I've just stumbled across a subtle and difficult-to-provoke GC bug while testing new changes to the GC. The problem was introduced in commit 50df879e or so (September 10), so I think the timing of the change is consistent with your problem.
For this bug to be relevant, your program would need to run a minor collection when memory use is in the neighborhood of 256MB to 300MB (which is not uncommon for 64-bit programs). The specific crash I can see also involves allocation a finalizer shortly before the GC, but the creation of a finalizer can be triggered in many ways, such as calling a bit of code for the first time so that it gets JIT-compiled. At Thu, 15 Oct 2015 11:56:21 +0300, Dmitry Pavlov wrote: > Matthew, > > > It seems that I have lost my grip on the crash. > > It has not happened for almost a week---neither with the version > > that I build myself, nor with the nightly build where I definitely > > saw it. I did not update Racket during this time. > > I did not do anything else. I have no idea why it is gone. Sorry. > > Oops, it just crashed again, 5+ hours of running. > I will re-run in under gdb. There is no guarantee, though, > that it will crash this time. > > By the way, I input "handle SIGSEGV nostop noprint" into gdb prior > to running, to get rid of gdb's complaints about Racket VM's way of > doing things. Am I correct that this should not hide the actual crash? > > Best regards, > > Dmitry > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
