SEGV in compileArgument() during build while processing docs(?) #1107
Comments
|
Thanks for the report. First step seems to try using version 9.0.4. Lots of issues where fixed since. If that still crashes try using the debug build ( |
|
Thanks for the hint. This uncovers a new (undocumented?) dependency: I'll rummage around and see where I can satisfy it. |
|
Part of GNU emacs. If this file does not exist however, it should simply not try to compile the sweep package. See packages/sweep/CMakeLists.txt |
|
Yes. Part of the problem is I'm trying to fit this into NetBSD's pkgsrc, and even though I have emacs installed, and cmake possibly detects that, the actual build happens in a restricted environment where the required packages have to be "properly declared". Trying to sort out what the magic is. For now I've hacked the given CMakeLists.txt file to get around this hurdle for now. |
|
It looks like this bug is also present in 9.0.4, ref: |
|
Hmm. Doesn't make much sense to me. This code has been in use for many years with many different compilers and executed using valgrind, AddressSanitizer, etc. I'd first try to build using the |
Did that, and, annoyingly, this doesn't reproduce the problem. Not sure that made it that much easier for me, but probably good news at your end. Or... Maybe not. I built Need to tweak the build to produce debug info by default, and re-do, to |
|
Gets nasty. Yes, two compilers doing it wrong sounds unlikely. Alignment issues come to mind. On the other hand, we also have arm, which passes for 32 and 64 bits (Linux). Note that we also have Debian which passes all platforms including ppc AFAIK. Debian testing is at gcc 12 though. I guess some good old print statements may shine some light ... Use Sdprintf() that otherwise has the same signature as printf() (with some extensions) to print debug output. Please keep me posted. |
|
The debug with Will dig out details later. |
|
Here's a bit more about what this is about: Looks like a "simple" null pointer de-reference, but ... why would the "modules" not be filled with actual data? |
|
Rather odd. Thread 2 is the global object (atom,clause) garbage collector thread. This looks like the startup of this thread, trying to find the predicate to call. The module table is shared and must already have been created long before by the main thread. So, this makes no sense unless something writes to the wrong address. The way forward is probably to run under gdb, set a breakpoint at the place the table is created (pl-modul.c:292 in de dev source) and then a hardware watchpoint on PL_global_data.tables.modules. Looks like there is something fundamentally wrong with this platform. I vaguely recall there were issues in the POSIX thread implementation of NetBSD that caused problems with SWI-Prolog, but that is rather long ago. What is the issue in thread 1? Is PC invalid? Or is it decode() which does a lookup in a global array. The == test can't crash 😄 That too is pretty weird for running a simple Prolog program. I don't think I've ever seen fetchop() crash. |
|
I beleive I have news on this. It turns out that since I do this build on a dual-CPU macppc, I also did the build with "make -j 2". However, it now looks like the build setup of swi-prolog has not made all inter-dependencies between the different build steps explicit, so that this is safe. I have now done a build with gcc 12, which initially crashed, and setting pkgsrc's |
|
Thanks for all the work. Concurrent dependency issues are not that likely to cause this. It doesn't match the crashes and concurrent builds are used on almost all platforms these days. What is more likely is that we are dealing with internal thread issues that become apparent because you run two make jobs, which typically leads to more than 2 threads. No this has also been tested in many extreme scenarios. I'm not claiming there is no bug related to thread synchronization, but this is rather extreme. Especially the lost module table is really weird. What happens on |
Trying to build swi-prolog on NetBSD/macppc 10.0_BETA fails, with the following process getting a SEGV:
It wasn't particularly easy to find how to configure it for a debug build, but I managed to hack it to produce a debug version eventually.
The GDB session reveals that it looks like it's trying to store into unmapped memory(?)
The text was updated successfully, but these errors were encountered: