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
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 polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
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 polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Sorry, I failed to read your message clearly enough. I thought you were running SVN head. That is indeed the fix that I mean. Perhaps the easiest thing is for me to back-port that fix and build a new compiler for the 5.4 branch for X86-64 and install it in the polyml/imports directory. I'll try and do that later.
There is a compiler binary for each architecture in polyml/imports so doing a "make clean" simply restores the state to the last pre-built compiler. Running "make" uses the pre-built compiler and compiles in the basis library. It doesn't compile the compiler. To do that you need "make compiler" which uses the existing compiler to build a new one. Because the compiler source is written in ML you need an ML compiler to build the compiler.
David
On 01/07/2011 16:16, Alex Merry wrote:
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 polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Ah, OK, when I tried backporting the fix, I ran "make; make compiler", rather than "make; make compiler; make compiler", I think. I've done that now, and the problem seems to have gone away.
Alex
On 01/07/11 16:40, David Matthews wrote:
Sorry, I failed to read your message clearly enough. I thought you were running SVN head. That is indeed the fix that I mean. Perhaps the easiest thing is for me to back-port that fix and build a new compiler for the 5.4 branch for X86-64 and install it in the polyml/imports directory. I'll try and do that later.
There is a compiler binary for each architecture in polyml/imports so doing a "make clean" simply restores the state to the last pre-built compiler. Running "make" uses the pre-built compiler and compiles in the basis library. It doesn't compile the compiler. To do that you need "make compiler" which uses the existing compiler to build a new one. Because the compiler source is written in ML you need an ML compiler to build the compiler.
David
On 01/07/2011 16:16, Alex Merry wrote:
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 polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
-
alex.merry＠cs.ox.ac.uk -
David.Matthews＠prolingua.co.uk