Hi Fred, Le 5 mai 2012 à 18:19, Fred Kiefer a écrit :
> You better report this on Valgrind see this old link on similar problems: > > https://bbs.archlinux.org/viewtopic.php?pid=315064 > > > You will have to provide the whole instructions within selector_insert() for > them to track down the issue. > See the bug reports within the above link. David told me it was probably a bug in Valgrind too. I'll report it, thanks for the infos. Cheers, Quentin. > On 05.05.2012 13:10, Quentin Mathé wrote: >> When I compile libobjc2 with 'make debug=no' and run a simple ObjC tool with >> valgrind, I get the failure below. >> If I remove 'debug=no', valgrind runs just fine… Any idea? >> >> I'm using libobjc2 from SVN trunk on Ubuntu Linux x86/32. >> >> ==2659== Memcheck, a memory error detector >> ==2659== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. >> ==2659== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for >> copyright info >> ==2659== Command: obj/TestTool >> ==2659== >> vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66 >> ==2659== valgrind: Unrecognised instruction at address 0x479b2a3. >> ==2659== Your program just tried to execute an instruction that Valgrind >> ==2659== did not recognise. There are two possible reasons for this. >> ==2659== 1. Your program has a bug and erroneously jumped to a non-code >> ==2659== location. If you are running Memcheck and you just saw a >> ==2659== warning about a bad jump, it's probably your program's fault. >> ==2659== 2. The instruction is legitimate but Valgrind doesn't handle it, >> ==2659== i.e. it's Valgrind's fault. If you think this is the case or >> ==2659== you are not sure, please let us know and we'll try to fix it. >> ==2659== Either way, Valgrind will now raise a SIGILL signal which will >> ==2659== probably kill your program. >> ==2659== >> ==2659== Process terminating with default action of signal 4 (SIGILL) >> ==2659== Illegal opcode at address 0x479B2A3 >> ==2659== at 0x479B2A3: selector_insert (selector_table.c:188) >> ==2659== by 0x47998DD: register_selector_locked (selector_table.c:260) >> ==2659== by 0x479A665: objc_register_selector_copy (selector_table.c:359) >> ==2659== by 0x4799DB4: sel_registerName (selector_table.c:440) >> ==2659== by 0x47912FC: init_class_tables (class_table.c:43) >> ==2659== by 0x47956D5: __objc_exec_class (loader.c:59) >> ==2659== by 0x47A1B9E: .objc_load_function (properties.m:532) >> ==2659== by 0x47A1DEC: ??? (in /Local/Library/Libraries/libobjc.so.4.6.0) >> ==2659== by 0x478E603: ??? (in /Local/Library/Libraries/libobjc.so.4.6.0) >> ==2659== by 0x400DBBB: call_init (dl-init.c:70) >> ==2659== by 0x400DCD8: _dl_init (dl-init.c:134) >> ==2659== by 0x400088E: ??? (in /lib/ld-2.11.1.so) >> ==2659== >> ==2659== HEAP SUMMARY: >> ==2659== in use at exit: 107,765 bytes in 18 blocks >> ==2659== total heap usage: 19 allocs, 1 frees, 107,790 bytes allocated > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
