#18 Crash when leaving race

[Botond István Horváth]

Whenever I leave a race by the restart race or abandon race buttons, or by ending the race the program stops. If I started it via a terminal I get the message:
... <<< /usr/local/lib/torcs/modules/simu/simuv2.so unloaded <<< *** buffer overflow detected ***: terminated /usr/local/bin/torcs: line 53: 2102113 Aborted (core dumped) $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*
I the version is 1.3.8 (commit 6cf3ec... (HEAD, tag: v1.3.8))
I built it with ./configure --enable-debug make sudo make install sudo make datainstall
OS: Linux mint 22.1
Gcc version: 13.3.0
If I don't enable debug mode I get less output but still a buffer overflow.

If any other info helps, like there should be a details log somewhere please tell me where do I find it.

Edit: I have tried to create a pull request that solves it. If you didn't get it please tell me how can I upstream the fix. (it is a 1 line fix in torcs/src/linux/linuxspec.cpp)

[Bernhard Wymann]

Hi. I did not receive it. Wonder was this was, becuase I cannot reproduce it on my SuSE 15.6.
Kind regards, Bernhard.

[Lino Banfi]

hi, sorry for barging in your discussion.
just wanted to say that i have the same problem, bur it shows only when compiling in release mode (eg: using "-O3" and "-g0" parameters when configuring with ./configure).
if compiled in debug mode (-O0 -g3) the problem doesn't show.
i will try both your solutions.

[Botond István Horváth]

The easyest way is maybe if I write the change down here than.
In the file torcs/src/linux/linuxspec.cpp at line 461 change from

strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize); /* cut .so */

to strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize-(strlen(dname) - 3)); /* cut .so */

This is needed because strncpy wants to fill the rest of the space with binary zeros, and seence we started at the(strlen(dname) - 3) th index we don't have soNameSize memory allocated after that.

I don't know why you couldn't reproduce (different standard libs maybe?)
Note: the first 12 extra 0-s actually don't cause problems, only when the OS or the lib checks for buffer overflows, because you don't use the lastSlash painter anymore and you set i to 0 anyway. and after that there is empty space on the stack so maybe it is never a problem, only when checked? I'm not 100% sure abut the last statement.

[Bernhard Wymann]

Cool. Btw. I think this is a funny one, because I guess the code is actually not needed at all, I wonder if it is some legacy thing. I checked if there is any symbol which could be resolved by this in my torcs installation:

find . -name .so; do nm -D $f | grep Shut; done

I get this (not a single match):
00000000000043c0 T _Z10ReShutdownv
U _Z13GfScrShutdownv
0000000000008ce0 T _Z14ReHookShutdownv
0000000000007890 T _Z15ReEventShutdownv
0000000000008a30 T _Z16ReScreenShutdownv
U _Z23RmShutdownLoadingScreenv
0000000000007b10 T _Z23RmShutdownLoadingScreenv
0000000000003bd0 T _Z15RtTelemShutdownv
U _Z13GfScrShutdownv
0000000000003fe0 T _Z14GfParmShutdownv
000000000000b270 T _Z13GfScrShutdownv
U _Z13GfScrShutdownv
000000000005d3e0 T _Z15grShutdownScenev
0000000000061600 T _Z15grShutdownSmokev
0000000000075610 T _Z15grShutdownSoundi
000000000005efd0 T _Z15grShutdownStatev
000000000004dfe0 T _Z18grShutdownBoardCarv
0000000000064ae0 T _Z19grShutdownSkidmarksv
0000000000000fb0 T _Z11TlmShutdownv
0000000000002290 T _Z13TrackShutdownv
000000000000c470 T _Z11SimShutdownv
000000000000ed60 T _Z17SimEngineShutdownP4tCar
0000000000014b00 T _Z21SimCarCollideShutdowni

So I guess you can remove all this code, please give me feedback if this does the trick:
lastSlash = strrchr(curMod->sopath, '/');
if (lastSlash) {
strncpy(dname, lastSlash+1, soNameSize);
} else {
strncpy(dname, curMod->sopath, soNameSize);
}
strncpy(&dname[strlen(dname) - 3], "Shut", soNameSize); / cut .so /
if ((fModShut = (tfModShut)dlsym(curMod->handle, dname)) != NULL) {
GfOut("Call %s\n", dname);
fModShut();
}

I will try it later this week myself, including removing the tfModShut stuff.

Cool stuff, kind regards
Bernhard

[David Bears]

Note: the first 12 extra 0-s actually don't cause problems, only when the OS or the lib checks for buffer overflows, because you don't use the lastSlash painter anymore and you set i to 0 anyway. and after that there is empty space on the stack so maybe it is never a problem, only when checked? I'm not 100% sure abut the last statement.

On many systems, the stack grows downward, so overflowing the buffer could corrupt previous stack frames. How much damage this actually does depends on how the compiler/optimizer organizes the stack frame.

[Gwyn Ciesla]

This fixes the crash on Fedora, thank you!

[Bernhard Wymann]

Fixed in 1.3.9