When I run a script in EPIC, I get strange errors that I don't get when running via the command line. For example:
Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately after start byte 0xc3) in substitution iterator at /System/Library/Perl/5.8.6/Carp/Heavy.pm line 61, <IN> line 1.
Malformed UTF-8 character (unexpected continuation byte 0xa0, with no preceding start byte) in substitution iterator at /System/Library/Perl/5.8.6/Carp/Heavy.pm line 61, <IN> line 1.
I'm running EPIC 0.6.4 on Mac OS. Any idea what would cause this?
Only two things that might differ in EPIC compared to command line execution come to mind:
1) command line
2) environment variables
You can find out what EPIC is using by enabling the debugger console in preferences. With that setting, these pieces of information will be logged to $WORKSPACE/.metadata/.log when you start the script.
BTW, you should probably upgrade to 0.6.11 (especially if you use the debugger).
In the debug config, Eclipse is set to use the "native" evironment. I don't currently have any additional variables defined.
I'll try upgrading EPIC. I'm using it via EasyEclipse and not sure if it supports updating.
Even if you don't add environment variables yourself, it would still make sense to compare the environment within Eclipse with that on the command line.
Upgrading EPIC in EasyEclipse should work ok.
I followed your instructions. I'm running 0.6.11 now. There was a difference in PATH values. I used the PATH value from the CLI in Eclipse and I still get tons of errors. The errors happen when I use the SOAP::Lite module. Not sure if that is significant.
Do you have any other ideas?
Hi, I am using the current stable release and face a similar issue with some Polish UTF chars.
Malformed UTF-8 character (unexpected non-continuation byte 0x64, immediately after start byte 0xf3) resolver.t /bookindex/src/perl/t line 112 Perl Problem
Interestingly, the error only appears in the UI - not when I run the test case.
Sample line that leads to the error:
our $city = "Łódź";
If I replace the second letter with an 'o' the problem goes away.
My environment details:
Version: Helios Release
Build id: 20100617-1415
Don't use the stable build, use testing, available via update site. See
There have been some improvements with UTF-8 files in testing.
Yeah, that did the trick.