Resting causing freeze/crash
#1 -jeezus-
Posted 05 April 2010 - 10:40 AM
Currently have full install of 2cd version (also tried 4cd version), using wine + mods in following order:
widescreen (1680x1050)
ghostdogs UI
fixpack 4.0
unfinished business
tweak pack
Every time after resting (in a safe place/rest anywhere tweak/dialog forced)
the game will freeze to black screen after video.
Tried several order of installing mods, clean installs etc. And the freeze is always coming
after installing the fixpack. Other then the freeze game works perfectly.
Any idea what in the fixpack could be causing the freeze after any kind of rest?
#2
Posted 05 April 2010 - 12:53 PM
Qwinn
#3 -jeezus-
Posted 05 April 2010 - 10:26 PM
Your install order is fine. I don't really change anything regarding resting, so I have no idea what could be causing that. More issues with wine, if I had to guess.
Qwinn
Yeah, probably is. Just strange it only happens with this mod. Probably some change causing incompatibility.
I'll verify on windows install today.
#4 -jeezus-
Posted 06 April 2010 - 09:22 AM
Apparently they broke something in 1.1.41, hopefully the 1.1.42 will also
have it fixed.
PS. Thanks for the hard work with the mods.
#5 -FCA-
Posted 09 April 2010 - 08:55 AM
I have the same problem, tried to locate it in Wine by git-bisect, but every version between 1.1.38 and 1.1.41 failed. Are you sure it is 1.1.38 that is working?Just wanted to let everyone know, works with wine version 1.1.38! =)
Apparently they broke something in 1.1.41, hopefully the 1.1.42 will also
have it fixed.
PS. Thanks for the hard work with the mods.
#6 -jeezus-
Posted 10 April 2010 - 05:36 AM
I have the same problem, tried to locate it in Wine by git-bisect, but every version between 1.1.38 and 1.1.41 failed. Are you sure it is 1.1.38 that is working?
Just wanted to let everyone know, works with wine version 1.1.38! =)
Apparently they broke something in 1.1.41, hopefully the 1.1.42 will also
have it fixed.
PS. Thanks for the hard work with the mods.
Yeah, 1.1.38 deb for (k)ubuntu from wine's repo is working for me (except for alt-tabbing).
#7 -FCA-
Posted 10 April 2010 - 06:26 AM
I located the source of the problem: the version of gcc used!Yeah, 1.1.38 deb for (k)ubuntu from wine's repo is working for me (except for alt-tabbing).
Compiled with gcc 4.4.3, both wine-current and wine-1.1.38 exhibit the problem.
When I compiled both 1.1.38 and current git with gcc-4.3.4, both worked without problems...
I'll try to investigate this further.
#8 -unknown78-
Posted 29 April 2010 - 02:10 PM
i can say wine 1.1.43 has the same issue and the compiler used to compile is gcc 4.5 (archlinux)
#9
Posted 23 May 2010 - 04:09 AM
I downgraded with the official Wine 1.1.38 for Ubuntu 9.04 and it works!
So this is somehow a wine + gcc regression? I guess this must be especially hard to track...
#10 -paulo-
Posted 23 May 2010 - 06:43 AM
#11 -paulo-
Posted 23 May 2010 - 07:00 AM
BTW no one has (searched google now). How do you expect bugs to be fixed if you don't report them on the right place? Are the wine devs supposed to be omniscient?Report this on wine if you haven't
http://www.winehq.or...e/bug-reporting
Anomaly, since you are the last that can reproduce this, could you report?
#12 -FCA-
Posted 01 June 2010 - 04:02 AM
As Anomaly reported, this is really hard to track down. It is a bug which only happens when you compile wine with a specific version of gcc, and you see it in the game only when you apply the fixpack.BTW no one has (searched google now). How do you expect bugs to be fixed if you don't report them on the right place? Are the wine devs supposed to be omniscient?
Report this on wine if you haven't
http://www.winehq.or...e/bug-reporting
Anomaly, since you are the last that can reproduce this, could you report?
I'd guess the bug is in gcc, but I'd have no clue how to track down the bug. I'm sure that the gcc developers want a more specific bug report then:
"*This* game, with *this* mod applied, crashes under a wine compiled with *this* gcc version when I do *this*.". If I have the time, I could try a bisect on gcc versions, to see if there is a specific commit in gcc which causes this, but this could take a long time...
#13 -i30817-
Posted 01 June 2010 - 04:24 PM
If you can't do the bisect who is to say that a dev can't do it?
Just report it, tell the problem is a regression and say you don't have the time for bisects but give steps to reproduce.
#14 -Dreamer-
Posted 22 July 2010 - 12:04 AM
#15 -Dreamer-
Posted 22 July 2010 - 12:08 AM
#16
Posted 22 July 2010 - 04:26 AM
In some areas it happens more than others, one area it did it everytime i used quickload.
#17 -megatv-
Posted 23 August 2010 - 10:41 AM
Hope this helps someone.
#18 -paulo-
Posted 24 August 2010 - 01:00 PM
You can write the information here:Seems like the bug has something to do with 64 bit distros (did anyone have the same issue on 32 bit installation?). I have Kubuntu 10.04 Lucid, 64 bit and only building 32-bit Wine 1.1.38 with gcc-4.3 (used this guide) fixed the problem for me. Trying to either build later version of Wine (tried 1.2 and 1.3) or use later version of gcc (tried 4.4) or even install 64-bit Wine leads to freezing any time your characters rest.
Hope this helps someone.
http://bugs.winehq.o...ug.cgi?id=23522
I reported it since no one else did.
#19 -paulo-
Posted 24 August 2010 - 01:14 PM
Hilarious hi-jinks------- Comment #11 From mikulas@artax.karlin.mff.cuni.cz 2009-07-31 01:00 [reply] -------
So I did this experiment whether the stack is aligned in current Linux
binaries.
I applied this patch for gcc, so that it crashes on function entry if the
function has stack not aligned on 16 bytes.
diff -urp gcc-4.4.1/gcc/varasm.c gcc-4.4.1-test-align/gcc/varasm.c
--- gcc-4.4.1/gcc/varasm.c 2009-03-17 21:18:21.000000000 +0100
+++ gcc-4.4.1-test-align/gcc/varasm.c 2009-07-25 16:18:11.000000000 +0200
@@ -1760,6 +1760,8 @@ assemble_start_function (tree decl, cons
/* Standard thing is just output label for the function. */
ASM_OUTPUT_LABEL (asm_out_file, fnname);
#endif /* ASM_DECLARE_FUNCTION_NAME */
+ if (!crtl->stack_realign_needed)
+ fputs("\tsubl\t$12, %esp\n\ttestl\t$15,
%esp\n\tjz\t99999f\n\tud2a\n99999:\taddl\t$12, %esp\n", asm_out_file);
}
/* Output assembler code associated with defining the size of the
--- and the results are terrifying:
Gcc didn't even bootstrap itself. It failed because it calls glibc function
obstack_init and it calls back to xmalloc - with misaligned stack. So I
compiled gcc without bootstrap and tried to compile glibc-2.7 with it. Glibc
compiles its integer-only code with -mpreferred-stack-boundary=2, so I changed
it to -mpreferred-stack-boundary=4.
Glibc didn't finish its build either (failed when running some self-compiled
scripts), but it at least produced libc.so.
So I tried to preload this libc.so with stack-alignment-checking to various
Linux binaries (with LD_PRELOAD) and see what happens.
Out of 95 binaries in /bin/, only 23 succeeded! The remaining crashed because
of glibc was called with unaligned stack. (the distribution is up-to-date
Debian Lenny).
The non-crashing binaries are:
bzip2recover, cpio, dmesg, fgconsole, fuser, kill, loadkeys, lsmod, lvnet,
mktemp, more (displays help only, crashes when attempting to display any file),
mount, mountpoint, mt, mt-gnu, nbd-server, pidof, ping, ping6, run-parts, sed,
su, tailf, umount
So anyone, who is saying that the stack is aligned to 16 bytes has his mind
disconnected from reality. It isn't.
I find it very unreasonable that GCC developers try to declare their own ABI
with aligned stack --- and that conflicts with what is being used by the
majority of Linux applications. GCC developers are trying to say that 3/4 of
programs in /bin/ are wrong because they don't align the stack.
I think you should really align the stack in the functions that do SSE math and
don't rely on the fact that the stack is already aligned. It is definitelly
easier to use the code for stack reallign than declaring that majority of Linux
binaries are BAD and need to be recompiled.
If some scientists needed extreme performance and can't take the penalty of
realigning the stack, you can add an option -massume-aligned-stack form them
and it is the responsibility of a given scientist that the code compiled with
this option is never called back from libc or anything else else. But don't
assume stack alignment for general code. It just isn't true.