gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Valgrind doesn't always work with libobjc2


From: Quentin Mathé
Subject: Re: Valgrind doesn't always work with libobjc2
Date: Sun, 6 May 2012 12:55:22 +0200

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]