Linux & glibc versions

[Keith Smith]

Yes, the disconnect() method of VSProClient is successfully completing, including the waitfor() that I just added back into that code for the MessageController. I did find another waitfor() in the destructor of a thread which wasn't started. I'm unsure why the stack trace shows it being in the VSProClient destructor, though...that destructor is empty. However, it's probably calling the destructors of the members of VSProClient, which include this thread which wasn't started.

I've removed the waitfor() in this other thread in v1.1.6d.

Give v1.1.6d a try when you can. I'll check the result in the morning, I'm heading to bed here.

[davidspreckeriii]

Keith,

Tried your newest one, still crashing. I will get the stacktrace to you tomorrow as it's late here and I did just a paste, start, login, hear atc, log off test.

Here's the PilotEdge_out.txt info:

Code: Select all

Starting up: PilotEdge client, V1.1.6d
initVoice with device alsa_output.pci-0000_00_1b.0.analog-surround-21, returned 0
PilotEdge initialized
Entered deferred startup
completed deferred startup
Setting up connection details...
Checking for slaves...
Checking for server file...
Checking for voice service file...
About to connect...
Connected to PilotEdge Server
Connected to PilotEdge Voice
Sent voice ids to server: 62,63
Checking for traffic relay file...
using standard bus voltage
VSProClient: disconnect() entered
MessageController::sendMsg entered: msg = QUIT
status = 37
VSProClient: sent bye
VSProClient: signalled controller
VSProClient: connection closed
MessageController exiting
VSProClient: messageController.waitfor() is done
VSProClient: disconnect() complete

[theluckyone17]

Same here:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6ec2741 in pthread_join () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ffff6ec2741 in pthread_join () from /lib64/libpthread.so.0
#1  0x00007fffc04a710f in pt::thread::waitfor() ()
   from /opt/X-Plane/X-Plane 10/Resources/plugins/PilotEdge/64/lin.xpl
#2  0x00007fffc0473204 in VSProClient::~VSProClient() ()
   from /opt/X-Plane/X-Plane 10/Resources/plugins/PilotEdge/64/lin.xpl
#3  0x00007fffc046a102 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  0x0000000001254618 in XPPHandleMenu(int) ()
#7  0x00000000009acd20 in mbar_class::mbar_select_an_item() ()
#8  0x00000000009ad588 in mbar_class::mbar_select_an_item_click() ()
#9  0x000000000096e8ce in MACIBM_handle_click(int) ()
#10 0x00000000009703c5 in xplane_window_delegate::mouse_down(void*, int, int, int) ()
#11 0x00000000013ee9f8 in LIN_handleevt(_XEvent*) ()
#12 0x00000000013ebd88 in WIN_event_loop(int) ()
#13 0x00000000013ebf19 in WIN_run_app ()
#14 0x0000000000600e1a in main ()

Code: Select all

Starting up: PilotEdge client, V1.1.6d
initVoice with device alsa_output.usb-Plantronics_Plantronics_GameCom_780_788-00.analog-stereo, returned 0
PilotEdge initialized
Entered deferred startup
completed deferred startup
Setting up connection details...
Checking for slaves...
Checking for server file...
Checking for voice service file...
About to connect...
Connected to PilotEdge Server
Connected to PilotEdge Voice
Sent voice ids to server: 43,44
Checking for traffic relay file...
using standard bus voltage
VSProClient: disconnect() entered
MessageController::sendMsg entered: msg = QUIT
status = 38
VSProClient: sent bye
VSProClient: signalled controller
VSProClient: connection closed
MessageController exiting

[Keith Smith]

That's very interesting. I read through the source code for the 3rd party library and found that it calls a waitfor() in the thread's destructor so even though I'm not calling it directly, it's being called in any case.

I've just built v1.1.6e which does NOT delete the client object after the disconnect (so the destructors shouldn't get called). This is just a temporary measure as it's poor design to allocate and object and then not delete it before creating a new one. If you were to connect and disconnect several thousand times without restarting xplane, the memory leak would be significant, but as a very temporary patch, it should allow you to disconnect without a crash and the memory leak for normal ops will be trivial.

Give that a try and let me know how that goes. In the mean time, I'm going to start removing the 2 member threads which are there but aren't being started (I suspect they're the ones which are giving us grief in the destructor).

Try 1.1.6e when able and post stack trace and the PilotEdge_out.txt when able, please.

[theluckyone17]

Success! 1.1.6e allows me to disconnect & reconnect without a crash. No backtrace to report (Boy, that sounds nice!)

Code: Select all

Starting up: PilotEdge client, V1.1.6e
initVoice with device alsa_output.pci-0000_00_1b.0.analog-surround-51, returned 0
PilotEdge initialized
Entered deferred startup
completed deferred startup
Setting up connection details...
Checking for slaves...
Checking for server file...
Checking for voice service file...
About to connect...
Connected to PilotEdge Server
Connected to PilotEdge Voice
Sent voice ids to server: 35,36
Checking for traffic relay file...
using standard bus voltage
received MSG_LEFT for CA89_21, plane not found
VSProClient: disconnect() entered
MessageController::sendMsg entered: msg = QUIT
status = 37
VSProClient: sent bye
VSProClient: signalled controller
VSProClient: connection closed
MessageController exiting
VSProClient: messageController.waitfor() is done
VSProClient: disconnect() complete

[Keith Smith]

very good, I will likely do some additional builds as described above, but this is at least a fallback.

[davidspreckeriii]

Keith,

I, too, was able to connect and disconnect several times! Glad to have this finally resolved haha.

[sanjiv]

Hello Everyone,

I am getting the crash on disconnect only when my avionics switch is ON. Disconnect after a complete shutdown works fine. But the good news is that I am now able to use callsign with more than five letters without crashing

Thanks for your efforts Kieth.

Sanjiv

[davidspreckeriii]

Hello Everyone,

I am getting the crash on disconnect only when my avionics switch is ON. Disconnect after a complete shutdown works fine. But the good news is that I am now able to use callsign with more than five letters without crashing

Thanks for your efforts Kieth.

Sanjiv

Interesting, I've not had it crash with avionics on yet.. Although PE does generate a crash when I exit game, just not when I disconnect now.. Which I'll call a win haha

[sanjiv]

Interesting, I've not had it crash with avionics on yet.. Although PE does generate a crash when I exit game, just not when I disconnect now.. Which I'll call a win haha

I have been experiencing this quite consistently. Although it all works fine as long as I do not disconnect prior to switching off the avionics switch/bus, I get a CTD in case of an unintended disconnection (due to network/server outage) during the flight.