Menu
▾
▴
#1163 TerraSync segfaults when enabled on startup
Originally created by: gijsrooy
Originally owned by: zakalawe@mac.com
What steps will reproduce the problem?
1. Start FlightGear with James' new SVN thingy.
2. Switch TerraSync on.
3. Let TerraSync download some tiles and then close FlightGear.
4. Launch FlightGear again.
What is the expected output? What do you see instead?
FlightGear crashes, showing a Windows error window. When I disable TerraSync (I need to modify the autosave.xml for this), FlightGear launches fine and continues to run fine when I re-enable TerraSync through the in-sim dialog.
What FlightGear version (or GIT date)?
Git from July 13
What operating system and graphics card?
Windows 7
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
Any chance of a back-ttrace from the crash? (Also this makes me glad I did not enable the new code by default for 2.12)
Status: NeedInfo
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: gijsrooy
Hm, I managed to trigger the segfault when starting TerraSync after startup. The first couple of directories go fine (the log displays "Succesfully synchronized directory", but at some point (always the same directory for a given position) the segfault shows up. The last directory is complete though, so it's probably the directory thereafter that fails.
Could it be some corrupted files on the server? I can reproduce this all over the world, so it's not a single file.
I will provide a back-trace if you tell me what I need to do :-)
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
Can you still repro this with latest git? I made some major fixes about a week ago.
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: gijsrooy
Same issue with freshly built Git. :-(
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
Okay, that's fine, this is what testing is for. Two things; can you *move* your TerraSync repo to a new name, and see if the problem disappears with a fresh checkout?
And secondly, with the original repo, can you compile a debug build, run in the debugger, and find the location it crashes?
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: soitanen...@gmail.com
/usr/games/bin/fgfs --telnet=5401 --airport=XLLE --aircraft=ufo --fg-root=/home/rolf/fgdata --fg-scenery=/home/rolf/Project-Russia:/home/rolf/Terrasync --log-level=debug
Starting automatic scenery download/synchronization. Using built-in SVN support. Directory: '/home/rolf/Terrasync'.
terrasync: will sync http://terrascenery.googlecode.com/svn/trunk/data/Scenery/Models
HTTP connecting to terrascenery.googlecode.com:80
[New Thread 0x7fffeb7fe700 (LWP 24463)]
did start request:http://terrascenery.googlecode.com/svn/trunk/data/Scenery/Models
@ 0x7fffe4000dd0
on connection 0x7fffe40012b0
NoaaMetarRealWxController::update(): (re) checking nearby airport with METAR
Path "/home/rolf/Terrasync/Models/Effects"exceeded MAX_UPDATE_REPORT_DEPTH, cleaning
did start request:http://terrascenery.googlecode.com/svn/!svn/vcc/default
@ 0x7fffe40011b0
on connection 0x7fffe40012b0
NoaaMetarRealWxController::update(): nearest airport with METAR is: KSFO
NoaaMetarRealWxController::update(): nearest airport with METAR has changed. Old: '', new: 'KSFO'
NoaaMetarRealWxController::update(): spawning load request for station-id 'KSFO'
HTTP connecting to weather.noaa.gov:80
did start request:http://weather.noaa.gov/pub/data/observations/metar/stations/KSFO.TXT
@ 0x1a9a560
on connection 0x1a109e0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffebfff700 (LWP 24462)]
0x00007ffff77c2953 in simgear::SVNDirectory::deleteChildByName(std::string const&) () from /usr/lib64/libSimGearCore.so.2.99.0
(gdb) bt
#0 0x00007ffff77c2953 in simgear::SVNDirectory::deleteChildByName(std::string const&) () from /usr/lib64/libSimGearCore.so.2.99.0
#1 0x00007ffff77c57f7 in simgear::SVNDirectory::addChildDirectory(std::string const&) () from /usr/lib64/libSimGearCore.so.2.99.0
#2 0x00007ffff77c79d4 in simgear::SVNReportParser::SVNReportParserPrivate::startElement(char const*, char const**) () from /usr/lib64/libSimGearCore.so.2.99.0
#3 0x0000003ac100ac7c in ?? () from /usr/lib64/libexpat.so.1
#4 0x0000003ac100bd61 in ?? () from /usr/lib64/libexpat.so.1
#5 0x0000003ac1008bf7 in ?? () from /usr/lib64/libexpat.so.1
#6 0x0000003ac100a5ab in ?? () from /usr/lib64/libexpat.so.1
#7 0x0000003ac100db6d in XML_ParseBuffer () from /usr/lib64/libexpat.so.1
#8 0x00007ffff77c6294 in simgear::SVNReportParser::innerParseXML(char const*, int) () from /usr/lib64/libSimGearCore.so.2.99.0
#9 0x00007ffff77c0489 in ?? () from /usr/lib64/libSimGearCore.so.2.99.0
#10 0x00007ffff77b4ccf in simgear::HTTP::Connection::collectIncomingData(char const*, int) () from /usr/lib64/libSimGearCore.so.2.99.0
#11 0x00007ffff77a6cd0 in simgear::NetChat::handleBufferRead(simgear::NetBuffer&) () from /usr/lib64/libSimGearCore.so.2.99.0
#12 0x00007ffff77a540c in simgear::NetChannelPoller::poll(unsigned int) ()
from /usr/lib64/libSimGearCore.so.2.99.0
#13 0x00007ffff77aec8d in simgear::HTTP::Client::update(int) ()
from /usr/lib64/libSimGearCore.so.2.99.0
#14 0x00007ffff786c4d1 in simgear::SGTerraSync::SvnThread::syncTreeInternal(char---Type <return> to continue, or q <return> to quit---
const*) () from /usr/lib64/libSimGearCore.so.2.99.0
#15 0x00007ffff786d2ba in simgear::SGTerraSync::SvnThread::syncTree(char const*, bool&) () from /usr/lib64/libSimGearCore.so.2.99.0
#16 0x00007ffff786f59d in simgear::SGTerraSync::SvnThread::run() ()
from /usr/lib64/libSimGearCore.so.2.99.0
#17 0x00007ffff784d09a in SGThread::PrivateData::start_routine(void*) ()
from /usr/lib64/libSimGearCore.so.2.99.0
#18 0x0000003ab9c08cfa in start_thread () from /lib64/libpthread.so.0
#19 0x0000003ab98e7e5d in clone () from /lib64/libc.so.6
if run with --restore-defaults and enabling SVN "on-the-fly"
Starting automatic scenery download/synchronization. Using built-in SVN support. Directory: '/home/rolf/Terrasync'.
*** glibc detected *** /usr/games/bin/fgfs: double free or corruption (!prev): 0x00007ff50e68aeb0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3ab987cea6]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear15SVNReportParser22SVNReportParserPrivate15decodeTextDeltaERK6SGPath+0x72a)[0x7ff53b5679da]
/usr/lib64/libSimGearCore.so.2.99.0(+0xc0f6c)[0x7ff53b565f6c]
/usr/lib64/libexpat.so.1[0x3ac100af5c]
/usr/lib64/libexpat.so.1[0x3ac100bd61]
/usr/lib64/libexpat.so.1(XML_ParseBuffer+0x6d)[0x3ac100db6d]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear15SVNReportParser13innerParseXMLEPKci+0x84)[0x7ff53b565294]
/usr/lib64/libSimGearCore.so.2.99.0(+0xba489)[0x7ff53b55f489]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear4HTTP10Connection19collectIncomingDataEPKci+0xdf)[0x7ff53b553ccf]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear7NetChat16handleBufferReadERNS_9NetBufferE+0xf0)[0x7ff53b545cd0]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear16NetChannelPoller4pollEj+0x17c)[0x7ff53b54440c]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear4HTTP6Client6updateEi+0x1d)[0x7ff53b54dc8d]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear11SGTerraSync9SvnThread16syncTreeInternalEPKc+0x811)[0x7ff53b60b4d1]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear11SGTerraSync9SvnThread8syncTreeEPKcRb+0xaa)[0x7ff53b60c2ba]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN7simgear11SGTerraSync9SvnThread3runEv+0x21d)[0x7ff53b60e59d]
/usr/lib64/libSimGearCore.so.2.99.0(_ZN8SGThread11PrivateData13start_routineEPv+0xa)[0x7ff53b5ec09a]
/lib64/libpthread.so.0[0x3ab9c08cfa]
/lib64/libc.so.6(clone+0x6d)[0x3ab98e7e5d]
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tom...@gmail.com
The first crash should be fixed now. The second crash sometimes also happens to me, but I don't know yet how to reproduce it reliable. I've cleaned my TerraSync directory and was not able to reproduce it afterwards yet.
Status: Dev
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: soitanen...@gmail.com
It still crashing at startup, but with other error. Here is log (it's not to small); http://pastebin.com/p3GjK7Gq
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: gijsrooy
FlightGear now crashes as soon as I enable TerraSync. James, please let me know if you still need me to see if I can build a debug version, or is Micahel's log sufficient?
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
I've seen a crash now (in a similar place), but only in release builds. The problem is I can't at present run valgrind on Mac. In the next few weeks I'm going to buy a real box to run Windows/Linux so I can test this stuff, but in the meantime if someone with Linux could run the new code under valgrind it would be a big help.
Owner: zakalawe@mac.com
Cc: -zakalawe@mac.com
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tom...@gmail.com
Here are two backtraces. I've looked a bit into it, but have currently now clue what's going wrong. Maybe a multithreading/synchronization issue?
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
I got frustrated and ordered the physical box a bit sooner - should arrive in the next few days. Tom's crashes above (plus the fact debug builds don't crash here) make me more convinced it's either a threading or memory corruption issue.
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tom...@gmail.com
Seems like there is somehow a conflict with the system expat library. Using the system expat library I was not able yet to reproduce a crash. With the provide expat code (and also enabling SIMGEAR_SHARED) I'm almost always able to get a crash by enabling and disabling TerraSync a few times. If it doesn't crash repositioning to another airport and then again enable/disable Terrasync "helps".
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
I was seeing something similar on my Linux (Ubuntu 13.04 64-bit) with the MD5 code, I renamed the MD5 symbols in SimGear to have distinct names (SG_ prefix) and my crashes went away. I've no idea if I'm using system or Simgear expat, but can check.
(And yes, I'm using SIMGEAR_SHARED)
I wonder if some of the code is seeing the 'wrong' expat header? Eg due to missing simgear_config.h include? (Although I think the paths are all set at the CMake level)
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: bmbr...@gmail.com
I posted a comment to bug #920 which *might* be related: without explicitly telling cmake to use the system sqlite I was getting a build with bits of both the bundled and system sqlite files. A runtime library version check prevented the inbuilt svn from working. Perhaps this is related. Try with SYSTEM_SQLITE turned on.
Related
Tickets:
#920View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
Hmm, it sounds as if we need to be much more defensive in ensuring the correct (system or built in) version of both expat and sqlite is selected on Linux & Mac (not an issue on Windows I guess, since there's never a system one)
View and moderate all "codetickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: zakalawe@mac.com
Right, this was done. (3rdparty dirs in SG+FG for expat and sqlite)
Status: Fixed