On 01/23/2016 06:04 PM, jn...@jnthn.net via RT wrote:
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)?
There are quite a few classes/modules in two projects, It is the MongoDB
project which can be found at
https://github.com/MARTIMM/mongo-perl6-driver and is using BSON to be
found at https://github.com/MARTIMM/BSON
To check the current code use the development branch for the mongo code.
For the bson code, the master branch is ok.
First it is easy to install the BSON code with panda, then get the mongo
driver code from github
To run the tests a mongod server must be installed and the test
t/000-mk-sandbox.t expects it at
/usr/bin/mongod. However it might be easier to set the environment
variable TRAVIS to 1 and run
*'sh Travis-ci/install-mongodb.sh 3.0.5*'. It will get the version of
mongod server I am testing against in the Travis-ci directory. Then the
first test creates a Sandbox and starts the server at localhost:65000 if
that one is available, then makes a note in the Sandbox directory and is
used in all of the other tests. At first the startup will take some time
because the server needs some workfiles to initialize.
The threading code using Promise can be found in the modules
lib/BSON/Document.pm6 in the BSON project and also in the
lib/MongoDB/Client.pm6 and lib/MongoDB/Server.pm6 in the mongo driver
project.
The code runs ok with the perl version: ' Rakudo version
2015.12-221-gb340ad5 built on MoarVM version 2015.12-29-g8079ca5
implementing Perl 6.c.'
The previous version which gave a problem in test t//301-Collection.t;
'Rakudo version 2015.12-201-g2a8ca94 built on MoarVM version
2015.12-29-g8079ca5 implementing Perl 6.c.'.
Having said this, a last test showed the error again using *'prove -e
perl6 t*' when at t/200-Database.t. It disappears when using the -v option.
Hopefully this is enough information to work with,
Regards
Marcel Timmerman
