Page 1 of 1

spring 0.74b3 segfaults on startup (feisty)

Posted: 10 Jun 2007, 18:49
by pattex
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. :?

Posted: 11 Jun 2007, 09:39
by Tobi
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?

Posted: 11 Jun 2007, 21:49
by pattex
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! :-)

Posted: 12 Jun 2007, 08:50
by Tobi
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 :-))

Posted: 12 Jun 2007, 14:13
by AF
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.

Posted: 12 Jun 2007, 16:10
by pattex

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...

Posted: 12 Jun 2007, 19:55
by Tobi
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.

Posted: 15 Jun 2007, 14:50
by pattex
what directories are these?

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

Posted: 15 Jun 2007, 19:09
by Neddie
/mods
/maps

If I recall correctly...