Could not save the game every turn in multiplayer (1.11.16)

[scwizard]

I didn't experience this in 1.10.

Here's a screenshot: http://i.imgur.com/hRrTKWT.png

I've attached the stderr.

Operating system is windows 7.

[scwizard]

Oh this is a problem with non ASCII characters: http://forums.wesnoth.org/viewtopic.php?f=4&t=36033

Specifically the — character which just happens to be in all multiplayer map names. What's wrong with the - character

[iceiceice]

What's wrong with the - character

Wesnoth adheres to a comprehensive typography style guide: Typography_Style_Guide

So, the - character doesn't cut it.

The real problem is that our file system code doesn't handle non-ascii characters on all platforms. We actually had a patch to fix this in april, but following a mailing list discussion it was decided that it can't be merged in 1.12 branch. https://github.com/wesnoth/wesnoth/pull/155

I don't really agree with that decision, but anyways it unfortunately means that we are stuck with these kinds of bugs.

[scwizard]

What's wrong with the - character

Wesnoth adheres to a comprehensive typography style guide: Typography_Style_Guide

So, the - character doesn't cut it.

The real problem is that our file system code doesn't handle non-ascii characters on all platforms. We actually had a patch to fix this in april, but following a mailing list discussion it was decided that it can't be merged in 1.12 branch. https://github.com/wesnoth/wesnoth/pull/155

I don't really agree with that decision, but anyways it unfortunately means that we are stuck with these kinds of bugs.

How about this work around:

For systems your file system code doesn't handle ascii characters for (windows) make the default save file name based off the scenario file name rather than the name property of the scenario.

Here are the options I can think of:

* Change your typography style so that scenario names are limited to ascii characters.
* Make it so your file system code is working on windows before you release the next stable version.
* Make auto save file names based off something that doesn't have unicode characters (such as the file name of the scenario), or a new scenario property.
* Drop support for windows as a platform (please please please don't do this).
* Keep support for windows as a platform, but decide this bug isn't severe enough to block a stable release (would be delusional imo).

Any word on what option the maintainers are planning on going with?

I mean hopefully the file system code is fixed, but did the mailing list discussion conclude that the file system code would not be fixed? Or that it would not be fixed in the proposed manner?

[iceiceice]

How about this work around:

I think it has rather far reaching consequences beyond just save files (not to minimize the importance of that). For instance, in another bug report, if you don't use English as your native language there's a fairly high chance that the default install location of wesnoth will cause it to crash inexplicably at startup because of not being able to find its core files (because of non-ascii characters in the path name). I'm not sure if it would really be feasible to hack together workarounds for all problems of this genre, and it would all be pointless since we (apparently) will eventually merge this branch and fix the real problem.

I mean hopefully the filesystem code is fixed, but did the mailing list discussion conclude that the file system code would not be fixed? Or that it would not be fixed in the proposed manner?

The mailing list discussion was about whether to add a standard library required for this branch to work. This was not permitted. The way this kind of thing works, the person/people who argue against adding a library don't have to take responsibility for providing an alternate solution. In this case though, realistically it would be a huge pain to get this to work without using this or a similar library.

[scwizard]

This was not permitted. The way this kind of thing works, the person/people who argue against adding a library don't have to take responsibility for providing an alternate solution.

If the maintainers ever want to release then someone will have to propose a solution that they will permit. Fingers crossed this happens.

[scwizard]

Oh I just realized this bug is in the stable release too...

That's kind of depressing...

[iceiceice]

After internal discussion and some work, we were able to merge the all of the new filesystem code into master branch.
We are now evaluating the results, to decide whether the results are good enough to go to 1.12 branch without causing regressions.

We really need for everyone who is able to test the new code and report if it gives them problems.
It seems to fix all of the problems for windows machines we have tested.
*If* we have confidence that it is also working at least as well for most users, then we will backport to 1.12.
If it turns out there are obscure platform-specific bugs for some users... we probably will not revert this change once it is on 1.12.
So we need to know about such problems as soon as possible.

If you are on windows: the easiest way to do this is,

1. Get a copy of the repo. You need an up-to-date 1.13.0 data directory.
   
   https://github.com/wesnoth/wesnoth/archive/master.zip
   
   This is a very large download, the alternative is to use git.
   
   (See also WesnothRepository.)
2. Get a copy of the most recent executable. Jenkins builds this on a daily basis:
   
   http://baldras.wesnoth.org:8080/job/Wes ... an7-32/ws/
   
   • Put wesnoth-master.exe in the base of the repo (just below the "data" directory).
   • Put mingwm10.dll next to it.
   EDIT:
3. Put the usual libraries that wesnoth needs, also next to wesnoth-master.exe. You can get these by downloading the 1.11 library bundle: http://sourceforge.net/projects/wesnoth ... p/download
   
   and moving all the *.dll files from /bin/ to your repo.
   
   (All of the new libraries mentioned above are in fact compiled into wesnoth-master.exe, so the 1.11 .dll collection is sufficient.)
   EDIT:
4. This might not now be necessary, but earlier it helped someone on irc to:
   • Also grab this .dll: http://filebin.ca/1eIee43Hfobh/libgcc_s_sjlj-1.dll
   • Rename libintl-8.dll to intl.dll

If you are on mac / linux, the easiest way to test right now is probably to compile from sources. On windows you could also compile from sources, but I believe the dependencies in all of the listed CompilingWesnothOnWindows methods are now out of date, so you would have to find the new libs yourself or wait until someone updates them. (mattsc says he will update the OS X lib collection soon.)

Thanks in advance for any help to fix these problems.

[Pentarctagon]

On windows you could also compile from sources, but I believe the dependencies in all of the listed CompilingWesnothOnWindows methods are now out of date, so you would have to find the new libs yourself or wait until someone updates them.

The download in my instructions has been updated with the new requirements.

Also as for the testing, I copy/pasted my existing wesnoth into a directory called áÇØßÜ and got this on trying to start it:

Code: Select all

Battle for Wesnoth v1.13.0-dev
Started on Sun Oct 19 13:01:25 2014

Automatically found a possible data directory at S:/áÇØßÜ/Battle_for_Wesnoth_1.13
Caught general exception:
boost::filesystem::path codecvt to wstring: error

Using Win7 64-bit.

[gfgtdf]

i tried to reproduce by using the same names ("áÇØßÜ") but i couldnt reproduce this. Could you please, if possible, give a stacktrace of when the boost exception was thrown ?

[Pentarctagon]

i tried to reproduce by using the same names ("áÇØßÜ") but i couldnt reproduce this. Could you please, if possible, give a stacktrace of when the boost exception was thrown ?

This is the result I got:

Code: Select all

C:\Users\Nano>gdb S:\áÇOßÜ\Battle_for_Wesnoth_1.13\wesnoth.exe
Reading symbols from S:\áÇOßÜ\Battle_for_Wesnoth_1.13\wesnoth.exe...done.
Starting program: S:\áÇOßÜ\Battle_for_Wesnoth_1.13\wesnoth.exe
[New Thread 6912.0x1ae4]
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
warning: while parsing target library list: not well-formed (invalid token)
[New Thread 6912.0x1094]
Catchpoint 1 (exception caught), 0x00c49059 in __cxa_begin_catch ()
Single stepping until exit from function __cxa_begin_catch,
which has no line number information.
SDL_main (argc=1, argv=0x302704a0) at src\wesnoth.cpp:860
860                     std::cerr << "Caught general exception:\n" << e.what() <
< std::endl;
861                     return 1;
858             } catch(std::exception & e) {
879     } // end main
0x00bcc47f in console_main ()
Single stepping until exit from function console_main,
which has no line number information.

Program exited with code 01.

edit - did some reading and was able to get more (hopefully useful) information.

[gfgtdf]

i talked with loonycyborg about this issue, and this seems to be a mingw only issue (thats why i coudn't rproduce it with my msvc build).

My proposed fix is thise one https://github.com/wesnoth/wesnoth/pull/305, especialy this commit: https://github.com/gfgtdf/wesnoth-old/c ... 2014f9b290

Note that this requires boost iostream 1.44 to compile (actualy im not sure about that).

It is also possible that it raises boost iostream requirements to 1.48. I already have a fix for that would remove the version 1.48 requirement but i dont want to add it unless i am sure that it's needed.

[loonycyborg]

I have really weird problems debugging this with gdb. Even if I compile with -g it still can't step through main even.

[Pentarctagon]

i talked with loonycyborg about this issue, and this seems to be a mingw only issue (thats why i coudn't rproduce it with my msvc build).

My proposed fix is thise one https://github.com/wesnoth/wesnoth/pull/305, especialy this commit: https://github.com/gfgtdf/wesnoth-old/c ... 2014f9b290

Note that this requires boost iostream 1.44 to compile (actualy im not sure about that).

It is also possible that it raises boost iostream requirements to 1.48. I already have a fix for that would remove the version 1.48 requirement but i dont want to add it unless i am sure that it's needed.

This did fix it for me. Wesnoth started and the only things in the stderr were a bunch of the "warning replay: MP synchronization called during an unsynced context.<timestamp>" warnings that have been there forever.

[gfgtdf]

This did fix it for me.

Im happy that fixed it, actualy im a little surpired that it fxed it since after a discussion it loonycyborg yesterday i thought the cause might be simething diffetn still.

Wesnoth started and the only things in the stderr were a bunch of the "warning replay: MP synchronization called during an unsynced context.<timestamp>" warnings that have been there forever.

This warning incicates potential sources of oos.
Especialy if comes if you do one of the following things:
1) using [get_global_variable], [message] with options or luas wesnoth.syncronize_choice during prestart events
2) using [get_global_variable], [message] with options or luas wesnoth.syncronize_choice during select events
3) using [get_global_variable], [message] with options or luas wesnoth.syncronize_choice during victory events.
If yes that thats the cause of these messages and you don't have to worry if you dot get OOS
If no you miight have found a bug in wesnoth.

Especialy 3) Is not a real cause of oos since the game is already over duing vicroy events.
If this warning has too many false positives we can simply remove it from 1.12.