-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with LTL traces in MT context #209
Comments
Here is a trace showing the issues :
So with one thread it seems good, 8 thread is not. Also note we went into the NONPROGRESS CYCLE case. |
A trace for 8 threads : incorrect file produced
|
Ok so some follow up examples, this one produces a GCF that ltsmin-printtrace will crash on. It's as small as I could make it, we have a lasso in 2 states : initial -> s1 -> initial Unfortunately, the code in here : https://github.com/utwente-fmt/ltsmin/blob/master/src/pins2lts-mc/algorithm/dfs-fifo.c#L63-L105 Is incorrectly building a trace with 4 elements instead of just 2. I'm starting to use "-ufscc" to bypass this dfs-fifo code. So there is a more general issue with the traces I think, I tried all search strategies, this is what I obtain : Here are current results (SINGLE THREAD)
The results are more bleak with 8 threads :
So, I'm using ufscc as search strategy for now. Attached are reproduction files (same compilation as in the first message of the thread). There are also logs of running with the various strategies. |
Hi, |
Hi, thanks for using (single threaded) and thanks for reporting the issues (mainly in multi-threaded). Meanwhile, LTSmin has grown quite a bit, supporting multiple action labels and state labels, and creating multi-core computations. Also, it was decided to reuse the gcf-format also for storing traces (since they are a special form of state spaces). I'm afraid the gcf-support is somewhat lacking behind on these newer developments. And - as you demonstrated - several combinations of use-cases with gcf are not properly tested. Any contributions on these are much appreciated. |
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 :
ltsmin/src/pins2lts-mc/algorithm/dfs-fifo.c
Line 104 in 3499bb5
We are coming from here :
ltsmin/src/pins2lts-mc/algorithm/dfs-fifo.c
Lines 123 to 127 in 3499bb5
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
ltsmin/src/pins2lts-mc/algorithm/ufscc.c
Line 725 in 3499bb5
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.
The text was updated successfully, but these errors were encountered: