TwinFan / LiveTraffic

LiveTraffic is an X-Plane multiplayer plugin, which fills your sky with live air traffic based on public flight tracking data.
https://twinfan.gitbook.io/livetraffic/
Other
99 stars 24 forks source link

Gargabe characters read from Settings UI #185

Closed TwinFan closed 4 years ago

TwinFan commented 4 years ago

Describe the bug Sometimes, LiveTraffic adds garbage characters to the end of edit field input in the Settings UI, like to CSL paths, or maybe also the ADSBEx API key.

To Reproduce Clear way to reproduce uncertain. When it happens then all text entries will have additional characters, which often only shows later in the Log.txt output.

Expected behavior Read and process only as much as entered.

Screenshots

Technical Info:

Log.txt image

0:35:26.701 LiveTraffic WARN  SettingsUI.cpp:672/MsgTextFieldChanged: Settings > Debug: Model matching forced to 'A319ͽýýý'/''/''
TwinFan commented 4 years ago

Man...that code is as old as the first betas of LiveTraffic! But it has a zero-termination bug...in times of heavy use of C++. Actually, the code wanted to make things perfect:

  1. First, it fetches the current length of the text in the input field
  2. Then it allocates an appropriately sized buffer, with one additional char room for the terminating zero
  3. Then it calls XP again to actually fetch the full text
  4. Lastly, it moves the text into a std::string object and deallocates the temporary buffer

The bug is in step 3: The length passed on to XP is the text length, not the buffer length, which is one more. XP specifically states that if the buffer is too small then the returned text will not be zero-terminated. So XP never could zero-terminate the string...if the text is 4 long, then I pass 4, and XP returns 4 actually chars, but no terminating zero.

Why the bug occurs now only is a bit beyond me. Maybe XP was changed to better watch when a terminating zero is added. (Remember, I have the room in the buffer, so if XP did previously add the zero beyond the 4th byte, there would be no memory access problem.) Maybe it is just a change in how the compiler initializes the memory allocated...if it was initialized to zero nothing would have happened either.

Well...fix is simple: Pass in the buffer length to XP, not the text length. As per documentation.