Skip to main content.

Wednesday, April 01, 2009

Falcon 0.9.0 was deemed "bleeding edge" for various reasons, but mainly because it failed some tests on some architectures. Most notably, it was messing up all the threaded tests on Win32/Mingw, and it crashed at random (once every 5-10 launches) on tests 38a or 51a (with different errors as malloc asserts, bus errors, segfaults etc) on some old Fedora based virtual host.

The type of error (its errand behavior), the fact that it appeared in the only tests forcing GC from the VM (while forcing GC from outside, activating the -M memory collection switch, everything was fine), the fact that previous versions were totally immune led me to think there was some concurrency error in the new GC, or some randomic behavior due to concurrency in sending the items to the GC and collecting them.

I'll cut the story short: the problem was simply that the ItemList, on which the new CoreSlot (message broadcasters) are based, and that is also the inner core of the List class in the Falcon language, has an internal list of active iterators. The list marks the iterators, and the iterators, when they are inside a Falcon iterator instance, mark back their owner. But if the GC destroyed the list, the iterators were still considered valid, and when they were to be destroyed, they tried to unlink themselves from the owner list...

Unluckily, this rarely (if ever) crashed; instead, it seems that it just dirtied the heap on every platform I tried (including VS8 with memory tracing enabled), and that may have caused (or not) a memory corruption detection on subsequent tests.

Oh, well, at least I checked line per line the mempool code twice, and now I can be sure that the new GC code is absolutely stable and consistent everywhere. This old error helped me to nail a couple of problems in the code that may have become a nasty nuisance later on.


No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it