Looks like it Can’t do much without a program to reproduce, so if you can share that? If not, the best you can do is to rebuild Prolog with AddressSanitizer and hope it finds something useful.
Note that we can help to fix this commercially with NDA for sharing code, etc. Just contact me privately or bugs@swi-prolog.org. My first hint would be AddressSanitizer or valgrind. That might give a message that gives a clue.
Which platform are we talking about? How did you install/build SWI-Prolog?
I think this might be related to the problem I reported earlier: Dynamic subsumptive table/1 predicate - #9 by alanbur, I’m using maplist + >> lambdas in this case as well and there are some similarities in the stack traces. If I replace all the lambdas in the maplist calls that fail with helper predicates, the problem goes away. And in this version of the app, some of the predicates that fail when compiled aren’t tabled which suggests that tabling likely isn’t a factor.
However I have other maplist + >> usages that don’t fail when compiled, which suggests it might be difficult to get a reproducible test case.
I suspect the SEGV may be a consequence of the initial maplist + >> failure, which is corrupting something somewhere which eventually triggers the SEGV, so I think seeing if AddressSanitizer can pick up anything during that initial failure is the best course of action. But I have a deadline to meet, so that will have to wait…
Linux, git clone + local build. I’ve tried valgrind but it looked like the heat death of the universe will have happened before the app got to the point of failure.
As I said in my earlier post, I’ll see if I can get AddressSanitizer going, but I’ve not used it before, so I’ll need to find & read the cooking instructions first
For now I have a workaround, which is s/>>/helperPredicate/
mkdir build.asan
cd build.asan
../scripts/configure
<confirm>
ninja
Now use .../swipl[-devel]/build.asan/src/swipl[-win] instead of swipl[-win] and hope for a crash with a detailed report. The Asan version is 2-3 times slower than the optimized version, which is a lot better than valgrind. They roughly capture the same issues, but sometimes one does the job better than the other.
Lambda (>>) generates different code when compiled (there have been various discussions of this) and maplist changes depending on whether you use library(apply_macros) is used, so if you run listing/1 on the predicates in question, you might get a hint as to where the problem is.
Ahah, I think that’s a key bit of info - I was going to ask if there was any difference between interpreted & compiled, because I wasn’t sure. and yes, I’m using apply_macros. I’ll temporarily drop that and see if it makes a difference, and I’ll investigate listing/1 as well - Thanks!
Here’s one discussion I found (I’m pretty sure there were others … you can try searching for “yall” or “lambda”:
tl;dr: library(yall) doesn’t know about other expansions, such as for dicts, so the generated code can be different than what you expect (and there are differences between lambdas in compiled code versus in interpreted code (inside a call/1)). So, it’s worth using listing/1 to see what term expansion did with your code.
This doesn’t account for the SEGV, of course – that shouldn’t happen under any circumstations.
W.r.t. library(yall), make sure to load library(apply_macros) and library(yall) explicitly and use listing/1 to verify that the code is compiled. Interpreted yall Lambda expressions are (very) slow and have different semantics w.r.t. variables shared with the remainder of the clause. It is a bit of a fragile library
library(lambda) by Ulrich Neumerkel (floating around as pack and on the internet) is more robust, but has an even uglier syntax and is not compiled AFAIK. Lambdas and Prolog don’t go together well as long as Prolog is untyped and homoiconic (source code is data) …
I understand the comment about lambdas & prolog but mostly I’m using them for things like collecting and iterating over data to produce formatted output. In those cases they are more convenient and IMHO easier to grok than having separate helper predicates.
The issue is that dict-dot expansion can be hoisted out of a lambda when compiled, the easiest way to check is to use listing/1 on the predicate. If you see something of the form .'(A, b, C), before the maplist (or similar) call rather than within it, then that’s the issue.
I suspect the root cause was the lambda-hoisting issue and the SEGV was secondary. I 've addressed the lambda issue and I haven’t been able to come up with a simple reproducer for the SEGV. I’ll therefore mark this thread as “answered” and start a new one if it happens again.
I’m interested in reproducible code that generates a SEGV as that is pretty much always a bug. But yes, Lambdas, high order predicates and functional notation can lead to surprising results. I’m afraid this cannot be resolved in Prolog.
I’ll circle back when I have time but the code has changed a lot and I’ve not seen the SEGV since. Using dict ‘dot’ notation in conjunction with lambdas seems fraught, for example BUG: internal error in GUI debugger - #5 by alanbur looks like it might be yet another bad interaction between the two?
Can’t do much without a program to reproduce, so if you can share that? If not, the best you can do is to rebuild Prolog with AddressSanitizer and hope it finds something useful.