Immediate SIGSEGV if not run from source dir or inside gdb

[D Gowers]

Steps to reproduce:

---

# make sure there are no stray files lying around..
sudo rm -r /usr/local/grafx2
git clone ​https://gitlab.com/GrafX2/grafX2.git
cd grafX2
make
cd src
sudo make install
cd ..
which grafx2-sdl
# 'which' should return /usr/local/bin/grafx2-sdl

grafx2-sdl
# should immediately give a message like '“grafx2-sdl” terminated by signal SIGSEGV (Address boundary error)'

gdb $(which grafx2-sdl)
# then type run
# grafx2 runs normally
# quit grafx2
# then quit gdb (enter 'q')

./bin/grafx2-sdl
# as with gdb; everything behaves normally

---

My suspicion is that this is a memory allocation bug related to the recent MAX_PATH_CHARACTERS changes.

Platform etc details:

• sdl versions and so on are still the same as the attachment to issue #111 indicates ( http://pulkomandy.tk/projects/GrafX2/attachment/ticket/111/47-54.png )
• Arch Linux x86_64; Linux 5.0.10-arch1-1-ARCH
• Spectrwm window manager, v 3.2.0 running on Xorg 1.20.4

Other details:

• Not sdl specific (I tested with API=x11 as well; same result)
• The md5sum of the installed binary is the same as the one in the bin/ directory (so the binaries really are identical)
• Does not depend on working directory... I *guess* this probably means it is dependent mainly on the particular path to the binary..
• Since gdb hides the problem, I'm not sure what else to try. Valgrind?

A working barebones setup:

---

# start in the top level directory of the grafx2 git clone, and execute this.
mkdir /tmp/g
cp -a bin/grafx2_sdl /tmp/g
mkdir -p /tmp/share/grafx2/skins
cp -a share/grafx2/skins/*DPaint* /tmp/share/grafx2/skins
/tmp/g/grafx_sdl
# gfx2def.ini is not required, despite the error message. Copying it in to /tmp/share/grafx2 does not effect the result other than removing the error message.
# the same applies to gfx2.png

---

It's curious that this particular snippet works, but hopefully the fact that it does work is informative somehow.

[D Gowers]

(as a side note -- I guess this is a minor Makefile bug -- gfx2.png is not installed by sudo make install on this platform -- it is only gfx2.gif that gets installed. Hence the 'gdb' invocation of grafx2 eventually complains that gfx2.png is missing. (but the non-gdb invocation does not; it appears to crash before any such message could be printed)

This may be useful in that it implies the crash described in this bug report must be occurring quite early -- before the check for gfx2.png is done.

Line 1184 of the Makefile is roughly where this sub-problem is.
)

[Thomas Bernard]

So it crashes when run directly but not when trying to debug it with GDB ?
running from /tmp/g/ works too ?

[Thomas Bernard]

can you run with the "-v" flag ? The debug output will help find when the crash is.

$ /tmp/usr/local/bin/grafx2-sdl -v
Failed to load icon /tmp/usr/local/bin/../share/grafx2/gfx2.png
Load_CFG() trying to load /home/nanard/.config/grafx2/gfx2.cfg
Load_INI() loading /home/nanard/.config/grafx2/gfx2.ini

[D Gowers]

To re-summarize:

• Case 1: ./bin/grafx-sdl : Works
• Case 2: grafx2-sdl or /usr/local/bin/grafx2-sdl : Crashes
• Case 3: /tmp/g/grafx2-sdl, after setting up as described above : Works

Invoking with the -v option does not give any debug output in case 2. Presumably this is because the crash occurs before any output is given. In fact, your own log shows this fact: the error about the missing PNG is the first message, but as I stated above, this error does not show for case 2; the crash occurs before this check for the PNG is made.

The other two cases give pretty normal looking debug output when run with -v.

[Thomas Bernard]

could you try the "crashing setup" with my branch ​https://gitlab.com/miniupnp/grafX2/commits/issue_115
I added some debug log in the init, to help locate the crash.

By the way, I'm building with CC=clang CFLAGS=-fsanitize=address LDFLAGS=-fsanitize=address OPTIM=0 make I don't know if it can help...

[Thomas Bernard]

SIGSEGV (Address boundary error) happens probably because we access memory after the end of a malloc'ed block. GDB change the way memory is managed, that could explain why the bug doesn't happen there.

[Thomas Bernard]

I added a few more debug log and improved the code regarding error handling (still in my issue_115 branch)

​https://gitlab.com/miniupnp/grafX2/commit/0eb715bd17b62f9dd0bf3ae09ccb801ec63cfe4a
​https://gitlab.com/miniupnp/grafX2/commit/9a8fca16933d0f1c92ba8d62ed82ea5ee42de6af

[Thomas Bernard]

I think the bug is caused by not setting a null terminating character in the string written by readlink()
most of the time there is a 0 that will save us, but if there is none, there will be a stack over-read.

​https://gitlab.com/GrafX2/grafX2/blob/master/src/setup.c#L116

cbc6b96639dad37c6b7ef037ae7b16a9bd7af450 should fix it.

@D Gowers : can you verify ?

[Thomas Bernard]

the bug was introduced in ​https://gitlab.com/GrafX2/grafX2/commit/54317d94aef5d2f648eef5915a23b48b9679c229
that's quite a long time ago ;)

[D Gowers]

Yes, commit cbc6b96639dad37c6b7ef037ae7b16a9bd7af450 seems to fix it. I've tested all cases -- they all work, no crash.

[Thomas Bernard]

​https://gitlab.com/GrafX2/grafX2/merge_requests/199