Mercury Bugs - mercury
View Issue Details
0000478mercuryBugpublic2019-04-17 23:062019-04-18 05:27
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000478: ssdb directory does not build in csharp grade with commit 0d667a7
DescriptionCompilation of the ssdb directory aborts in the csharp grade with commit 0d667a7 (i.e. what would have been rotd-2019-04-17).

gmake[1]: Entering directory `/mnt/opturion/jfischer/mercury-4.git/ssdb'
../Mmake.common:469: warning: undefined variable `mer_ssdb.mhs'
../Mmake.common:472: warning: undefined variable `mer_ssdb.mhs'
../Mmake.common:478: warning: undefined variable `mer_ssdb.os'
/tmp/mmake.og2WZB:930: warning: undefined variable `mer_ssdb.ms'
/tmp/mmake.og2WZB:942: warning: undefined variable `mer_ssdb.ms'
/tmp/mmake.og2WZB:1324: warning: overriding recipe for target `realclean_local'
/tmp/mmake.og2WZB:978: warning: ignoring old recipe for target `realclean_local'
{ echo MCFLAGS += '--grade csharp --options-file ../Mercury.options --mercury-linkage shared --flags SSDB_FLAGS --allow-stubs --no-warn-stubs --use-subdirs '; echo MCFLAGS += ' '; echo CFLAGS += ' '; echo JAVACFLAGS += '-J"-Xmx1024m" '; echo CSCFLAGS += ' '; echo C2INITARGS += ' ../library/mer_std.init ../runtime/mer_rt.init '; echo MLLIBS += ' -lmer_std '; echo MLOBJS += ' '; echo LDFLAGS += ' '; echo LD_LIBFLAGS += ' '; echo EXTRA_LIBRARIES += ''; echo EXTRA_LIB_DIRS += ''; echo LIBGRADES = 'asm_fast.gc asm_fast.gc.debug.stseg asm_fast.gc.debug.trseg.stseg asm_fast.gc.decldebug.stseg asm_fast.gc.memprof asm_fast.gc.prof asm_fast.gc.profdeep.stseg asm_fast.gc.trseg asm_fast.par.gc.stseg csharp hlc.gc hlc.gc.trseg hlc.par.gc java '; echo INSTALL_PREFIX = '/usr/local/mercury-DEV'; echo LINKAGE = 'shared'; echo MERCURY_LINKAGE = 'shared'; } | /mnt/opturion/mercury/rotd-2019-04-17/bin/mmc --make --options-file - libmer_ssdb
Making Mercury/int3s/mer_ssdb.int3
Making Mercury/int3s/ssdb.int3
** Error reading file `mdb.browse.m' to generate dependencies.
** Module `mdb.browse' is imported or included by module `ssdb'.
mercury_compile: cannot find source for module `mdb.browse' in directories `.'
gmake[1]: *** [libmer_ssdb] Error 1
gmake[1]: Leaving directory `/mnt/opturion/jfischer/mercury-4.git/ssdb'
gmake: *** [ssdb] Error 2
TagsNo tags attached.
Attached Files

Notes
(0001024)
juliensf   
2019-04-17 23:20   
Ditto for the Java grade. The issue is not present in rotd-2019-04-16.
(0001025)
zs   
2019-04-17 23:23   
The problem was probably triggered by commit df47de186bf59c8c97010455c29c7ad765bfa3da,
but that was on March 31. So two things that may be
worth looking into are (a) why hasn't been a problem
in the last two weeks, and (b) why isn't this a problem
in other grades?
(0001026)
zs   
2019-04-17 23:25   
It seems our notes crossed paths. If the problem was not present
in rotd-2019-04-16, then the March 31 commit could not have been
the cause.

What was the last commit present in rotd-2019-04-16?
(0001027)
juliensf   
2019-04-17 23:35   
rotd-2019-04-16 was commit b70bdb2d9557ccc3f62abbc291a25dbc2f8dfc23.
(FYI, commit ids for all rotds are listed on the download page.)

The obvious point of difference between the csharp / java grades and the others is that the former
are compiled using --use-mmc-make.

(0001028)
zs   
2019-04-17 23:54   
There has been only one commit since, and that was a refactoring that should have had
only one change that could cause a change in behavior: the addition of this sanity test
in modules.m:

expect(unify(ModuleName, ParseTreeModuleName), ...)

Does the problem still occur if this is taken out? I can't check since my machine
does not have C#. (I will get a new laptop soon, which will get C# and Java.)
(0001030)
juliensf   
2019-04-18 00:55   
Yes, the problem still occurs if that check is taken out.
(0001031)
juliensf   
2019-04-18 01:00   
Annoyingly I can't check if the same issue occurs with --use-mmc-make and the C grades since
we have some problem there with the .mh files in the browser directory not being created, specifically
when we got to compile the trace directory:

    ./scripts/mgnuc --grade asm_fast.gc --c-debug --no-ansi -- -I. -IMercury/mihs/. -c mercury_trace_browse.c -o mercury_trace_browse.o
mercury_trace_browse.c:28:25: fatal error: mdb.browse.mh: No such file or directory
(0001032)
juliensf   
2019-04-18 01:13   
Actually the issue with the trace directory is likely a manifestation of the same problem since building with --use-mmc-make works fine in asm_fast.gc with rotd-2019-04-16. (The C# and Java grades skip over the trace directory which is why the problem shows up in different places.)
(0001033)
zs   
2019-04-18 01:16   
I just found and fixed a cut-and-paste bug. I think it should fix bug 478.
Please try it out.

By the way, testing proposed bug fixes for bugs with --use-mmc-make have
always been harder for me than testing for fixes for other kinds of bugs.
For other bugs, I build the maybe-fixed executable in a workspace, and use
a wrapper around lmc to try it out. But the lmc script sets up the environment
only for compilations that do NOT use --use-mmc-make, so this does not
work for --use-mmc-make bugs.

Since I don't use --use-mmc-make frequently, this is rarely a problem for me.
Since you use the Java and C# grades reasonably regularly, I expect it would be
more of a problem for you. How do you handle it?
(0001034)
juliensf   
2019-04-18 01:43   
I've just restarted the ROTD build, so we'll know in a bit.

Generally, if I'm working on stuff related to the C# and Java grades I just install the whole system
and and work with that. (Once it is installed you can do an install from within the compiler directory if,
for example, the work is related to the compiler.) That's obviously not a great solution and I suspect it's only bearable because I have access to machines with lots of cores and lots of memory, so parallel builds at -j8 or more are feasible.
(0001035)
zs   
2019-04-18 01:48   
That is what I do as well.

The reason why I don't find it satisfactory is not the CPU workload,
but the context switch overhead. I have to switch to doing something else
while waiting for the install, and switch back later when it is complete.
This wipes out details held in my brain's short term memory, requiring
them to the rebuilt later (and maybe again and again).

I was hoping you, or someone else who works with --use-mmc-make more than me,
would have found it less work in the long term just to teach lmc about --use-mmc-make.
(0001036)
juliensf   
2019-04-18 02:55   
The fix worked.
(0001037)
zs   
2019-04-18 05:27   
Fix committed

Issue History
2019-04-17 23:06juliensfNew Issue
2019-04-17 23:20juliensfNote Added: 0001024
2019-04-17 23:23zsNote Added: 0001025
2019-04-17 23:25zsNote Added: 0001026
2019-04-17 23:35juliensfNote Added: 0001027
2019-04-17 23:35juliensfNote Edited: 0001027bug_revision_view_page.php?bugnote_id=1027#r50
2019-04-17 23:54zsNote Added: 0001028
2019-04-18 00:55juliensfNote Added: 0001030
2019-04-18 01:00juliensfNote Added: 0001031
2019-04-18 01:13juliensfNote Added: 0001032
2019-04-18 01:16zsNote Added: 0001033
2019-04-18 01:43juliensfNote Added: 0001034
2019-04-18 01:48zsNote Added: 0001035
2019-04-18 02:55juliensfNote Added: 0001036
2019-04-18 05:27zsAssigned To => zs
2019-04-18 05:27zsStatusnew => resolved
2019-04-18 05:27zsResolutionopen => fixed
2019-04-18 05:27zsNote Added: 0001037