Any idea how to debug this?
This happens consulting a quite large program.
Thanks,
Roberto
First, upgrade to 9.2.7. The stable series should be fully compatible and some behavior that is formally undefined in C has been fixed recently, mostly thanks to @mgondan1. Otherwise I see little option as to use llgb to get a stack trace. That may give some hint. If it happens consistently during loading it should be possible to find.
Thanks Jan. The issue reproduces 100% of the times. We will first upgrade to 9.2.7 and, if the issue is still present, we will try to obtain a stack trace.
Hmm… is the following of any use?
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x000000010126f2b9
frame #1: 0x00000001010058b0
(lldb) list
(lldb) l
137 force_malloc_dependency();
138
139 if ( !PL_initialise(argc, argv) )
140 PL_halt(1);
141
142 for(;;)
143 { int status = PL_toplevel() ? 0 : 1;
144
145 PL_halt(status);
146 }
(lldb) f 1
frame #1: 0x00000001010058b0
-> 0x1010058b0: outsb (%rsi), %dx
0x1010058b1: outsl (%rsi), %dx
0x1010058b2: subb %ah, %gs:0x75(%rdx)
0x1010058b7: imull $0x2900296e, 0x69(%rsp,%rsi,2), %ebp ; imm = 0x2900296E
(lldb) l
147
148 return 0;
149 }
150
151
152 /*******************************
153 * AddressSanitizer support *
154 *******************************/
155
156 /* Clang way to detect address_sanitizer */
(lldb)
BTW, this is on SWI-Prolog 9.2.7. Fearing a compiler bug, we also upgraded to GCC 13, to do so we had to add the following fragment at the very beginning of pl-apple.c:
/* Neutralize the availabiliy attribute, which is misused by
the Apple SDK. */
#define availability availability_attribute_disabled
Is this in Intel Apples? Could you give the full cmake commandline? I do build the stable releases for MacOS using gcc on Intel. That does not seem to be a problem. See scripts/make-distribution for the options passed. This also doesn’t seem to have any relation to a big program as it crashes right at the beginning.
I recall such issues when trying to build against libGMP.
The issue was caused by a bug in PCRE2 version 10.43, which, apparently, was fixed in version 10.44. Thanks!
? The crash seems to be really at the start. That does not hint at pcre which is loaded dynamically, no? Or, is this about embedding SWI-Prolog in a system using pcre?
Consulting the application involved the compilation and execution of PCRE2 regular expressions. Eventually, we could reproduce the issue in a way that is completely independent from the application as follows:
$ swipl
Welcome to SWI-Prolog (64 bits, version 9.2.7)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit https://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word)
.
1 ?- load_foreign_library(pcre4pl).
true.
2 ?- regcomp(x, [], A, B).
A = 105553182736384,
B = 0.
3 ?- regexec(105553182736384, y, 0, A, B, C).
SWI-Prolog [thread -2 (main) at Thu Sep 12 15:18:31 2024]: received fatal signal 4 (ill)
C-stack trace labeled "crash":
[0] save_backtrace() at pl-cstack.c:335 [0x10830b278]
[1] print_c_backtrace() at pl-cstack.c:909 [0x10830b9fc]
[2] sigCrashHandler() at pl-cstack.c:949 [0x10830bb36]
[3] dispatch_signal() at pl-setup.c:579 [0x1082392a5]
[4] pl_signal_handler() at pl-setup.c:617 [0x10823951a]
[5] _os_lock_handoff_lock_slow() at [0x7ff803893dfd]
[6] PL_reset_term_refs___NOLD() at pl-fli.c:483 [0x1082c9530]
Prolog stack:
[12] regexec/6 <foreign>
[11] $toplevel:toplevel_call/1 [PC=3 in clause 1]
[10] $toplevel:stop_backtrace/2 [PC=4 in clause 1]
[9] $tabling:$wfs_call/2 [PC=17 in clause 1]
[7] $toplevel:$execute_goal2/3 [PC=31 in clause 1]
[5] $toplevel:$query_loop/1 [PC=35 in clause 2]
[4] system:setup_call_cleanup/3 [PC=5 in clause 1]
[3] $toplevel:$query_loop/0 [PC=30 in clause 1]
[2] $toplevel:$runtoplevel/0 [PC=19 in clause 1]
[1] $toplevel:$toplevel/0 [PC=3 in clause 1]
[0] system:$c_call_prolog/0 [PC=0 in top query clause]
Running on_halt hooks with status 132
Killing 55080 with default signal handlers
$
This doesn’t seem to be library(pcre), but instead it’s part of XPCE? (that’s where I found regexec.c, which is (c) Henry Spencer 1998,1999.
There is a POSIX-style API to pcre2, but it uses different function names: pcre2posix specification and, as far as I know, these aren’t used in library(pcre).
I couldn’t find where regcomp/4 or regexec/6 are defined and their entry points aren’t in pcre4pl.so (I’m using the “development” version of SWI-Prolog, so perhaps this is something that only the “stable” version has?).
Sorry, I should have clarified that pcre4pl was developed by us.
Is there a reason that you’re using your own pcre4pl instead of library(pcre)? [I updated library(pcre) to use pcre2 over 2 years ago; I tried to add support for all its options, although there are some known missing pieces.]