Segmentation fault in thread "LT_ADSBEx"

[JT8D-17]

Building LiveTraffic on Arch Linux with commit 696b9e6326c01b1c4664f7efb0ef58ba5b75e432 and a fresh LT installation produces a segmentation fault when starting a flight.

XP log and GDB backtrace: X-Plane_gdb_log.txt

- Edit:

The official 3.6.0 release also does this. Sigh. Off to investigate system packages...

[JT8D-17]

Fixed it. LT choked on the ADSBEx API key in LiveTraffic.prf. Removed the line and now it starts again.

[JT8D-17]

Need to reopen because LiveTraffic always segfaults when testing the ADSBEx API key. I've triple checked that it is correct while typing it in.

Note that, as opposed to the plugin-laden main isntall that the backtrace above is from, this also happens in a vanilla XP12.1.0rc2 testing installation with zero other plugins.

I get the API key from:

[TwinFan]

Whatever the key...LiveTraffic would certainly not be supposed to crash. But I won't investigate on private builds. If the official download crashes, then please provide Log.txt and if you have crash dump. I have no other reports of crashes as of yet. If reproducible, then please configure Set Log Level to Debug and also switch on Log Raw Network Data before you reproduce by testing an ADSBEx API key. The last option produce a separate file LTRawFD.log, which includes network traffic. Please attach it, too.

[JT8D-17]

Clean XP12.1.0rc2 installation, LiveTraffic 3.6.0 being the only plugin. Debug log level and raw network data output enabled.

Log.txt

X-Plane_gdb_log.txt

LTRawFD.log

FWIW, adsb.fi works flawlessly.

[TwinFan]

Unfortunately the logs don't say much except for the crash being in ADSBExchangeConnection::ReceiveHeader(), which we knew already. That function needs to play a bit with char pointers, granted...but still, works for everybody else.

I've dusted off my Linux installation, but that's Ubuntu 22.04.4. Ran hours of updates to get to latest in both OS and X-Plane (12.1.0-rc-2) and ran LiveTraffic official v3.6.0 totally successful with ADSBEx.

The next best I can offer you is this debug-build of LiveTraffic 3.6.0 in the hope that, as symbol tables are included, the crash dump provides more details. Or you play yourself with the code of ADSBExchangeConnection::ReceiveHeader(). LiveTraffic_3.6.0_lin_dbg.zip

[JT8D-17]

With debug symbols:

Log.txt

X-Plane_gdb_log.txt

LTRawFD.log

[TwinFan]

Thanks, the crash dump does have more details...but they don't make sense. The relevant parts are:

Thread 122 "LT_TestADSBEx" received signal SIGSEGV, Segmentation fault.
0x00007fff34c84f59 in ADSBExchangeConnection::ReceiveHeader (buffer=0x7fffad6d3d17 "\r\n", size=1, 
    nitems=2) at /home/birger/Programming/LiveTraffic/Src/LTADSBEx.cpp:635
        p = 0x7fffad6d3d17 "\r\n"
        len = 2
        lenRLimit = 27
        lenRRemain = 31
        num = "S\276\025 [...] \000\000\000"
        lenMax = 2
        i = 0

The crash location, LTADSBEx.cpp:635, is this line of code:

*p = char(std::tolower(*p));

and from the crash dump we know that p = "\r\n", ie. a perfectly valid string of 2 characters, which happen to CR LF, actually passed in into the function via parameter buffer. This is the first attempt in a loop (i = 0) to turn characters into lower case. And it crashes while taking the first of the two characters (*p), passing it through a standard library function std::tolower and assign it back to the very same location *p.

Sorry...I'm lost how that can seg fault...and all the rest of LiveTraffic not...

[JT8D-17]

I've googled "segfault std::tolower" and some results mention the locale, which influences the conversion rules. Maybe this has something to do with it, but setting LC_CTYPE=C (instead of en_US.UTF-8) in etc/locale.conf (and rebooting) has no effect.

[TwinFan]

...because all communication threads set the "C" locale already upon spawning, so they can parse network messages in a predictable way and don't confuse dots and commas and the like. It is set through the ThreadSettings class in the thread's main function ADSBExchangeConnection::DoTestADSBExAPIKey (see #244).