1.3.12 indeed unstable
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:
1.3.12 indeed unstable
It seems that not only does the Windows build crash at the end of every game, and sometimes during, but it seems that Linux and Mac users have been crashing as well, though I have little information from those users.
On Windows (Vista Business), I consistantly crash whenever a game ends for any reason: win and end, lose and end, quit, and sometimes during the game at seemingly random times.
Just want to put this info out there for you guys to look into.
-edit-
And just now I was merely sitting in the lobby and it crashed...
On Windows (Vista Business), I consistantly crash whenever a game ends for any reason: win and end, lose and end, quit, and sometimes during the game at seemingly random times.
Just want to put this info out there for you guys to look into.
-edit-
And just now I was merely sitting in the lobby and it crashed...
-
- Retired Developer
- Posts: 1086
- Joined: September 16th, 2005, 5:44 am
- Location: Hamburg, Germany
Tried a new build and whatever i do, i don't seem to crash, neither with the official build, nor with the new one .
Which pops up an idea: Most crashes seem to have to do with msvcrt.dll. Maybe that file is needed with the version corresponding to the relevant operating system. Well, those who crash all the time, will you just rename this DLL and see if it gets better, please (it's a very common DLL present on almost any windows, i just included it to be absolutely sure it's there)?
Which pops up an idea: Most crashes seem to have to do with msvcrt.dll. Maybe that file is needed with the version corresponding to the relevant operating system. Well, those who crash all the time, will you just rename this DLL and see if it gets better, please (it's a very common DLL present on almost any windows, i just included it to be absolutely sure it's there)?
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
Actually I'd go even further and suggest using msvcp80.dll. It can be googled for or found here :
http://www.dll-files.com/dllindex/dll-f ... ml?msvcp80
And it's true, I do not have any runtime errors.
Edit : I do have them, but not as often
http://www.dll-files.com/dllindex/dll-f ... ml?msvcp80
And it's true, I do not have any runtime errors.
Edit : I do have them, but not as often
Last edited by Mist on December 10th, 2007, 9:57 am, edited 1 time in total.
Somewhere, between the sacred silence and sleep.
Disorder.
Disorder.
msvcrt.dll was to blame for crashes!!!
msvcrt is like glibc so you should have only version made for your system or it will make wrong system calls that will results to crashes.
Maybe someone should put notice to frontpage that everyone knows to delete it.
GDB still reports problems in calls to c runtime but that might be bug in gdb vista support.
"warning: Invalid parameter passed to C runtime function."
msvcrt is like glibc so you should have only version made for your system or it will make wrong system calls that will results to crashes.
Maybe someone should put notice to frontpage that everyone knows to delete it.
GDB still reports problems in calls to c runtime but that might be bug in gdb vista support.
"warning: Invalid parameter passed to C runtime function."
You're basicaly right but this statement
Oficial advice at the moment is to get rid of msvcrt.dll from the wesnoth root directory and put msvcp80.dll in that place without renaming the latter. It won't sort out timeout problems as they are not a CRT issue.
is false.msvcrt is like glibc so you should have only version made for your system or it will make wrong system calls that will results to crashes.
Oficial advice at the moment is to get rid of msvcrt.dll from the wesnoth root directory and put msvcp80.dll in that place without renaming the latter. It won't sort out timeout problems as they are not a CRT issue.
Somewhere, between the sacred silence and sleep.
Disorder.
Disorder.
msvcrt.dll is the c-runtime of vc6Mist wrote: Oficial advice at the moment is to get rid of msvcrt.dll from the wesnoth root directory and put msvcp80.dll in that place without renaming the latter. It won't sort out timeout problems as they are not a CRT issue.
msvcr80.dll is the c-runtime of vc8
msvcp80.dll is the c++-runtime of vc8
so "replacing" msvcrt.dll by msvcp80.dll is nonsense, they don't export the same functions
Besides that, msvcp80.dll will never be loaded when wesnoth was compiled with vc6, and if it's compiled with vc8 then msvcrt.dll will never be loaded.
Just for the record, I'm getting the same crashes no matter which runtimes I have in the wesnoth directory (even if all are deleted).
Wesnoth was not compiled with VC. CRT libraries are just satysfying secondary dependencies for libraries such as libintl. These libraries are built to use either C Runtime library or C++ runtime library (msvcr or msvcp) depending on enviroment they are used in. So replacing C library with a C++ one for use with aplication written in C++ makes a little bit of sense in this context. If you don't have a .dll in your root directory one from system directory is used (you have to have at least msvcp6 and msvcrt to run IE)
And yes we are aware it doesn't solve all crashes, but it eliminates some of them (ie. one resulting from large file load). There are at least two more issues to this, one identified already, and one with a strong suspect.
As i said before replacing .dlls is official advice for now, it doesn't solve the issue but makes play possible.
And yes we are aware it doesn't solve all crashes, but it eliminates some of them (ie. one resulting from large file load). There are at least two more issues to this, one identified already, and one with a strong suspect.
As i said before replacing .dlls is official advice for now, it doesn't solve the issue but makes play possible.
Somewhere, between the sacred silence and sleep.
Disorder.
Disorder.
Allright, after few days of work and with huge help from Soliton and Mordante I've managed to produce a build that *seems* to be stable on Windows and *doesn't crash on my machine in any place it used to* . Now it needs testing on different setups and by more people
This is package contain wesnoth.exe with required .dlls. It is built with debug support enabled so you may use gda(also included) to provide backtrace for any crashes you might enable.
http://www.mistbinder.org/wesnoth/wesno ... _build.zip
For people compiling by themselves a patch to be applied to sources
https://gna.org/patch/index.php?883
IMPORTANT INFORMATION :
This is a trunk build, it may be put in 1.3.12 file tree but you have to connect to games.tuxfamily.org
If your CPU has more than one core you have to set wesnoth.exe to work on only one of them. If you don't do that the game WILL crash as it immensly screws multithreading and exception handling.
This is package contain wesnoth.exe with required .dlls. It is built with debug support enabled so you may use gda(also included) to provide backtrace for any crashes you might enable.
http://www.mistbinder.org/wesnoth/wesno ... _build.zip
For people compiling by themselves a patch to be applied to sources
https://gna.org/patch/index.php?883
IMPORTANT INFORMATION :
This is a trunk build, it may be put in 1.3.12 file tree but you have to connect to games.tuxfamily.org
If your CPU has more than one core you have to set wesnoth.exe to work on only one of them. If you don't do that the game WILL crash as it immensly screws multithreading and exception handling.
Somewhere, between the sacred silence and sleep.
Disorder.
Disorder.