On Sat Jan 23 07:08:17 2016, mt1...@gmail.com wrote: > On 01/21/2016 06:44 PM, mt1957 wrote: > > On 01/21/2016 06:35 PM, mt1957 (via RT) wrote: > >> # New Ticket Created by mt1957 > >> # Please include the string: [perl #127340] > >> # in the subject line of all future correspondence about this issue. > >> # <URL: https://rt.perl.org/Ticket/Display.html?id=127340 > > >> > >> > >> L.s. > >> > >> Got this error; > >> > >> Internal error: zeroed target thread ID in work pass > >> > >> I really don't know where this happens, except it has something to with > >> threads using Promise > >> > >> Greetings > >> Marcel Timmerman > > Following is done. I guessed that the line just entered was perhaps a > > problem so commented it out. Run the program and the error was gone. > > Then, removed the '#' and run again. still gone! weird! > > > > Race conditions perhaps? > I've found the line of the error message in nqp/MoarVM/src/gc/collect.c > at line 439. > > Found in; > This is Rakudo version 2015.12-201-g2a8ca94 built on MoarVM version > 2015.12-29-g8079ca5 > implementing Perl 6.c. > > After upgrade of rakudo the message was gone again... (the code in > collect.c was not changed) > This is Rakudo version 2015.12-221-gb340ad5 built on MoarVM version > 2015.12-29-g8079ca5 > implementing Perl 6.c. > > This is a tricky thing for I do not know how to test it and what > conditions it needs to reproduce it. > The error is from the VM, and indicates that while performing garbage collection some kind of memory corruption was encountered. It's highly unlikely to indicate a bug in your program, unless you're (mis)using NativeCall. Furthermore, the bug is almost never in the garbage collector itself; rather, something else somewhere in the VM broke an invariant the GC depends on. So, the place things went wrong and the place we realize it can be enormously different (that is, the corruption could have occurred some millions of CPU instructions ago before we find it). And any change to memory layout can easily hide it.
Typically, such things are horrible to debug, though typically we start off by building a MoarVM with a tiny nursery size to make GC happen very often, and so hopefully to flag up the problem very quickly. How big is the program that triggers the problem? Is it something you're able to share (perhaps privately)? Thanks, Jonathan
