#3741 SDCC crash while compiling (SIGSEGV)

[bbbbbr]

sdcc -v
SDCC : z80/sm83/mos6502/mos65c02 TD- 4.4.1 #14878 (Linux)
published under GNU General Public License (GPL)

Built with: Ubuntu 20.04, libboost1.71-dev

Getting a crash when building some code. The crash doesn't happen with versions 14635 and 14865. Not sure if it is port specific, but it looks like it at least happens for sm83 and z80.

I've reduced it to a fairly minimal example (attached).

sdcc -msm83 --no-std-crt0 --fsigned-char --use-stdout -Wa-pogn -c test.c -o test.o
Caught signal 11: SIGSEGV

[bbbbbr]

Looks like Win x64 and x32 builds do not crash on Windows 10 for the same scenario. So might be Linux only so far.

[Philipp Klaus Krause]

Hmm, I just tried with current trunk on my Debian GNU/Linux testing amd64 laptop, and could not reproduce the problem. valgrind doesn't find anything either.

In [r14880], I added a regression test that should be able to reproduce this bug, so we'll see if the issue can be reproduced on some machines in the compile farm.

[Philipp Klaus Krause]

On one machine in the farm, the Fedora one, the segfault can be observed according to snapshot results.

[bbbbbr]

Thanks for the update, glad you got a repro!

[bbbbbr]

Thanks. Just for reference:

Linux Mint 21.3 Cinnamon
$ uname -a
Linux 5.15.0-105-generic #115-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux

I just got another crash building a different project that usually builds without issue.

SDCC Snapshot builds:

• I don't get the crash building the repro test when running this build from the SDCC snapshot page:
  sdcc-snapshot-i386-unknown-linux2.5-20240604-14879.tar.bz2
  However it looks like the Linux x64 builds are empty except for a couple docs right now(?) so I'm not able to try those.

The build I'm using is the one below which we (gbdk) compile on github using their runners:
sdcc-14878-Linux-x64.tar.gz
https://github.com/gbdk-2020/gbdk-2020-sdcc/releases/tag/sdcc-patched-gbdk-4.3.0

If nothing turns up for the compile farm or for other people I can try tracking it down in more detail on my end.

[Erik Petrich]

I've been looking at this problem for nearly 2 weeks. This looks like a problem triggered in some versions of the boost library remove_vertex() function. If the vertices are renumbered, valgrind detects several use after free bugs which then either terminates with SIGSEGV from following a bad pointer or causes SDCC to generate code with bad stack offsets because the stack conflict graph has been mangled. I'm not yet sure if the bug is in the boost code itself or in how gcc is compiling it, but I have fixed the problem on the Fedora compiler farm system (generates our 64-bit Linux and Windows snapshots) by switching from boost 1.75 to 1.81. I picked 1.81 only because it was the version installed on my main development system and it seemed to be working (including no valgrind errors other than the known memory leaks).

@bbbbbr, if possible try a newer boost version and see if that also fixes the problem for you?

[Philipp Klaus Krause]

I suspect this is a duplicate of [bugs:#3771], in which case this is a boost bug.

[Maarten Brock]

I also saw this problem with Ubuntu 22.04 LTS. There the natively installed libboost-graph-dev is v1.74.
Then I tried on Ubuntu 24.04 LTS and this problem went away due to the newer libboost-graph-dev v1.83.
But Ubuntu 24.04 LTS also comes with GCC 13.2.0 which fails on regression test wchar_test_wcharstringnorestart,
This did not fail with GCC 11.4.0 on Ubuntu 22.04 LTS.

[Maarten Brock]

gen/host/wchar/wchar_test_wcharstringnorestart.bin  > results/host/wchar/wchar_test_wcharstringnorestart.out
Aborted (core dumped)

It turns out that _FORTIFY_SOURCE==2 is no longer the default for GCC on Ubuntu, but has been changed to _FORTIFY_SOURCE==3 when optimization is enabled.
So the exception made in wchar.c.in is no longer triggered.

[Maarten Brock]

I just found out that the bug in boost was fixed in version 1.79.

[Philipp Klaus Krause]

I that case, we can close this ticket, since we currently require boost >= 1.81.0 (but != 1.85.0) for compiling trunk.

[bbbbbr]

Looks good.

Confirming that the dependency check blocks the default boost 1.71.0 as expected on Ubuntu 20.04 and 22.04.

Forcing install of boost 1.81 passes dependency checks and the resulting build does NOT crash when building the test.c example.