Library coverage hangs

[Adrian Pop]

It seems that the coverage for some libraries hangs and the processes need to be killed manually.

Attached is the trace i got from one of the hanging processes on test.openmodelica.org by attaching to it with gdb. Maybe we can find out what the problem is.

[Adrian Pop]

Seems to hang in SimulationResultsCmp_compareResults after getData() is called.
The gdb trace was obtained running:

(gdb) set logging on
(gdb) thread apply all bt full
(gdb) bt full

[Adrian Pop]

This is the only change I see for SimulationResultsCmp_omc.c:
​https://github.com/OpenModelica/OMCompiler/commit/baef0588e890ef007cfb28322f564593fa43b30b
Could it be that we don't allocate enough for the str?

[Adrian Pop]

Doesn't seem that malloc size is the issue. As far as I can see getData calls malloc which fails and then a signal handler is called #15 <signal handler called> which somehow hangs.

[Adrian Pop]

As far as I can tell the problem is with read_matlab4.c function dymolaStyleVariableName

That function is called with a name already in dymola format from the SimulationResultsCmp_compareResults via getData().
So you get a string like:

world.y_label.lines[2, 2, 1]

and you get back a string like:

world.y_label.lines[2,  ,,  1]

and also the size of i is wrong which makes the free(dymolaName) go bad.

[Martin Sjölund]

Which result-file did you run this on? I tried running one of the examples that hang on the testing script, but it works just fine on my machine in valgrind, gdb, and just running it in the shell.
I think I should just change it to not move commas instead, and rather do a white-space insensitive sorting.

[Adrian Pop]

Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulumInitTip.mos from MSL 3.2.1 for example.