spring 0.74b3 segfaults on startup (feisty)

pattex · Post by **pattex** » 10 Jun 2007, 18:49

hi,

I used spring without any error for a week or so on ubuntu feisty, but suddenly it segfaultet while playing a singleplayer skirmish with the Star WarsMod (the fixed Version).
since spring always crashed with a segmantation fault when I tried to fire it up again, I uninstalled spring with my packetmanager, deleted (probably) all spring (configuration-)files and compiled from source.
but spring still had the same error.

traceback from the source-version:

Code: Select all

$ gdb /usr/local/games/spring

<Debugger-information...>

(gdb) r
Starting program: /usr/local/games/spring 
[Thread debugging using libthread_db enabled]
[New Thread -1245316624 (LWP 20425)]
warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 000000b4

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1245316624 (LWP 20425)]
0xb79ffedf in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6


(gdb) bt
#0  0xb79ffedf in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#1  0x081a963e in CArchiveScanner::Scan (this=0x8710bf0, curPath=@0xbf837554, 
    checksum=true) at rts/System/FileSystem/ArchiveScanner.cpp:227
#2  0x084c06f9 in UnixFileSystemHandler::InitVFS (this=0x87109e8, 
    mapArchives=true)
    at rts/System/Platform/Linux/UnixFileSystemHandler.cpp:247
#3  0x084c1cd9 in UnixFileSystemHandler (this=0x87109e8, verbose=true, 
    mapArchives=true)
    at rts/System/Platform/Linux/UnixFileSystemHandler.cpp:270
#4  0x0816cf93 in FileSystemHandler::Initialize (verbose=true)
    at rts/System/Platform/FileSystem.cpp:63
#5  0x081366a5 in SpringApp::Initialize (this=0xbf8376f4)
    at rts/System/Main.cpp:276
#6  0x08136ca8 in SpringApp::Run (this=0xbf8376f4, argc=1, argv=0xbf8377e4)
    at rts/System/Main.cpp:868
#7  0x0813717f in Run (argc=1, argv=0xbf8377e4) at rts/System/Main.cpp:1047
#8  0x0813730c in main (argc=Cannot access memory at address 0x1
) at rts/System/Main.cpp:1087
(gdb) q
The program is running.  Exit anyway? (y or n) y

Perhaps there├é┬┤s a conflicted config file I├é┬┤ve overseen to delete.

Tobi · Post by **Tobi** » 11 Jun 2007, 09:39

Could you set StdoutDebug to 1 in ~/.Springrc and run it again (preferably in debugger) so I can see the datadirs and what exactly it was doing while this happened?

pattex · Post by **pattex** » 11 Jun 2007, 21:49

hmmm, I tried it with and without debugger...

I checked the debug option to be enabled, but with debugger it seems to be the same as before (here is the debug of the current try), and without gdb there├é┬┤s coming nothing except

Code: Select all

$ /usr/local/games/spring 
Segmentation fault (core dumped)

Do you know where to find this "core"?

I think spring crashes before it can create debug information. Or this has something to do with the console verbose level (in "Settings++"). I tried with verbose level on 10.

Thanks for the quick answer btw!

Tobi · Post by **Tobi** » 12 Jun 2007, 08:50

No, the verbose level thing was never implemented.

Well if you set this StdoutDebug option to 1 and it still outputs the same then it's crashing really really early, but I suppose it's possible. (Looking at the stacktrace again it's very well possible actually that it did not yet print anything to log/stdout.)

I'll take a look at the source once I'm at home (if I remember

)

AF · Post by AF » 12 Jun 2007, 14:13

verbose level is used in AI messages though. When the AI send a message to the console it has to provide a priority value which is then compared against the verbosity level.

pattex · Post by **pattex** » 12 Jun 2007, 16:10

Code: Select all

$ gdb /usr/local/games/spring 
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r
Starting program: /usr/local/games/spring 
[Thread debugging using libthread_db enabled]
[New Thread -1246049808 (LWP 9625)]
warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 000000b4

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1246049808 (LWP 9625)]
0xb794cedf in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string ()
   from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb794cedf in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string ()
   from /usr/lib/libstdc++.so.6
#1  0x081a963e in CArchiveScanner::Scan (this=0x8710c08, curPath=@0xbfe1fb54, checksum=true)
    at rts/System/FileSystem/ArchiveScanner.cpp:227
#2  0x084c06f9 in UnixFileSystemHandler::InitVFS (this=0x87109a8, mapArchives=true)
    at rts/System/Platform/Linux/UnixFileSystemHandler.cpp:247
#3  0x084c1cd9 in UnixFileSystemHandler (this=0x87109a8, verbose=true, mapArchives=true)
    at rts/System/Platform/Linux/UnixFileSystemHandler.cpp:270
#4  0x0816cf93 in FileSystemHandler::Initialize (verbose=true) at rts/System/Platform/FileSystem.cpp:63
#5  0x081366a5 in SpringApp::Initialize (this=0xbfe1fcf4) at rts/System/Main.cpp:276
#6  0x08136ca8 in SpringApp::Run (this=0xbfe1fcf4, argc=1, argv=0xbfe1fde4) at rts/System/Main.cpp:868
#7  0x0813717f in Run (argc=1, argv=0xbfe1fde4) at rts/System/Main.cpp:1047
#8  0x0813730c in main (argc=Cannot access memory at address 0x1
) at rts/System/Main.cpp:1087
(gdb)

well, this is probably still the same as the one before. is there any further option in the debugger than "backtrace"/"bt" ?

What I├é┬┤m thinking about is, that it did work well for a week and then suddenly after the first segv neither the .deb nor the later compiled source work.
Maybe it├é┬┤s caused by an update or by a corrupted config.
(can spring corrupt configs?)

would it be an option to replace "~/springrc" ?
perhaps someone could give me his springrc so we can check this...

Tobi · Post by **Tobi** » 12 Jun 2007, 19:55

No not a config. But it could be, and I suspect that, that a corrupt .sdz/.7z file is in one of the directories where Spring looks.

pattex · Post by **pattex** » 15 Jun 2007, 14:50

what directories are these?

sry for not responding, I unfortunatelly crashed my NVidia driver so I had to fix that issue first...

Neddie · Post by **Neddie** » 15 Jun 2007, 19:09

/mods
/maps

If I recall correctly...

Spring RTS Engine

spring 0.74b3 segfaults on startup (feisty)

spring 0.74b3 segfaults on startup (feisty)