|
Notes |
|
|
|
When bootchecking in that grade on 64-bit linux I get nondet stack overflow while building the
stage 3 dependencies:
+ /home/jfischer/Mercury-Staging/mercury-srcdist-14.01-beta-2014-01-29/scripts/mmake -k dep_library dep_mdbcomp dep_browser_all dep_ssdb dep_compiler
cd library && PATH=../scripts:../util:../mfilterjavac:../../mfilterjavac:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake depend
gmake[1]: Entering directory `/home/jfischer/Mercury-Staging/mercury-srcdist-14.01-beta-2014-01-29/stage3/library'
config.status: creating LIB_FLAGS
/home/opturion/mercury-14.01-beta-2014-01-29/x86_64/bin//mmc --generate-dependencies --grade asm_fast.gc.debug.stseg --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS --no-warn-nothing-exported --no-warn-unused-imports mer_std
Mercury runtime: memory zone nondetstack#2 overflowed
This may have been caused by a stack overflow, due to unbounded recursion.
gmake[1]: *** [mer_std.depend] Error 1
gmake[1]: Target `depend' not remade because of errors.
gmake[1]: Leaving directory `/home/jfischer/Mercury-Staging/mercury-srcdist-14.01-beta-2014-01-29/stage3/library'
gmake: *** [library/mer_std.dep] Error 2 |
|
|
|
|
|
asm_fast.gc.stseg and_fast.gc.debug both both bootcheck successfully on the same machine. |
|
|
|
(0000627)
|
|
zs
|
|
2014-01-30 17:06
|
|
|
Fixed by commit 15cb7cf721ae2d04ce5bcd7702b63a41fd5c7b8c. The problem was --generate-dependencies processing a list of all the items in the library with a nondet loop using the nondet mode of list.member. That procedure is usually tail recursive, and so uses constant nondet stack space, but debugging defeats this. |
|
|
|
|
Is there still not a problem here? Why did the compiler before this fix succeed with asm_fast.gc.debug
but fail with asm_fast.gc.debug.stseg? My intuition is that lack of tail recursion should cause problems
for the former more obviously than the latter. |
|
|
|
(0000629)
|
|
zs
|
|
2014-01-30 17:46
|
|
My guess as to why the compiler before this fix succeeded with asm_fast.gc.debug but failed with asm_fast.gc.debug.stseg is that the nondet stack was just big enough without stseg, but the added slots needed for stsegs was enough to push things over the edge.
But you are right; there is a bug remaining, though the compiler would be a VERY bad test case for fixing it. The problem is that the macro making an ORDINARY nondet stack frame checks whether a new stack segment is needed, the macro making a TEMPORARY nondet stack frame does not.
Unfortunately, changing that fact would require changing the definitions of temp frames, which would NOT be a trivial thing to do. |
|
|
|
(0000630)
|
|
zs
|
|
2014-01-30 18:14
|
|
The file I just attached, bug302.m, is a very small test case for the actual problem. It just creates a list of numbers of specified length, and searches it for a number that is not in the list. On my machine, in asm_fast.gc.debug.stseg grade, it works for "bug302 1012" but fails on "bug302 1013".
For simple predicates like list.member(out, in), we could compute the total amount of space needed by tmp frames on the nondet stack and include this in the initial check to see whether we should create a new nondet stack segment. However, that wouldn't work in the general case where there are calls to nondet predicates between the initial mkframe and later mktmpframes: having enough space in the current segment when mkframe is called will in that case NOT guarantee that there is enough space in the current segment when mktmpframe is called. |
|
|
|
|
|
I suggest separating the latter issue out into a new bug and the reclosing this one. |
|
|
|
(0000632)
|
|
zs
|
|
2014-01-30 18:26
|
|
|
The original symptom is fixed. The underlying problem is now bug 314. |
|
|
|
(0000633)
|
|
pbone
|
|
2014-01-31 10:15
|
|
I didn't see the diff for this fix on the mailing list. Did you send it?
Thanks. |
|
bug302.m (1,402) 2014-01-30 18:08