Skip to main content

Re: Runtimes problems when building with gcc/g++ 4.6

6 replies [Last post]
davyp
Offline
Joined: 2007-01-03
Points: 0

It seems to be a string/utf8 related issue. If I set LC_ALL=C (or unset
LANG), then the experiment below continues further but fails in a later
test (with an NPE in a string function java.lang.Integer.getChars()).

Weird.

Davy

On 01/26/2012 08:51 PM, Davy Preuveneers wrote:
> Thanks Chris and Hinkmond for the suggestions.
>
> I had already done some further tests. In order to get all the debug
> info in the stack trace below, I had set CVM_DEBUG=true and then the
> test below ran normal. With debugging disabled I am having trouble.
>
> However, I am not sure if it is a compiler optimization issue, as I can
> trigger the same exception as below in another configuration in which I
> build cvm as a library (rather than as am executable), and have another
> frontend application dlopen() this library and run the java app. That is
> also how I ported phoneME to android. With this setup, I again get an
> NPE in sun.io.CharToByteUTF8.convert().
>
> I will do some further digging ...
>
> Cheers,
> Davy
>
> On 01/26/2012 08:14 PM, Chris wrote:
>> You might also want to try enabling asserts with CVM_DEBUG_ASSERTS=true.
>>
>> Chris
>>
>> On 1/26/12 11:09 AM, Hinkmond Wong wrote:
>>> Hi Davy,
>>>
>>> Can you start by ruling out if this is an difference in the gcc 4.5
>>> vs. 4.6 optimizations? Try forcing the CCFLAGS_SPEED,
>>> CCFLAGS_SPEED_OPTIONS, CCFLAGS_SPACE and CCFLAGS_SPACE_OPTIONS to use
>>> -O0 (dash oh zero) or something less than -O4. If that causes a
>>> difference, it might be that gcc 4.6 has more aggressive optimizations
>>> that adversely affect our build.
>>>
>>> Thanks,
>>> Hinkmond
>>>
>>>
>>>
>>> On 1/26/2012 1:49 AM, Davy Preuveneers wrote:
>>>> Hi,
>>>>
>>>> It seems there are some issues with pMEA builds when they are compiled
>>>> with gcc/g++ 4.6. Running the following test with a simple CDC build for
>>>> Linux/x86 gives:
>>>>
>>>> $ bin/cvm -cp testclasses.zip Test
>>>> ...
>>>> ...recurse
>>>> ...recurse
>>>> ...recurse
>>>> CVMjniExceptionDescribe failed: couldn't print stack trace.
>>>> Using brute force method to print stack trace.
>>>> java.lang.NullPointerException: Null pointer dereference
>>>> at sun.io.CharToByteUTF8.convert([CII[BII)I(Compiled
>>>> Method)(Unknown Source)
>>>> at sun.io.CharToByteConverter.convertAny([CII[BII)I(Unknown
>>>> Source)
>>>> at java.io.OutputStreamWriter.write([CII)V(Unknown Source)
>>>> at java.io.BufferedWriter.flushBuffer()V(Unknown Source)
>>>> at java.io.PrintStream.write(Ljava/lang/String;)V(Unknown
>>>> Source)
>>>> at java.io.PrintStream.print(Ljava/lang/String;)V(Unknown
>>>> Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.test1(Z)V(Unknown Source)
>>>> at Test.main([Ljava/lang/String;)V(Unknown Source)
>>>> at sun.misc.CVM.runMain()V(Unknown Source)
>>>>
>>>> Not sure what is going on, but when I use gcc/g++ 4.5, the above test
>>>> produces the expected results. Tests were carried out on a 32-bit
>>>> Kubuntu 11.10 machine.
>>>>
>>>> Regards,
>>>> Davy
>>>>
>>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>>
>>
>
>

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
davyp
Offline
Joined: 2007-01-03
Points: 0

> If I build cvm as a shared library libcvm.so (linking the same objects
> and libraries, and using dlopen() and dlsym() to call the main() method
> in libcvm.so), it does not matter which compiler version or optimization
> flags I use, I always get exceptions in string related methods.

To make matters even more bizarre: if I copy the above binaries and
libraries to an old laptop that also runs Kubuntu 11.10 32-bit (all
systems are up to date), they work.

I think I am gonna give up.

Davy

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Hinkmond Wong Guest
Offline
Joined: 2010-11-03
Points: 0

On 1/26/2012 1:36 PM, Davy Preuveneers wrote:
>> If I build cvm as a shared library libcvm.so (linking the same objects
>> and libraries, and using dlopen() and dlsym() to call the main() method
>> in libcvm.so), it does not matter which compiler version or optimization
>> flags I use, I always get exceptions in string related methods.
> To make matters even more bizarre: if I copy the above binaries and
> libraries to an old laptop that also runs Kubuntu 11.10 32-bit (all
> systems are up to date), they work.
>

Hi Davy,

If you ldd the cvm executable or library, are there any differences that
might explain the errors (different versions of the libraries being
pulled in)?

Thanks,
Hinkmond

Chris Guest
Offline
Joined: 2012-01-27
Points: 0

CVM_DEBUG_ASSERTS=true is different than CVM_DEBUG=true. It will give
you optimized code, but with asserts enabled. You can also try
CVM_DEBUG=true CVM_OPTIMIZED=true. That will give you full debugging
support (asserts, tracing, symbols) but with gcc optimized code.

Chris

On 1/26/12 11:51 AM, Davy Preuveneers wrote:
> Thanks Chris and Hinkmond for the suggestions.
>
> I had already done some further tests. In order to get all the debug
> info in the stack trace below, I had set CVM_DEBUG=true and then the
> test below ran normal. With debugging disabled I am having trouble.
>
> However, I am not sure if it is a compiler optimization issue, as I can
> trigger the same exception as below in another configuration in which I
> build cvm as a library (rather than as am executable), and have another
> frontend application dlopen() this library and run the java app. That is
> also how I ported phoneME to android. With this setup, I again get an
> NPE in sun.io.CharToByteUTF8.convert().
>
> I will do some further digging ...
>
> Cheers,
> Davy
>
> On 01/26/2012 08:14 PM, Chris wrote:
>> You might also want to try enabling asserts with CVM_DEBUG_ASSERTS=true.
>>
>> Chris
>>
>> On 1/26/12 11:09 AM, Hinkmond Wong wrote:
>>> Hi Davy,
>>>
>>> Can you start by ruling out if this is an difference in the gcc 4.5
>>> vs. 4.6 optimizations? Try forcing the CCFLAGS_SPEED,
>>> CCFLAGS_SPEED_OPTIONS, CCFLAGS_SPACE and CCFLAGS_SPACE_OPTIONS to use
>>> -O0 (dash oh zero) or something less than -O4. If that causes a
>>> difference, it might be that gcc 4.6 has more aggressive optimizations
>>> that adversely affect our build.
>>>
>>> Thanks,
>>> Hinkmond
>>>
>>>
>>>
>>> On 1/26/2012 1:49 AM, Davy Preuveneers wrote:
>>>> Hi,
>>>>
>>>> It seems there are some issues with pMEA builds when they are compiled
>>>> with gcc/g++ 4.6. Running the following test with a simple CDC build for
>>>> Linux/x86 gives:
>>>>
>>>> $ bin/cvm -cp testclasses.zip Test
>>>> ...
>>>> ...recurse
>>>> ...recurse
>>>> ...recurse
>>>> CVMjniExceptionDescribe failed: couldn't print stack trace.
>>>> Using brute force method to print stack trace.
>>>> java.lang.NullPointerException: Null pointer dereference
>>>> at sun.io.CharToByteUTF8.convert([CII[BII)I(Compiled
>>>> Method)(Unknown Source)
>>>> at sun.io.CharToByteConverter.convertAny([CII[BII)I(Unknown
>>>> Source)
>>>> at java.io.OutputStreamWriter.write([CII)V(Unknown Source)
>>>> at java.io.BufferedWriter.flushBuffer()V(Unknown Source)
>>>> at java.io.PrintStream.write(Ljava/lang/String;)V(Unknown
>>>> Source)
>>>> at java.io.PrintStream.print(Ljava/lang/String;)V(Unknown
>>>> Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.recurse(I)I(Unknown Source)
>>>> at Test.test1(Z)V(Unknown Source)
>>>> at Test.main([Ljava/lang/String;)V(Unknown Source)
>>>> at sun.misc.CVM.runMain()V(Unknown Source)
>>>>
>>>> Not sure what is going on, but when I use gcc/g++ 4.5, the above test
>>>> produces the expected results. Tests were carried out on a 32-bit
>>>> Kubuntu 11.10 machine.
>>>>
>>>> Regards,
>>>> Davy
>>>>
>>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>

Chris Guest
Offline
Joined: 2012-01-27
Points: 0

On 1/27/12 3:15 AM, Davy Preuveneers wrote:
> On 01/27/2012 06:20 AM, Chris wrote:
>> CVM_DEBUG_ASSERTS=true is different than CVM_DEBUG=true. It will give
>> you optimized code, but with asserts enabled. You can also try
>> CVM_DEBUG=true CVM_OPTIMIZED=true. That will give you full debugging
>> support (asserts, tracing, symbols) but with gcc optimized code.
>>
>> Chris
> Hi Chris, Hinkmond,
>
> I did some further tests with a default build of CDC compiled with gcc
> 4.6 and assertions enabled. Running the following test
>
> bin/cvm -cp testclasses.zip Test
>
> gives me on all my test machines this assertion error:
>
> ...recurse
> ...recurse
> ...recurse
> ...recurse
> Assertion failed at line 309 in
> ../../src/x86/javavm/runtime/jit/jitemitter_cpu.c: scale != CVMX86no_scale
> Segmentation fault
I think you will need to debug this in gdb. Get a backtrace and also
figure how "scale" got passed in improperly. I suspect the problem is
actually the passing in of an invalid "base" register, leading this
function into a code path it should not be entering.
>
> When compiled with gcc 4.5, the above test works on all machines.
> If, however, I compile and link the phoneme objects into a library
> (rather than into the bin/cvm binary):
>
> gcc-4.5 -shared -Wl,-soname,libcvm.so.1 -o libcvm.so ...
>
> and dlopen that library in another mini frontend app:
>
> #include
> #include
> #include
> #include
> #include
>
> int (*fn_main)(int, char **);
>
> int main(int argc, char **argv) {
> void *libhandle;
> char libpath[256];
> char *ptr;
>
> strncpy(libpath, argv[0], 200);
> ptr = strrchr(libpath, '/');
> strcpy(ptr, "/libcvm.so");
>
> libhandle = dlopen(libpath, RTLD_LAZY);
> if (!libhandle) {
> fprintf(stderr, "%s: %s\n", libpath, dlerror());
> exit(1);
> }
>
> fn_main = (int (*)(int, char **))dlsym(libhandle, "main");
> if (fn_main == NULL) {
> fprintf(stderr, "%s\n", dlerror());
> exit(1);
> }
>
> (*fn_main)(argc, argv);
>
> dlclose(libhandle);
> return 0;
> }
>
> then this app and the libcvm.so library don't work on one machine (get
> Java exceptions like below). This is an excerpt of the stack trace (the
> whole log with CVM_DEBUG=true CVM_OPTIMIZED=true is a bit long):
>
> CVMjniExceptionDescribe failed: couldn't print stack trace.
> Using brute force method to print stack trace.
> java.lang.NullPointerException: Null pointer dereference
> at sun.io.CharToByteUTF8.convert([CII[BII)I(Compiled
> Method)(CharToByteUTF8.java:137)
> at
> sun.io.CharToByteConverter.convertAny([CII[BII)I(CharToByteConverter.java:159)
> at
> java.io.OutputStreamWriter.write([CII)V(OutputStreamWriter.java:204)
> at java.io.BufferedWriter.flushBuffer()V(BufferedWriter.java:131)
> at
> java.io.PrintStream.write(Ljava/lang/String;)V(PrintStream.java:323)
> at
> java.io.PrintStream.print(Ljava/lang/String;)V(PrintStream.java:467)
> at Test.recurse(I)I(Test.java:453)
> at Test.recurse(I)I(Test.java:456)
> at Test.recurse(I)I(Test.java:456)
> at Test.recurse(I)I(Test.java:456)
> at Test.recurse(I)I(Test.java:456)
> at Test.recurse(I)I(Test.java:456)
> at Test.recurse(I)I(Test.java:456)
> at Test.test1(Z)V(Test.java:288)
> at Test.main([Ljava/lang/String;)V(Test.java:108)
> at sun.misc.CVM.runMain()V(CVM.java:524)
>
> However, on another machine the same lib and binary work fine. If I
> unset most of my environment vars (including LANG="en_US.UTF-8"), the
> above test fails at a later stage again with a string related exception:
>
> testManyFieldsAndMethods() failed:
> java.lang.NullPointerException: Null pointer dereference
> java.lang.NullPointerException: Null pointer dereference
> CVMjniExceptionDescribe failed: couldn't print stack trace.
> Using brute force method to print stack trace.
> java.lang.NullPointerException: Null pointer dereference
> at java.lang.Integer.getChars(I[C)I(Compiled
> Method)(Integer.java:347)
> at
> java.lang.Integer.appendTo(ILjava/lang/StringBuffer;)V(Integer.java:402)
> at
> java.lang.StringBuffer.append(I)Ljava/lang/StringBuffer;(StringBuffer.java:670)
> at
> java.lang.StackTraceElement.toString()Ljava/lang/String;(StackTraceElement.java:152)
> at
> java.lang.String.valueOf(Ljava/lang/Object;)Ljava/lang/String;(String.java:2313)
> at
> java.lang.StringBuffer.append(Ljava/lang/Object;)Ljava/lang/StringBuffer;(StringBuffer.java:454)
> at
> java.lang.Throwable.printStackTrace(Ljava/io/PrintStream;)V(Throwable.java:489)
> at java.lang.Throwable.printStackTrace()V(Throwable.java:472)
> at Test.testManyFieldsAndMethods()V(Test.java:727)
> at Test.main([Ljava/lang/String;)V(Test.java:142)
> at sun.misc.CVM.runMain()V(CVM.java:524)
>
>
> So, I think we are having two issues: one has to do with gcc 4.6
> compiler optimizations, and the other one is just plain bizarre.
Yes, I would agree. For the 2nd one, keep in mind that if a JIT'd method
crashes, it will generate an NPE. This is because of the trap-based NPE
support. You might want to try disabling trap-based NPE support to see
if it is a real NPE or not. Do this with an #undef of
CVMJIT_TRAP_BASED_NULL_CHECKS in the linux-x86 jit_arch.h.

I will also add that the OSS source does not really officially support
building as a shared library. It is not something we were testing at the
time. Nor does it officially support the x86 JIT. We know there are bugs
there.

Chris
>
> That is all for now.
>
> Davy
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Hinkmond Wong Guest
Offline
Joined: 2010-11-03
Points: 0

On 1/26/2012 12:28 PM, Davy Preuveneers wrote:
> It seems to be a string/utf8 related issue. If I set LC_ALL=C (or unset
> LANG), then the experiment below continues further but fails in a later
> test (with an NPE in a string function java.lang.Integer.getChars()).

Hi Davy,

Can you try setting LANG=en_US ?

Does that help both errors?

Thanks,
Hinkmond

>
> Weird.
>
> Davy
>
> On 01/26/2012 08:51 PM, Davy Preuveneers wrote:
>> Thanks Chris and Hinkmond for the suggestions.
>>
>> I had already done some further tests. In order to get all the debug
>> info in the stack trace below, I had set CVM_DEBUG=true and then the
>> test below ran normal. With debugging disabled I am having trouble.
>>
>> However, I am not sure if it is a compiler optimization issue, as I can
>> trigger the same exception as below in another configuration in which I
>> build cvm as a library (rather than as am executable), and have another
>> frontend application dlopen() this library and run the java app. That is
>> also how I ported phoneME to android. With this setup, I again get an
>> NPE in sun.io.CharToByteUTF8.convert().
>>
>> I will do some further digging ...
>>
>> Cheers,
>> Davy
>>
>> On 01/26/2012 08:14 PM, Chris wrote:
>>> You might also want to try enabling asserts with CVM_DEBUG_ASSERTS=true.
>>>
>>> Chris
>>>
>>> On 1/26/12 11:09 AM, Hinkmond Wong wrote:
>>>> Hi Davy,
>>>>
>>>> Can you start by ruling out if this is an difference in the gcc 4.5
>>>> vs. 4.6 optimizations? Try forcing the CCFLAGS_SPEED,
>>>> CCFLAGS_SPEED_OPTIONS, CCFLAGS_SPACE and CCFLAGS_SPACE_OPTIONS to use
>>>> -O0 (dash oh zero) or something less than -O4. If that causes a
>>>> difference, it might be that gcc 4.6 has more aggressive optimizations
>>>> that adversely affect our build.
>>>>
>>>> Thanks,
>>>> Hinkmond
>>>>
>>>>
>>>>
>>>> On 1/26/2012 1:49 AM, Davy Preuveneers wrote:
>>>>> Hi,
>>>>>
>>>>> It seems there are some issues with pMEA builds when they are compiled
>>>>> with gcc/g++ 4.6. Running the following test with a simple CDC build for
>>>>> Linux/x86 gives:
>>>>>
>>>>> $ bin/cvm -cp testclasses.zip Test
>>>>> ...
>>>>> ...recurse
>>>>> ...recurse
>>>>> ...recurse
>>>>> CVMjniExceptionDescribe failed: couldn't print stack trace.
>>>>> Using brute force method to print stack trace.
>>>>> java.lang.NullPointerException: Null pointer dereference
>>>>> at sun.io.CharToByteUTF8.convert([CII[BII)I(Compiled
>>>>> Method)(Unknown Source)
>>>>> at sun.io.CharToByteConverter.convertAny([CII[BII)I(Unknown
>>>>> Source)
>>>>> at java.io.OutputStreamWriter.write([CII)V(Unknown Source)
>>>>> at java.io.BufferedWriter.flushBuffer()V(Unknown Source)
>>>>> at java.io.PrintStream.write(Ljava/lang/String;)V(Unknown
>>>>> Source)
>>>>> at java.io.PrintStream.print(Ljava/lang/String;)V(Unknown
>>>>> Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.recurse(I)I(Unknown Source)
>>>>> at Test.test1(Z)V(Unknown Source)
>>>>> at Test.main([Ljava/lang/String;)V(Unknown Source)
>>>>> at sun.misc.CVM.runMain()V(Unknown Source)
>>>>>
>>>>> Not sure what is going on, but when I use gcc/g++ 4.5, the above test
>>>>> produces the expected results. Tests were carried out on a 32-bit
>>>>> Kubuntu 11.10 machine.
>>>>>
>>>>> Regards,
>>>>> Davy
>>>>>
>>>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>

davyp
Offline
Joined: 2007-01-03
Points: 0

On 01/26/2012 09:40 PM, Hinkmond Wong wrote:
> On 1/26/2012 12:28 PM, Davy Preuveneers wrote:
>> It seems to be a string/utf8 related issue. If I set LC_ALL=C (or unset
>> LANG), then the experiment below continues further but fails in a later
>> test (with an NPE in a string function java.lang.Integer.getChars()).
>
> Hi Davy,
>
> Can you try setting LANG=en_US ?
>
> Does that help both errors?

The same late failure as with LC_ALL=C. The strange thing is, if I
compile with g++-4.5 I don't need to mess around with these environment
variables and the test run is OK (even with -O4).

If I use gcc 4.6 I get failures with -O4 and -O2, but with -O0 or -O1
optimization the test also succeeds. So it seems to be a compiler issue
somewhere that affects string handling one way or the other.

If I build cvm as a shared library libcvm.so (linking the same objects
and libraries, and using dlopen() and dlsym() to call the main() method
in libcvm.so), it does not matter which compiler version or optimization
flags I use, I always get exceptions in string related methods.

Davy

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm