1.11.5 can't get campaigns to run

[Crow_T]

as reported here: https://gna.org/bugs/?20951
Anyone else having this problem? I built from source using make- re-downloaded the source and tried again, no dice. I am running wesnoth from the terminal. 1.11.4 works fine, built/ran the same way.

[Iris]

So the bug report is yours? Do you have any add-ons installed? Could you list them?

[Crow_T]

Yep that's my report- I removed all of the addons, and I just now deleted the entire 1.11 folder that contains the addons and tried running wesnoth again, it still just hangs.

terminal output is identical when starting 1.11.5 and 1.11.4

[Iris]

terminal output is identical when starting 1.11.5 and 1.11.4

Note that anonymissimus asked you to attach the --log-debug=all output (the full output) in the tracker and you haven’t done so yet. Just the last line generally won’t suffice to diagnose a problem.

[Crow_T]

Is there a more elegant way to do this? There are so many lines generated that the top part is getting cut off (I'm no terminal expert). I'm getting this repeated a lot though:

Code: Select all

The config object has no child named »filter«.
20130717 20:33:26 debug config: The config object has no child named »filter_vision«.
20130717 20:33:26 debug config: The config object has no child named »filter_adjacent_location«.
20130717 20:33:26 debug config: The config object has no child named »filter_owner«.

If this means nothing I'll try again tomorrow using gnome terminal or find a better one somewhere...

[Iris]

Is there a more elegant way to do this?

Code: Select all

$ wesnoth --log-debug=all 2> path/to/output_file.txt

The 2> operator above redirects file descriptor 2 (stderr) to the specified file, clobbering any previous contents in it.

[Crow_T]

OK, huge txt file is up at the bug tracker, thanks for the tips.

[Max]

the problem described in this thread sounds similar:
http://forums.wesnoth.org/viewtopic.php ... 25#p544425

[Crow_T]

Well Max, you found the answer- building with scons instead of make worked. Thanks!

[Iris]

Well Max, you found the answer- building with scons instead of make worked. Thanks!

If you have time, could you run make clean, then make VERBOSE=1 and record the full command line printed on the screen for each .cpp file? (Yes, that’s a rebuild using the cmake configuration.) You can use make | tee logfile.txt to record the output to logfile.txt in the current directory automatically. Additionally, I’d also want to see the scons build log as it appears during the scons build, what compiler you are using, and what version it is (e.g. the output of gcc --version for GCC).

(The point is that there is an issue that is most likely linked to the compiler option set used by the cmake recipe, so if we want to look into it we need to know the environment conditions that trigger it.)

[Iris]

From bug #20951 [Gna.org], for whoever might want to help us understand this bug better:

Since the reporter seems to not be interested in providing additional information in the forums [1], I'm posting this here as well.

[1] http://forums.wesnoth.org/viewtopic.php ... 70#p557270

I would suspect that there's a problem with compiler optimizations at work here. If my memory serves, the default used with scons is -O2, whereas cmake uses -O3 for Release builds. I personally use -O3 -march=native with scons here, running gcc version 4.7.2 and a full amd64 Debian wheezy system, and I have not seen anything like this so far with 1.11.x or 1.10.x. From what I read, Ubuntu 13.04 (raring)'s default is gcc 4.7.3 [2]. I expect that both the Debian wheezy and raring gcc packages include additional patches that could have something to do with this bug.

[2] http://packages.ubuntu.com/raring/gcc

Additionally, a gdb backtrace would be very helpful.

[Crow_T]

Additionally, a gdb backtrace would be very helpful.

If this is a simple one step thing I can try I can give it a shot. I've been out of the loop because of some real life things, but if you guys could put the commands into a format that I ould copy/paste that would help a lot. I don't code so I'm not really familiar with build environments. The GCC version that I have installed is 4.7.3

Is anyone else having this problem btw?

[Iris]

If this is a simple one step thing I can try I can give it a shot.

You would need to make sure you have gdb installed in your package manager, and use cmake to produce a faulty Wesnoth build again. What I said above about gathering more information during the build still applies, but you may just provide a copy of the CMakeCache.txt file from the build dir instead.

Then, load Wesnoth on gdb on a terminal emulator window. The following will load the Wesnoth binary named ./path/to/wesnoth, redirect stderr to stdout, and record stdout in a file named debug-session-log.txt in the current directory.

Code: Select all

$ gdb ./path/to/wesnoth 2>&1 | tee debug-session-log.txt

In the gdb prompt, type “start” to begin running Wesnoth.

Code: Select all

(gdb) start

Once Wesnoth begins to malfunction (not before), quickly switch to the gdb window and press Ctrl+C to interrupt its execution. To generate a backtrace:

Code: Select all

(gdb) bt

And finally, to quit gdb:

Code: Select all

(gdb) q

The file created during the gdb launch step should now contain all the relevant information, hopefully. It really depends on the exact nature of the bug.

(I have just realized that cmake by default (well, cmake 2.8.9, anyway) doesn’t use the Release build type, so unless you specified a build type or optimization level explicitly, it should be the compiler default of -O0 — which only raises more questions. Hence I want to see either CMakeCache.txt or the actual compiler command line in `make VERBOSE=1`.)