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? In the 2.9 release, there are still some problems with clang debug info (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!) > I'm currently compiling Clang trunk to see whether I can reproduce the bug > I'm discussing above. Let me know what you encounter. >> 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 ;-) David -- This email complies with ISO 3103 _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
