Skip to content

Issues with LTL traces in MT context #209

Open
@yanntm

Description

@yanntm

Hi,
So I'm trying to get traces out of ltl, but the results are a bit random, and the files tend to be broken.

Attached model, when run with 8 threads, typically produces a gcf file with incomplete or completely wrong information, or even a corrupt gcf that subsequently crashes ltsmin-printtrace.
In particular resolution of edge labels seems bad, the states themselves are consistent.

I think the problem comes from this invocation :

find_and_write_dfs_stack_trace (ctx->model, s, true);

We are coming from here :

if (!is_progress && seen && ecd_has_state(loc->cyan, successor)) {
global->exit_status = LTSMIN_EXIT_COUNTER_EXAMPLE;
if (run_stop(ctx->run)) {
construct_np_lasso (ctx, successor);
}

Where we did set LTSMIN exit to signal but the barrier is not strong to ensure only one thread is still working.

Most other invocations to trace are much more heavily protected or delayed as in this instance :
https://github.com/utwente-fmt/ltsmin/blob/master/src/pins2lts-mc/algorithm/ltl.c#L77-L89

The call that was commented + the comment preceding it makes me think the issue has been met before. @alaarman Could we use the same kind of behavior for NonProgress cycles ? somehow print the trace with a single thread AFTER all threads have acknowledged the EXIT sign.

In other cases, there is also care taken, e.g. only master is working here

find_and_write_dfs_stack_trace (ctx->model, trace_stack, true);


Attached are a few test files
example.zip

Compile with 'gcc' -g '-c' '-I/home/ythierry/git/ITSTools/ltsmin/fr.lip6.move.gal.ltsmin.binaries/bin/include/' '-I.' '-std=c99' '-fPIC' '-O0' 'model.c';'gcc' -g '-c' '-I/home/ythierry/git/ITSTools/ltsmin/fr.lip6.move.gal.ltsmin.binaries/bin/include/' '-I.' '-std=c99' '-fPIC' '-O0' 'strat.c';'gcc' -g '-shared' '-o' 'gal.so' 'model.o' strat.o

Then I'm running this:
/home/ythierry/git/LTSmin-BinaryBuilds/ltsmin/src/pins2lts-mc/pins2lts-mc './gal.so' '--threads=1' '--when' '--ltl' '<>((LTLAPtower==true))' '--buchi-type=spotba' '-v' '--trace' 'trace.gcf'

So threads=1 works, threads=8 is mostly producing corrupt GCF file.

**

thanks for your insight, I'll keep investigating, but it's one of those subtle concurrency issues so not easy to fully diagnose, and I have the feeling that the solution has already been developed, just this call was not updated to honor it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions