[REPAIRED]1.11.1 does not seem to work

Having trouble with the game? Report issues and get help here. Read this first!

Moderator: Forum Moderators

Forum rules
Before reporting issues in this section, you must read the following topic:
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

[REPAIRED]1.11.1 does not seem to work

Post by Dugi »

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.

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)
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.
Last edited by Dugi on December 12th, 2012, 8:54 pm, edited 1 time in total.
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: 1.11.1 does not seem to work

Post by Anonymissimus »

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.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

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.

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)
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.
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: 1.11.1 does not seem to work

Post by Anonymissimus »

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.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

Okay, this is what it said about the segmentation fault.

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&) ()
I'll post about it there.
AI
Developer
Posts: 2396
Joined: January 31st, 2008, 8:38 pm

Re: 1.11.1 does not seem to work

Post by AI »

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.
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

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_
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: 1.11.1 does not seem to work

Post by Anonymissimus »

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.)
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

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).
Spoiler:
Is that enough?
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: 1.11.1 does not seem to work

Post by Anonymissimus »

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.)
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

According to the information how to build it (using make), I should do this in the folder (if I am correct):

Code: Select all

cmake .
make -DCMAKE_BUILD_TYPE=Debug
sudo make install
But it does not seem to want to take that argument. Am I doing something wrongly?
Anonymissimus
Inactive Developer
Posts: 2461
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: 1.11.1 does not seem to work

Post by Anonymissimus »

I think it should be (the Debug argument needs to be passed to cmake at least)

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Debug
make wesnoth
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.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

Okay, this is the gdb output now:
Spoiler:
Btw, what is the chance that the archive was damaged during downloading and checksums haven't noticed it?
JaMiT
Inactive Developer
Posts: 511
Joined: January 22nd, 2012, 12:38 am

Re: 1.11.1 does not seem to work

Post by JaMiT »

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 src/serialization/parser.cpp. Line 504 should be

Code: Select all

			out_ << '"' << escaped_string(w.begin(), w.end()) << '"';
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.

Code: Select all

			std::cerr << "Visiting: ";
			std::string part(w.begin(), w.end());
			std::cerr << "_\"" << part << "\"\n";
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 to parser.cpp and change line 504 to

Code: Select all

			out_ << '"' << escaped_string(std::string(w.begin(), w.end())) << '"';
Does the crash still occur? Still in escaped_string?
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: 1.11.1 does not seem to work

Post by Dugi »

When I did the first edit, this is all I got into Terminal (except the usual locations of directories and screen resolution):

Code: Select all

Visiting: _"Easy"
Segmentation fault (core dumped)
No idea what can it mean.


This is what I got with gdb.
Spoiler:
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.
Post Reply