Linux & glibc versions

[theluckyone17]

I'm taking the time to track down the segmentation fault that I'm getting whenever disconnecting from PilotEdge, since I'm having comm problems that appear to be related to specific aircraft. Being able to connect with an X-Plane included model, verify functionality, disconnect, switch to the problematic aftermarket model, and reconnect would be nice.

In short, what versions of glibc are y'all running with, successfully?

Why do I ask? I'm getting a segmentation fault in libpthread.so.0:

Code: Select all

Flight begun!
[Thread 0x7fff877fe700 (LWP 29826) exited]
Completed request with payload: v=1&tid=UA-12381236-12&cid=00:27:0E:0A:1C:2A&t=event&an=X-Plane&av=10.40r1&vp=1024x768&ul=en&sr=3840x1080&ea=app_action&ec=Simulated%20Flight&el=Simulated%20Flight&cd1=Free%20Flight&cd2=Cessna%20172%20SP%20Skyhawk%20-%20Class:%20General%20Aviation%20-%20Studio:%20Laminar%20Research%20-%20Engines:%201&cd3=KVNY&cd13=Mouse&cd14=HDR:%201%20-%20Shadows:%202%20-%20Objects:%203%20-%20HDR%20Antialiasing:%202&cd15=Ramp%20Start%20(Engines%20Off)&cd16=Linux&cd17=:%20Intel%20Core%20i7%20CPU%20%20%20%20%20%20%20%20%20860%20%20-%20Speed:%202.8-3.2%20GHz%20-%20Cores:%208&cd18=GeForce%20GTX%20760/PCIe/SSE2&cd19=0&cd20=ATC%20On%20(0)%20or%20Off%20(1),%20Group%200&cd8=Global
[New Thread 0x7fff877fe700 (LWP 29900)]
[Thread 0x7fff877fe700 (LWP 29900) exited]
0x00000003: I found someone else's context 0x04dfab20.
[New Thread 0x7fff87fff700 (LWP 29902)]
[Thread 0x7fff87fff700 (LWP 29902) exited]
sh: /sbin/ifconfig: No such file or directory
[New Thread 0x7fff8cf7c700 (LWP 29910)]
Connect status changed: 1 1 0
Connect status changed: 1 2 0
onNewChannelEvent: 1 1 0
New channel: 1 Default Channel 
Connect status changed: 1 3 0
New client: N3756D
warning: Unknown nb_ctl request:  12
warning: The VAD has been replaced by a hack pending a complete rewrite
onNewChannelEvent: 1 2 0
New channel: 2 17510 
onNewChannelEvent: 1 3 0
New channel: 3 18011 
onNewChannelEvent: 1 4 0
New channel: 4 18012 
onNewChannelEvent: 1 5 0
New channel: 5 18010 
onNewChannelEvent: 1 6 0
New channel: 6 12280 
onNewChannelEvent: 1 7 0
New channel: 7 12270 
onNewChannelEvent: 1 8 0
New channel: 8 16010 
onNewChannelEvent: 1 9 0
New channel: 9 17010 
Connect status changed: 1 4 0
New channel created: N3756D
warning: Unknown nb_ctl request:  12
warning: The VAD has been replaced by a hack pending a complete rewrite
[Thread 0x7fff8cf7c700 (LWP 29910) exited]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6ec2741 in pthread_join () from /lib64/libpthread.so.0
(gdb) backtrace
#0  0x00007ffff6ec2741 in pthread_join () from /lib64/libpthread.so.0
#1  0x00007fffc04a765f in pt::thread::waitfor() () from /opt/X-Plane/X-Plane 10/Resources/plugins/PilotEdge/64/lin.xpl
#2  0x00007fffc047395f in VSProClient::disconnect() () from /opt/X-Plane/X-Plane 10/Resources/plugins/PilotEdge/64/lin.xpl
#3  0x00007fffc0469cac in disconnect(int) () from /opt/X-Plane/X-Plane 10/Resources/plugins/PilotEdge/64/lin.xpl
#4  0x00007fffc175a335 in XPLMHandleMenuItemPick(int) () from /opt/X-Plane/X-Plane 10/Resources/plugins/XPLM_64.so
#5  0x00007fffc17530d2 in XPLMMenuHook () from /opt/X-Plane/X-Plane 10/Resources/plugins/XPLM_64.so
#6  0x0000000001255f78 in XPPHandleMenu(int) ()
#7  0x00000000009aca20 in mbar_class::mbar_select_an_item() ()
#8  0x00000000009ad288 in mbar_class::mbar_select_an_item_click() ()
#9  0x000000000096e59e in MACIBM_handle_click(int) ()
#10 0x0000000000970095 in xplane_window_delegate::mouse_down(void*, int, int, int) ()
#11 0x00000000013f00b8 in LIN_handleevt(_XEvent*) ()
#12 0x00000000013ed448 in WIN_event_loop(int) ()
#13 0x00000000013ed5d9 in WIN_run_app ()
#14 0x0000000000600dea in main ()

[davidspreckeriii]

Keith and I have been trying to debug a disconnect bug on my end where each time I disconnect from PE, I get a crash to desktop. You might check with him on that and I'd be interested in any findings you have. I've had this crash on several distributions, but currently am running a 64bit Arch linux setup.

[theluckyone17]

I've been running 64 bit Gentoo for years... and I've had the crash since the plugin went 64 bit. Drops right to the desktop. Currently using version 2.22 of glibc, but I also ran into the issue with version 2.20-r2 (Gentoo's downstream patches added, I might add). Wouldn't mind downgrading, assuming I don't have throw myself off the cliff and into dependency hell, and it fixed the segmentation fault.

Is this thread prominent enough to catch Keith's attention? I'd be more than happy to help out where I can.

[Keith Smith]

that's a great stack trace. it tells me where it's crashing on disconnect.

I'll see if I can do some reading to find out what might be causing it. all the code is doing is waiting for the threads to end.

[Keith Smith]

what version of libpthread was that?

I'd have to fire up my Linux env to get my libc and pthread versions. I don't have this issue with my config.

[theluckyone17]

That's nice to hear. Running libpthread-2.22 here. Libc is version 2.22 as well:

Code: Select all

Tesla lib64 # ls -l /lib64/libpthread.so*
lrwxrwxrwx 1 root root 18 Sep 17 21:10 /lib64/libpthread.so.0 -> libpthread-2.22.so
Tesla lib64 # ls -l /lib64/libc.so*
lrwxrwxrwx 1 root root 12 Sep 17 21:10 /lib64/libc.so.6 -> libc-2.22.so

If you can get me the version you're running, I'd be happy to try reverting back to it, even if it means resolving whatever dependency issues I run across in the process. I'm running Gentoo, I should be used to dependency issues at this point. . If I can get it working off an earlier version, it might shed a little light on when it's flaking out on the wait.

[Keith Smith]

Got to spend some time on this tonight. I have an idea of what it might be. The system was going to introduce some new networking code which ran in a separate thread. Ultimately, the testing produced unreliable results, so I stopped using that new sub-system. However, the disconnect code still calls a waitfor() (ie, waits for the thread to end) on several threads including the new sub-system's thread. Well, since that thread isn't actually STARTING, that might be the cause of the issue.

I suspect that Windows, Mac and some Linux implementations allow you to wait for the end of a thread that was never started whereas some other Linux implementations might have an issue with it.

The good news is that I can remove the waitfor() on that thread and get a new build out to you guys very soon.

[theluckyone17]

Have I mentioned lately how awesome you and the rest of the staff at Pilotedge are? Great response time, especially on a Saturday night (Eastern time at least) . I'll await the new version, and test from there. Thanks!

[Keith Smith]

I'm on libpthread/libc 2.19.

For anyone who is having linux crashing issues during the disconnect, I was able to get into my linux dev environment and build a new version which no longer has the waitfor() call on the thread that never started. Give it a shot, here is the updated lin.xpl file. Backup your existing PilotEdge/64/lin.xpl and replace with this one.

NOTE: this build also has true dual radio support. If you can get your audio panel to have COM1 and COM2 set to receive at the same time then you'll be able to hear ATC from both freqs at the same time. I've been testing it by mapping a key on the keyboard to force com2 to RX mode (if you actually click on the COM2 on the stock audio panel it tends to disable the COM1 RX state and vice versa, but if you trigger this through the xplane audio panel commands in the advanced keys section, you can do it) The online map hasn't been updated to handle this capability yet, it's going to show your com1 frequency only.

[theluckyone17]

I've got family in town, so I won't be able to test it until later tonight. Thanks!