[m-users.] uncaught Mercury exception using mdprof_create_feedback

[Paul Bone]

On Sun, Sep 28, 2014 at 04:35:17PM +0200, Matthias Guedemann wrote:
> Dear all,
> 
> I am using mmc version 14.01.1, trying to use the implicit parallelism
> feature.
> 
> My program looks roughly like this:
> 
> ,----
> | main(!IO) :-
> |     ...
> |     (( prepareGraph(E1),
> |        G1 = createGraph(E1),
> |        R1 = analyseGraph(G1)),
> |      ( prepareGraph(E2),
> |        G2 = createGraph(E2),
> |        R2 = analyseGraph(G2)),
> |      ( prepareGraph(E3),
> |        G3 = createGraph(E3),
> |        R3 = analyseGraph(G3))
> |     ),
> |     ...
> |     some IO on results
> `----
> 
> This works without problems, I can also execute the three independent
> conjunction groups using parallel-AND in the asm_fast.par.gc.stseg grade
> with 300% CPU usage. But when I use
> 
> % mmc --deep-profiling --profile-for-feedback
> 
> mdprof_create_feedback chokes on the created Deep.data file. I always
> get the error:
> 
> ,----
> | Uncaught Mercury exception:
> | Software Error: measurements: predicate `measurements.check_total_calls'/3: Unexpected: TotalCalls \= CallsA + CallsB
> | Stack dump not available in this grade.
> `----
> 
> when using
> 
> % mdprof_create_feedback --implicit-parallelism Deep.data feedback.data
> 
> What am I doing wrong?
> 

Hi Matthias

I've now had a look and found the problem.  As we thought, it's not your
fault at all.  Unfortunatly there's nothing you can do to work around it.

I'd like to attempt to explain what's happening, this may be pretty detailed
so feel free to ignore it, I'm mostly explaining this to myself :-).

The autoparallelisation analysis scans your whole program for places where
parallelism could help (it skips parts of the program where it's obvious
that it won't help).  It crashes when it looks in
euler_81_82_83_problem_set.euler_edge_81/4 which is nondeterminisic.  It
tries to calculate the cost of every goal including the disjunction as a
whole, however it assumes that the disjunction is either a switch or a
"semidet disjunction" which is another special case.  This incorrect
assumption causes the analysis to crash (because a consistency check fails).
It might be possible to comment out the consistency check, but then I'd be
concerned that something else would crash because of the same faulty
assumption.  I'll see if I can fix the bug in the next week or so.

Thanks for sending the bug report, I've put it in the bugtracker:
https://www.mercurylang.org/bugs/view.php?id=364



-- 
Paul Bone