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
Description: Binary data
_______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
