2024-11-21 23:34 AEDT
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000478mercuryBugpublic2019-04-17 23:062019-04-18 05:27
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
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

-Relationships
+Relationships

-Notes

~0001024

juliensf (administrator)

2019-04-17 23:20

 Ditto for the Java grade. The issue is not present in rotd-2019-04-16.

~0001025

zs (developer)

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 (developer)

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 (administrator)

2019-04-17 23:35

Last edited: 2019-04-17 23:35

View 2 revisions

 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 (developer)

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 (administrator)

2019-04-18 00:55

 Yes, the problem still occurs if that check is taken out.

~0001031

juliensf (administrator)

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 (administrator)

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 (developer)

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 (administrator)

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 (developer)

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 (administrator)

2019-04-18 02:55

 The fix worked.

~0001037

zs (developer)

2019-04-18 05:27

 Fix committed
+Notes

-Issue History
Date Modified Username Field Change
2019-04-17 23:06 juliensf New Issue
2019-04-17 23:20 juliensf Note Added: 0001024
2019-04-17 23:23 zs Note Added: 0001025
2019-04-17 23:25 zs Note Added: 0001026
2019-04-17 23:35 juliensf Note Added: 0001027
2019-04-17 23:35 juliensf Note Edited: 0001027 View Revisions
2019-04-17 23:54 zs Note Added: 0001028
2019-04-18 00:55 juliensf Note Added: 0001030
2019-04-18 01:00 juliensf Note Added: 0001031
2019-04-18 01:13 juliensf Note Added: 0001032
2019-04-18 01:16 zs Note Added: 0001033
2019-04-18 01:43 juliensf Note Added: 0001034
2019-04-18 01:48 zs Note Added: 0001035
2019-04-18 02:55 juliensf Note Added: 0001036
2019-04-18 05:27 zs Assigned To => zs
2019-04-18 05:27 zs Status new => resolved
2019-04-18 05:27 zs Resolution open => fixed
2019-04-18 05:27 zs Note Added: 0001037
+Issue History