[REPAIRED]1.11.1 does not seem to work
Moderator: Forum Moderators
Forum rules
Before reporting issues in this section, you must read the following topic:
Before reporting issues in this section, you must read the following topic:
[REPAIRED]1.11.1 does not seem to work
I tried to compile wesnoth 1.11.1 from source using make on Linux Ubuntu 12.10, everything went fine, but when I tried to load it, it crashed while loading to the main screen. I reinstalled it, but without success. I deleted all configuration files, but without success. This is the terminal output. 1.11.0 installed in the same way worked without problems.
The filesystem error that it could not find preferences was created when I removed the preferences supposing that it might cause the problem, it crashed also if the file was there.
Code: Select all
Started on Sun Dec 9 17:58:57 2012
20121209 17:58:57 error filesystem: Could not open '/home/dugi/.config/wesnoth/preferences' for reading.
Data directory: /usr/local/share/wesnoth
User configuration directory: /home/dugi/.config/wesnoth
User data directory: /home/dugi/.local/share/wesnoth/1.11
Cache directory: /home/dugi/.cache/wesnoth
Checking video mode: 1024x768x32...
setting mode to 1024x768x32
Segmentation fault (core dumped)
Last edited by Dugi on December 12th, 2012, 8:54 pm, edited 1 time in total.
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: 1.11.1 does not seem to work
Firstly, I'd try deleting the whole configuration and cache directories, you see these paths in the terminal output which you posted.
Secondly, to troubleshoot this, whether it's a bug or somehow related to the OS, you should get a backtrace as precisely described here: http://forums.wesnoth.org/viewtopic.php?f=4&t=16163
EDIT
Actually, before the backtrace, you can also start wesnoth with passing the command line parameter --log-debug=all and post the output.
Secondly, to troubleshoot this, whether it's a bug or somehow related to the OS, you should get a backtrace as precisely described here: http://forums.wesnoth.org/viewtopic.php?f=4&t=16163
EDIT
Actually, before the backtrace, you can also start wesnoth with passing the command line parameter --log-debug=all and post the output.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: 1.11.1 does not seem to work
It was extremely long and there was no way to copy it all, I hope the last lines will help you to tell where it happened and what might have been the cause.
And I have removed all the paths mentioned there, but it didn't help, and it created new ones after that. Deleting the cache on the last line above the segmentation fault didn't help neither (not even the whole folder).
I'll do the other troubleshooting thing soon, as the log above does not seem to carry much information.
gdb does nothing, wrote a few lines that looked like starting something, but then after 10 minutes, nothing new appeared there.
Code: Select all
20121209 21:17:08 debug filesystem: Looking for 'advanced_preferences.cfg'.
20121209 21:17:08 debug filesystem: trying '/usr/local/share/wesnoth/data/advanced_preferences.cfg'
20121209 21:17:08 debug filesystem: found: '/usr/local/share/wesnoth/data/advanced_preferences.cfg'
20121209 21:17:08 info filesystem: Streaming /usr/local/share/wesnoth/data/advanced_preferences.cfg for reading.
20121209 21:17:08 debug config: testing for macro __UNUSED__: not defined
20121209 21:17:08 info config: Macro definition not found for game_config.cfg , attempting to open as file.
20121209 21:17:08 debug filesystem: Looking for 'game_config.cfg'.
20121209 21:17:08 debug filesystem: trying '/usr/local/share/wesnoth/data/game_config.cfg'
20121209 21:17:08 debug filesystem: found: '/usr/local/share/wesnoth/data/game_config.cfg'
20121209 21:17:08 info filesystem: Streaming /usr/local/share/wesnoth/data/game_config.cfg for reading.
20121209 21:17:08 info config: Macro definition not found for core/team-colors.cfg , attempting to open as file.
20121209 21:17:08 debug filesystem: Looking for 'core/team-colors.cfg'.
20121209 21:17:08 debug filesystem: trying '/usr/local/share/wesnoth/data/core/team-colors.cfg'
20121209 21:17:08 debug filesystem: found: '/usr/local/share/wesnoth/data/core/team-colors.cfg'
20121209 21:17:08 info filesystem: Streaming /usr/local/share/wesnoth/data/core/team-colors.cfg for reading.
20121209 21:17:08 debug config: testing for macro TUTORIAL: not defined
20121209 21:17:08 info filesystem: streaming /home/dugi/.cache/wesnoth/cache-v1.11.1-d300d12b655e8545928eb51ab07f7acfe6a6b406.gz for writing.
Segmentation fault (core dumped)
I'll do the other troubleshooting thing soon, as the log above does not seem to carry much information.
gdb does nothing, wrote a few lines that looked like starting something, but then after 10 minutes, nothing new appeared there.
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: 1.11.1 does not seem to work
Hm well, report it at gna I'd say, so that it doesn't get lost: http://gna.org/bugs/?group=wesnoth
Include a link to this and that it didn't yet happen in 1.11.0.
Getting gdb to print something useful would be good. Make sure to use a debug build.
Include a link to this and that it didn't yet happen in 1.11.0.
Getting gdb to print something useful would be good. Make sure to use a debug build.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: 1.11.1 does not seem to work
Okay, this is what it said about the segmentation fault.
I'll post about it there.
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0x092a5be4 in (anonymous namespace)::escaped_string(__gnu_cxx::__normal_iterator<char const*, std::string> const&, __gnu_cxx::__normal_iterator<char const*, std::string> const&) ()
Re: 1.11.1 does not seem to work
If you enter the command 'bt', gdb will print a backtrace. While this line shows that the crash happens in the parser, it doesn't show us how we got there.
Re: 1.11.1 does not seem to work
This is what it said then:
Code: Select all
#0 0x092a5be4 in (anonymous namespace)::escaped_string(__gnu_cxx::__normal_iterator<char const*, std::string> const&, __gnu_cxx::__normal_iterator<char const*, std::string> const&) ()
#1 0x092a5ff9 in (anonymous namespace)::write_key_val_visitor::operator()(t_string const&) const ()
#2 0x092a8700 in void boost::detail::variant::invoke_visitor<(anonymous namespace)::write_key_val_visitor const>::internal_visit<t_string const>(t_string const&, int) ()
#3 0x092a85d5 in boost::detail::variant::invoke_visitor<(anonymous namespace)::write_key_val_visitor const>::result_type boost::detail::variant::visitation_impl_invoke_impl<boost::detail::variant::invoke_visitor<(anonymous namespace)::write_key_val_visitor const>, void const*, t_string>(int, boost::detail::variant::invoke_visitor<(anonymous namespace)::write_key_val_visitor const>&, void const*, t_string*, mpl_::bool_<true>) ()
#4 0x092a8364 in boost::detail::variant::invoke_visitor<(anonymous namespace)::write_key_val_visitor const>::result_type boost::detail::variant::visitation_impl_invoke<boost::detail::variant::invoke_visitor<(anonymous namespace)::write_key_val_visitor const>, void const*, t_string, boost::variant<boost::blank, bool, double, std::string, t_string, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: 1.11.1 does not seem to work
That is a very short backtrace (it should go at least until #10 I suppose); are you sure you copied it all ?
So, did you forget to type bt in the first place (and AI was right about reminding you), or does gdb actually behave very weird (slow ?). Perhaps copy the complete shell output. Usually you get back to the gdb prompt where you entered the bt command after it has printed the trace, doesn't that happen ? (Then something seriously is wrong.)
So, did you forget to type bt in the first place (and AI was right about reminding you), or does gdb actually behave very weird (slow ?). Perhaps copy the complete shell output. Usually you get back to the gdb prompt where you entered the bt command after it has printed the trace, doesn't that happen ? (Then something seriously is wrong.)
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: 1.11.1 does not seem to work
gdb didn't behave very slow, I had to start the process with the run command and I forgot about it. And the backtrace also wasn't entire, I just thought that overly long logs are useless. Here is the entire terminal output (bt ended after 23 steps).
Is that enough?
Spoiler:
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: 1.11.1 does not seem to work
Yes, but in one line gdb says "no debugging symbols found" which very likely means you used a release build as opposed to a debug one. (And indeed there is info missing from the trace.)
Also, you don't need to install wesnoth to run it. The executable will be in the root of your source tree from where you should run it. (Actually, I never installed it, and I don't know whether it would work with a debug build.)
Also, you don't need to install wesnoth to run it. The executable will be in the root of your source tree from where you should run it. (Actually, I never installed it, and I don't know whether it would work with a debug build.)
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: 1.11.1 does not seem to work
According to the information how to build it (using make), I should do this in the folder (if I am correct):
But it does not seem to want to take that argument. Am I doing something wrongly?
Code: Select all
cmake .
make -DCMAKE_BUILD_TYPE=Debug
sudo make install
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: 1.11.1 does not seem to work
I think it should be (the Debug argument needs to be passed to cmake at least)
To force a reconfiguration, delete the file CMakeCache.txt. Not sure whether it has that name since I've also used cmake on windows, and on Linux I usually only generate a project file with cmake.
No need for install, all in the source tree root folder.
Code: Select all
cmake -DCMAKE_BUILD_TYPE=Debug
make wesnoth
No need for install, all in the source tree root folder.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: 1.11.1 does not seem to work
Okay, this is the gdb output now:
Btw, what is the chance that the archive was damaged during downloading and checksums haven't noticed it?
Spoiler:
Re: 1.11.1 does not seem to work
This looks like the same problem nvlbg_ reported in IRC last month. So you can probably sidestep the crash by running 'wesnoth --nocache' instead of just 'wesnoth'. However, sidestepping is not solving. Would you be willing to do some debugging? Otherwise, the problem might persist until a developer can reproduce it.
First, since it might be simplest, is this related to any add-ons? If you move your add-on directory someplace "safe" (effectively deleting it without actually deleting anything), does the crash still occur? If the crashing stops, can you identify which add-on is triggering this crash? (Restore them one at a time until the crash comes back.) The goal of this is to make the crash reproducible, not to blame the add-on.
If that fails (or if you feel like messing with code anyway), take a look at the source file If you add the following three lines right before that one, you should get a lot of data dumped to the terminal when you run Wesnoth.
I would be curious as to the last dozen or so lines of this output, as well as confirmation that gdb still reports the segmentation fault as occurring "in (anonymous namespace)::escaped_string".
Next, remove the three lines you added toDoes the crash still occur? Still in escaped_string?
First, since it might be simplest, is this related to any add-ons? If you move your add-on directory someplace "safe" (effectively deleting it without actually deleting anything), does the crash still occur? If the crashing stops, can you identify which add-on is triggering this crash? (Restore them one at a time until the crash comes back.) The goal of this is to make the crash reproducible, not to blame the add-on.
If that fails (or if you feel like messing with code anyway), take a look at the source file
src/serialization/parser.cpp
. Line 504 should be Code: Select all
out_ << '"' << escaped_string(w.begin(), w.end()) << '"';
Code: Select all
std::cerr << "Visiting: ";
std::string part(w.begin(), w.end());
std::cerr << "_\"" << part << "\"\n";
Next, remove the three lines you added to
parser.cpp
and change line 504 to
Code: Select all
out_ << '"' << escaped_string(std::string(w.begin(), w.end())) << '"';
Re: 1.11.1 does not seem to work
When I did the first edit, this is all I got into Terminal (except the usual locations of directories and screen resolution):
No idea what can it mean.
This is what I got with gdb.
The last modification made it work (no crashes and therefore no backtrace available).
Sorry for the time it took, but these processes are quite slow and their usage if disk makes the computer almost useless.
Code: Select all
Visiting: _"Easy"
Segmentation fault (core dumped)
This is what I got with gdb.
Spoiler:
Sorry for the time it took, but these processes are quite slow and their usage if disk makes the computer almost useless.