I couldn't reproduce it on my laptop. (uname -rv: 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013)

But GC is indeed buggy, and it is enormously hard to make a reasonably small test case that will fail on most machines :(

On Fri, Dec 13, 2013 at 1:47 AM, Artem Tarasov <lomereiter@gmail.com> wrote:

> I couldn't reproduce it on my laptop. (uname -rv: 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013)
>

on my machines I had to try with n from 10 to 100 (in increments of 10) to get the segfault. The few bad values of n differed in each machine. Also the ubuntu I used were 12.x instead, if that matters.


But GC is indeed buggy, and it is enormously hard to make a reasonably
> small test case that will fail on most machines :(
>

the cases I was aware of were rather due to GC being overly conservative. This bug seems more serious and I haven't seen such kind yet. It also disappears if we refactor code to use string instead of DirEntry (ie only maintain the entry.name field)

Did you try to add some debug printf statements in gcx.d? The log of memory ranges that were marked/allocated would be helpful.