Nope, that doesn't fix it. I would have been surprised if it had, as
I've always done "make clean" before rebuilding. I even tried deleting
all my installation directories (so that there was no trace of a
previously-built polyml around) before rebuilding, and I still get the
assert (I am on x86_64).
If the fix you mean is r1297[1], then that hasn't been backported to the
5.4-fixes branch.
However, even applying this patch doesn't fix the problem.
Alex
[1]: commit message: Add back the tag to the dividend after a DIV
instruction to ensure that the register contains a valid tagged
integer. If a GC happened before the register was loaded with a valid
value it could trigger an assertion.
On 01/07/11 15:44, David Matthews wrote:
I am almost certain this is a problem I fixed a while ago that affects
64-bit X86. There was a bug in the integer divide code that computed
the correct result but left a invalid value in a temporary register.
If a garbage-collection happened before the register had been reused
the GC would crash in exactly the way you've described. The solution
is to rebuild the compiler to pick up the fix and then recompile
everything with the fixed compiler i.e. run
make compiler; make compiler
It's important to run "make compiler" TWICE. Running it only once
will leave buggy code around.
David
On 01/07/2011 14:30, Alex Merry wrote:
I think Lucas has probably mentioned this problem that we keep running
into with quantomatic.
I'm using Poly/ML 5.4 (ie: the lastest version of the 5.4 branch from
subversion).
Occasionally (or, in my case, frequently) we get the following error:
poly: scanaddrs.cpp:107: PolyWord
ScanAddress::ScanStackAddress(PolyWord, StackObject*, bool): Assertion
`val.IsDataPtr()' failed.
There appears to be no rhyme or reason to it. Re-running poly with the
same code another time will not necessarily produce this assertion, or
may produce it in a different place.
It happens regardless of compiler optimisations (I've tried -O3, -O2 and
-O0).
I managed to get a backtrace:
#0 0x0000003ff54330c5 in raise () from /lib64/libc.so.6
#1 0x0000003ff5434a76 in abort () from /lib64/libc.so.6
#2 0x0000003ff542b905 in __assert_fail () from /lib64/libc.so.6
#3 0x00007ffff7dc357e in ScanAddress::ScanStackAddress
(this=0x7fffffffde10, val=..., base=0x7fffed6b56c0, isCode=false)
at scanaddrs.cpp:107
#4 0x00007ffff7dc3811 in ScanAddress::ScanAddressesInObject
(this=0x7fffffffde10, obj=0x7fffed6b56c0,
lengthWord=4827858800541175088)
at scanaddrs.cpp:146
#5 0x00007ffff7d9b4e2 in ProcessMarkPointers::ScanAddressesInObject
(this=0x7fffffffde10, base=0x7fffed6b56c0, L=4827858800541175088)
at gc.cpp:509
#6 0x00007ffff7dc42c8 in ScanAddress::ScanAddressesInObject
(this=0x7fffffffde10, base=0x7fffed6b56c0) at scanaddrs.h:86
#7 0x00007ffff7dc3d48 in ScanAddress::ScanAddressesInRegion
(this=0x7fffffffde10, region=0x7fffed6a3af0, end=0x7fffed6c3000)
at scanaddrs.cpp:252
#8 0x00007ffff7d9ad12 in OpMutables (process=0x7fffffffde10) at
gc.cpp:348
#9 0x00007ffff7d9d2cc in doGC (doFullGC=false,
wordsRequiredToAllocate=3) at gc.cpp:1341
#10 0x00007ffff7d9f473 in QuickGCRequest::Perform (this=0x7fffeaa10cc0)
at gc.cpp:1955
#11 0x00007ffff7da732c in Processes::BeginRootThread
(this=0x7ffff7ffa8e0, rootFunction=0x605278) at processes.cpp:1253
#12 0x00007ffff7d9a472 in polymain (argc=3, argv=0x7fffffffe218,
exports=0xf72a00) at mpoly.cpp:205
#13 0x0000000000400659 in main (argc=3, argv=0x7fffffffe218) at
polystub.c:43
I don't know how useful that is, though.
Alex
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
