I'm having a bit of difficulty working out exactly what is the bit that is wrong in your test case. Can you try to put together a reduced test case? My suspicion is that it's somehow related to the handling of unions. NSMapTable uses unions of the OpenStep-style pointer functions structure and the OS X 10.5-style NSPointerFunctions object in various places, and there's a lot of potential for stuff to go wrong there due to weirdness in the Linux ABI for unions.
David On 21 Jun 2011, at 13:50, Quentin Mathé wrote: > Le 20 juin 2011 à 15:29, David Chisnall a écrit : > >> On 20 Jun 2011, at 14:20, Quentin Mathé wrote: >> >>> Le 20 juin 2011 à 15:01, David Chisnall a écrit : >>> >>>> Thanks Quentin, >>>> >>>> Currently, the EtoileFoundation test suite crashes with GC enabled. This >>>> was working a couple of weeks ago - it seems to be related to the use of >>>> NSMapTable with weak-to-strong references (these are currently broken in >>>> GNUstep - patches welcome...). >>> >>> In the trait code, initially I was using a map table with strong to opaque >>> memory references, but it appears there is a bug in Clang 2.9 that prevents >>> the -[NSConcretePointerFunctions initWithOption:] to be called correctly >>> (see Please test pending bugfix release of base on gnustep-discuss). >> >> I think this is an LLVM optimiser bug. Did you try compiling at -O0? > > Base, EF and my test program were compiled with -O0, libobjc2 was compiled > -O2. > >> In the 2.9 release, there are still some problems with clang debug info > > I observed that too. > >> (it's a lot better in trunk), so I think that what you are seeing in gdb is >> related to errors in the debug info, not errors in the generated code >> (although there may still be some there). I was seeing crashing in GNUstep >> with clang just before the 2.9 release, but I thought it was fixed with the >> release (the GNUstep test suite passed for me on x86-64/Linux - I only run >> trunk on my FreeBSD system). >> >>> So I rewrote this code to use a dictionary. >>> iirc this issue means all pointer functions happen to be initialized as >>> strong object references. Because the map table weak references become >>> strong, this could explain why the map table crashes with GC if the bug I'm >>> mentionning exist in Clang trunk too. >> >> It's crashing in the GSIMap code, because that code is a mess. Currently, >> it doesn't insert the weak write barriers. The old GS GC code explicitly >> marks the memory as GC-ignored and as a disappearing link (which is fragile >> and not actually concurrency-safe, since the GC lock is not held while >> loading the link), but there is not yet any code in there to use the weak >> read / write barriers correctly (patches very welcome!) > > ok, looks like another bug indeed. > >>> I'm currently compiling Clang trunk to see whether I can reproduce the bug >>> I'm discussing above. >> >> Let me know what you encounter. > > I recompiled libobjc2, Base and EF with Clang trunk (yesterday) and -O0, but > I still get the same crash and corrupted arguments. I attached the test > progam I posted on gnustep-discuss, but added some extra lines to show the > map table crash triggered by the corrupted arguments in > -[NSConcretePointerFunctions initWithOptions:]. See debug session at the end > of this mail too. > >> >>>> Given the large number of new features and the removal of some classes, >>>> would it be better to bump the version to 0.5? >>> >>> I like the idea. However we have advertised 0.5 as our first-user release >>> everywhere (e.g. slide presentations), so I don't know whether we should do >>> it or not. Any other opinion? >> >> I think that's for the Étoilé release, not for the component releases. I >> thought we decided that we should give up trying to keep version numbers for >> components in sync with the project as a whole. Étoilé 0.5 can include >> EtoileFoundation 1.5 if required ;-) > > Ah right I forgot about that :-) > > Back to the bug topic… Here is the debug session with some back traces that > show how the test program crashes for me with Clang but not GCC 4.4.3. Here > I'm running it with Clang trunk. As a side note, I didn't see anything wrong > with objc_msg_lookup() when I stepped through it. > > [Thread debugging using libthread_db enabled] > [New Thread 0xb7fe0b70 (LWP 27164)] > 2011-06-21 14:24:13.373 pfunc-issue[27163] ---> Alloc > <NSConcretePointerFunctions: 0x80f4c48> > 2011-06-21 14:24:13.375 pfunc-issue[27163] ---> Init > <NSConcretePointerFunctions: 0x80f4c48> > 2011-06-21 14:24:13.376 pfunc-issue[27163] ---> Alloc > <NSConcretePointerFunctions: 0x80f4c48> > > Breakpoint 1, -[NSConcretePointerFunctions initWithOptions:] (self=0x2, > _cmd=0x804b388, options=135220296) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > 188 - (id) initWithOptions: (NSPointerFunctionsOptions)options > (gdb) c > Continuing. > 2011-06-21 14:24:20.998 pfunc-issue[27163] ---> InitWithOptions: > <NSConcretePointerFunctions: 0x80f4c48> > > // Now here is the part that involves the new lines that creates a map table… > > // First the pointer functions for the key option > > Breakpoint 1, -[NSConcretePointerFunctions initWithOptions:] (self=0x0, > _cmd=0x70a240, options=136206136) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > 188 - (id) initWithOptions: (NSPointerFunctionsOptions)options > (gdb) bt > #0 -[NSConcretePointerFunctions initWithOptions:] (self=0x0, _cmd=0x70a240, > options=136206136) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > #1 0x003b9fed in -[NSMapTable initWithKeyOptions:valueOptions:capacity:] ( > self=0x81caa60, _cmd=0x804b368, keyOptions=0, valueOptions=2, > initialCapacity=0) > at /home/qmathe/reps/devmodules/core/base/Source/NSMapTable.m:110 > #2 0x08048cf7 in main (argc=1, argv=0xbffff4e4) at pfunc-issue.m:26 > (gdb) c > Continuing. > > // Then the pointer functions for the value option > > Breakpoint 1, -[NSConcretePointerFunctions initWithOptions:] (self=0x2, > _cmd=0x70a240, options=136201152) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > 188 - (id) initWithOptions: (NSPointerFunctionsOptions)options > (gdb) bt > #0 -[NSConcretePointerFunctions initWithOptions:] (self=0x2, _cmd=0x70a240, > options=136201152) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > #1 0x003ba059 in -[NSMapTable initWithKeyOptions:valueOptions:capacity:] ( > self=0x81caa60, _cmd=0x804b368, keyOptions=0, valueOptions=2, > initialCapacity=0) > at /home/qmathe/reps/devmodules/core/base/Source/NSMapTable.m:111 > #2 0x08048cf7 in main (argc=1, argv=0xbffff4e4) at pfunc-issue.m:26 > (gdb) c > Continuing. > > // Finally the default pointer functions (created by the concrete map table) > > Breakpoint 1, -[NSConcretePointerFunctions initWithOptions:] (self=0x0, > _cmd=0x6f4040, options=136193768) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > 188 - (id) initWithOptions: (NSPointerFunctionsOptions)options > (gdb) bt > #0 -[NSConcretePointerFunctions initWithOptions:] (self=0x0, _cmd=0x6f4040, > options=136193768) > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:188 > #1 0x002f3811 in -[NSConcreteMapTable > initWithKeyPointerFunctions:valuePointerFunctions:capacity:] (self=0x81caa60, > _cmd=0x70a200, keyFunctions=0x81e5738, > valueFunctions=0x81e43c0, initialCapacity=0) > at /home/qmathe/reps/devmodules/core/base/Source/NSConcreteMapTable.m:1268 > #2 0x003ba0ad in -[NSMapTable initWithKeyOptions:valueOptions:capacity:] ( > self=0x81caa60, _cmd=0x804b368, keyOptions=0, valueOptions=2, > initialCapacity=0) > at /home/qmathe/reps/devmodules/core/base/Source/NSMapTable.m:112 > #3 0x08048cf7 in main (argc=1, argv=0xbffff4e4) at pfunc-issue.m:26 > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x00777b08 in objc_msg_lookup () from /Local/Library/Libraries/libobjc.so.4 > (gdb) bt > #0 0x00777b08 in objc_msg_lookup () from > /Local/Library/Libraries/libobjc.so.4 > #1 0x003ff1df in acquireRetainedObject (item=0x80491ff, size=0, > <------------------ We crash because the pointer function related to strong > refs is called when it should be the one to handle opaque memory refs. > shouldCopy=0 '\000') > at > /home/qmathe/reps/devmodules/core/base/Source/NSConcretePointerFunctions.m:52 > #2 0x002f1d32 in pointerFunctionsAcquire (PF=0x81caaa8, dst=0x81e3e08, > src=0x80491ff) > at > /home/qmathe/reps/devmodules/core/base/Source/././NSConcretePointerFunctions.h:75 > #3 0x002f12d2 in GSIMapAddPair (map=0x81caa60, key=..., value=...) > at > /home/qmathe/reps/devmodules/core/base/Source/../Headers/GNUstepBase/GSIMap.h:1050 > #4 0x002f4510 in -[NSConcreteMapTable setObject:forKey:] (self=0x81caa60, > _cmd=0x804b380, anObject=0x80491ff, aKey=0x804b2a8) > at /home/qmathe/reps/devmodules/core/base/Source/NSConcreteMapTable.m:1414 > #5 0x08048d4a in main (argc=1, argv=0xbffff4e4) at pfunc-issue.m:29 > > Cheers, > Quentin. > > <pfunc-issue.m>_______________________________________________ > Etoile-dev mailing list > Etoile-dev@gna.org > https://mail.gna.org/listinfo/etoile-dev -- Sent from my Cray X1 _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
