PDC from BOS_1_CTR causing CTD

[Noel Bennett 1159876]

Short story: Every time Boston Center p[Mod - Happy Thoughts]es a clearance to me via PDC/text, XSquawkbox crashes. 64 bit Linux (Gentoo), 10.51r2. I've submitted feedback to BVARTCC thanking the controller for his patience, and asking that he send over the text of the PDC if possible for debugging purposes. I've got a gut feeling that something in that PDC is causing an issue.

 

The long story:

X-Plane log: http://pastebin.com/raw/UPzN7HQJ

 

GDB Running Output: http://pastebin.com/raw/ZAxPiBs1

 

GDB Backtrace (set pagination off & thread apply all backtrace): http://pastebin.com/raw/UQndBa6m

[Bradley Grafelman]

Looks like sprintf() is being used rather than something like snprintf(). Based on that and the backtrace, my guess would be on a string buffer that isn't sized large enough to hold the maximum private message (or on-frequency text message... or both?) string length that the VATSIM FSD supports.

[Camden Bruno]

Noel,

 

Expect a response to your feedback from our Facilities Engineer, who will include all of the CPDLC/PDC text we use. They are always sent via private message. We have sent hundreds of these and have never heard of this problem, that said, it is very strange.

 

Thanks,

[Noel Bennett 1159876]

Thanks, Camden!

 

I'm rarely flying anything bigger than a Twin Otter; this was the first time I'd been sent a PDC. Like the concept, though. It does make me wonder how many pilots are using XP10 with XSquawkbox on Linux, and if that's a contributing factor.

[Noel Bennett 1159876]

... my guess would be on a string buffer that isn't sized large enough to hold the maximum private message (or on-frequency text message... or both?) string length that the VATSIM FSD supports.

 

Got a feeling you're right. The Facilities Engineer got back to me, with the template for the PDC:

$aircraft - CLEARANCE START - | CALL SIGN: $aircraft | TRANSPONDER CODE: $squawk | ALTITUDE: $cruise | DEPT: $dep | ARR: $arr | EQUIPMENT: $type($aircraft) | APPROVED ROUTE: $route | ALTITUDE RESTRICTIONS: CLIMB VIA SID. -ADDITIONAL INFORMATION: DEPARTURE FREQUENCY $freq($1) | THIS MESSAGE SERVES AS YOUR DEPARTURE CLEARANCE. YOU DO NOT NEED TO REPLY TO THIS MESSAGE. CONTACT $uc($radioname()) ON $com1 WITH LOCATION ON THE AIRPORT, [Mod - Happy Thoughts]IGNED SID, AND CURRENT ATIS WHEN READY TO PUSH OR IF YOU HAVE QUESTIONS REGARDING THIS CLEARANCE. - CLEARANCE END -

 

Bet the buffer for that sprintf call is just set smaller than the PDC I was receiving.

[Ross Carlson]

Easy enough to confirm if it's a length problem versus a PDC-specific content problem ... just have someone send you a private message that's the same length or longer.

[Bradley Grafelman]

APPROVED ROUTE: $route

Here's the biggest variable (pun intended); if you do test this, make sure you pay attention to how long the route is in your flight plan as it might be that which tips the scales.

[Noel Bennett 1159876]

I tried something even simpler... Just hopped online and talked to ASE_APP (Marcus Miller), explained the situation, and he sent over a long private message, over 256 characters... and XSquawkbox crashed, taking X-Plane down with it.

 

It's possible the actual limit is lower; I picked 256 characters for its obvious significance. Go back a few years and I bet the statement "No one's going to need more than 256 characters" might have been mentioned.

 

In all my years of flying on VATSIM, this would have been the first time I've had a PDC sent to me; I could avoid the issue by simply requesting no PDCs.

Edited November 17, 2016 at 01:01 AM by Guest

[Bradley Grafelman]

Unless I'm mistaken, XSquawkbox is still a closed-source product, so you'll likely have to wait until Christopher Collins stops by and can take a look at this. If it really is as simple as growing the size of an internal string buffer or two, perhaps this is something he could provide a hotfix for relatively quickly.

 

Until then, you might want to consider adding something like "NO PDC" to the front of your flight plan remarks to avoid this.

[Christopher Collins]

Thanks for the excellent troubleshooting on this one - I'll practically guaranty that it's a buffer length issue given some of the other doozies I've found in the code with my recent work.

 

I'll try to get a fix release out in the next 2 weeks - can't guaranty much faster because of various pressures around my real-world flying activities and my day job.

[Andreas Fuchs]

Thanks for dropping in and fixing it!

[Noel Bennett 1159876]

Thanks for the excellent troubleshooting on this one

No worries. I've heard it said that we Linux folk can be vocal minorities and a right pain in the tooshie, so we better make up for it somewhere. 'Course, having the tools at your disposal helps, too.

 

I'll try to get a fix release out in the next 2 weeks - can't guaranty much faster...

No guarantees need, either. Life (family and job) comes first. Color me grateful that someone's still working on XSB.

[Christopher Collins]

I can now positively confirm that it's overflowing an internal string buffer.

 

I've fixed the codebase for now - I'll see if I can coax my legacy toolchain into building a working Windows release (OSX and Linux shouldn't be a problem).

 

The fix for now will truncate overlength messages - the limit is just a touch over 500 characters.

 

I'll see about fixing this properly in a future release.

 

The fix release will also contain a delayed fix I had for XSB disabling weather when you set the update interval to 0.

[Dhruv Kalra]

The fix release will also contain a delayed fix I had for XSB disabling weather when you set the update interval to 0.

Could I humbly request that this remain the way that it is now? Wade put that "feature" in deliberately by request so that you could disable the VATSIM weather in order to use either the NOAA weather scripts or FSGRW weather, both of which have far more accurate winds aloft than the VATSIM canned weather.

 

Either that, or could we have an explicit checkbox option to disable VATSIM server weather so that X-Plane's built-in real weather (which includes worldwide wind aloft) or a 3rd-party weather injector still be usable alongside XSB?

[Charles Rizzi 810637]

Could I humbly request that this remain the way that it is now? Wade put that "feature" in deliberately by request so that you could disable the VATSIM weather in order to use either the NOAA weather scripts or FSGRW weather, both of which have far more accurate winds aloft than the VATSIM canned weather.

 

Either that, or could we have an explicit checkbox option to disable VATSIM server weather so that X-Plane's built-in real weather (which includes worldwide wind aloft) or a 3rd-party weather injector still be usable alongside XSB?

 

+1 - Perhaps I am misunderstanding but I don't see how forcing people to use VATSIM WX through XSB is a good idea (if that's what's proposed here - not sure). Certainly in the FSX world other weather injectors like Active Sky are allowed. I also agree that any of XP native, FSGRW, NOAA or FsRealWX give better WX injection than XSB.

 

Also re FSGRW see https://forums.vatsim.net/viewtopic.php?f=109&t=72648

[Christopher Collins]

The fix release will also contain a delayed fix I had for XSB disabling weather when you set the update interval to 0.

Could I humbly request that this remain the way that it is now?

 

Please do NOT presume to tell me how to do my job or read your own fears and bullshit into what I've written.

 

I meant that precisely as I wrote it.

 

There is a bug at present where even with weather updates disabled, XSB [Mod - Happy Thoughts]erts nil/clear weather.

 

This is definitely a bug.

 

This is what the bugfix is to fix.

 

If you have read previous comments here about this bug, maybe you'd realise that.

[Charles Rizzi 810637]

Chris - thank you for your time and effort here. I was a VATUSA INS, DATM, TA, ATM, VATSIM SUP and more for plus/minus seven years. The complaints are continuous and the thank you's are very, very rare. So at least here's one thank you.

[Dhruv Kalra]

Please do NOT presume to tell me how to do my job or read your own fears and [Mod-You kiss your mother with that mouth?] into what I've written.

 

I meant that precisely as I wrote it.

 

There is a bug at present where even with weather updates disabled, XSB [Mod - Happy Thoughts]erts nil/clear weather.

 

This is definitely a bug.

 

This is what the bugfix is to fix.

 

If you have read previous comments here about this bug, maybe you'd realise that.

You are correct. I haven't been as well-versed on current XSB bugs as I could be. That being said, I was unsure as to whether or not you were cl[Mod - Happy Thoughts]ifying XSB disabling VATSIM weather with the interval set to 0 as the intended behavior, hence my attempt at clarifying what Wade's intent had been.

 

I'll also echo Charles' sentiment in that I'm grateful that the XSB codebase is being actively maintained and I apologize if my post sounded contrary to that.