2024-07-16 01:06 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000302mercuryBugpublic2014-01-31 10:15
Assigned Tozs 
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
  • ? file icon bug302.m (1,402 bytes) 2014-01-30 18:08




juliensf (administrator)

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


juliensf (administrator)

asm_fast.gc.stseg and_fast.gc.debug both both bootcheck successfully on the same machine.


zs (developer)

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.


juliensf (administrator)

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.


zs (developer)

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.


zs (developer)

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.


juliensf (administrator)

I suggest separating the latter issue out into a new bug and the reclosing this one.


zs (developer)

The original symptom is fixed. The underlying problem is now bug 314.


pbone (administrator)

I didn't see the diff for this fix on the mailing list. Did you send it?


-Issue History
Date Modified Username Field Change
2013-10-30 12:02 wangp New Issue
2014-01-29 18:36 juliensf Note Added: 0000625
2014-01-30 16:42 juliensf Note Added: 0000626
2014-01-30 16:55 zs Assigned To => zs
2014-01-30 16:55 zs Status new => assigned
2014-01-30 17:06 zs Note Added: 0000627
2014-01-30 17:06 zs Status assigned => resolved
2014-01-30 17:06 zs Resolution open => fixed
2014-01-30 17:12 juliensf Note Added: 0000628
2014-01-30 17:46 zs Note Added: 0000629
2014-01-30 17:46 zs Status resolved => feedback
2014-01-30 17:46 zs Resolution fixed => reopened
2014-01-30 18:08 zs File Added: bug302.m
2014-01-30 18:14 zs Note Added: 0000630
2014-01-30 18:14 juliensf Note Added: 0000631
2014-01-30 18:26 zs Note Added: 0000632
2014-01-30 18:26 zs Status feedback => resolved
2014-01-30 18:26 zs Resolution reopened => fixed
2014-01-31 10:15 pbone Note Added: 0000633
+Issue History