Mercury Bugs - mercury
View Issue Details
0000302mercuryBugpublic2013-10-30 12:022014-01-31 10:15
Assigned Tozs 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000302: can't bootcheck in asm_fast.gc.debug.stseg
DescriptionBootcheck in asm_fast.gc.debug.stseg crashes when making dependencies for the standard library, on both 32-bit and 64-bit.

May or may not be like bug 0000065.
TagsNo tags attached.
Attached Files? bug302.m (1,402) 2014-01-30 18:08

2014-01-29 18:36   
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
2014-01-30 16:42   
asm_fast.gc.stseg and_fast.gc.debug both both bootcheck successfully on the same machine.
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.
2014-01-30 17:12   
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.
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.
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.
2014-01-30 18:14   
I suggest separating the latter issue out into a new bug and the reclosing this one.
2014-01-30 18:26   
The original symptom is fixed. The underlying problem is now bug 314.
2014-01-31 10:15   
I didn't see the diff for this fix on the mailing list. Did you send it?


Issue History
2013-10-30 12:02wangpNew Issue
2014-01-29 18:36juliensfNote Added: 0000625
2014-01-30 16:42juliensfNote Added: 0000626
2014-01-30 16:55zsAssigned To => zs
2014-01-30 16:55zsStatusnew => assigned
2014-01-30 17:06zsNote Added: 0000627
2014-01-30 17:06zsStatusassigned => resolved
2014-01-30 17:06zsResolutionopen => fixed
2014-01-30 17:12juliensfNote Added: 0000628
2014-01-30 17:46zsNote Added: 0000629
2014-01-30 17:46zsStatusresolved => feedback
2014-01-30 17:46zsResolutionfixed => reopened
2014-01-30 18:08zsFile Added: bug302.m
2014-01-30 18:14zsNote Added: 0000630
2014-01-30 18:14juliensfNote Added: 0000631
2014-01-30 18:26zsNote Added: 0000632
2014-01-30 18:26zsStatusfeedback => resolved
2014-01-30 18:26zsResolutionreopened => fixed
2014-01-31 10:15pboneNote Added: 0000633