Has anyone tried Wine with Linux kernel 2.6.9? I'm getting crashes with this version that don't happen when I reboot back to 2.6.8.1. I haven't had much luck debugging it so far, but each time, ps shows a <defunct> wine-preloader process and wineserver still running.
I'm using Slackware 9.1/Linux 2.6.9, and I haven't seen anything out of the usual. The CrossOver Wine tree that I'm using may be a little older than the WineHQ cvs though (3-4 months), and Slackware doesn't use NPTL as yet.
Mike
Paul Rupe wrote:
Has anyone tried Wine with Linux kernel 2.6.9? I'm getting crashes with this version that don't happen when I reboot back to 2.6.8.1. I haven't had much luck debugging it so far, but each time, ps shows a <defunct> wine-preloader process and wineserver still running.
Hi,
On Freitag 12 November 2004 14:58, Paul Rupe wrote:
Has anyone tried Wine with Linux kernel 2.6.9? I'm getting crashes with this version that don't happen when I reboot back to 2.6.8.1. I haven't had much luck debugging it so far, but each time, ps shows a <defunct> wine-preloader process and wineserver still running.
I'm using 2.6.9 + Wine and I haven't noticed any problems.
Regards,
David
I've got an app now that I can reliably provoke into crashing under 2.6.9, but unfortunately it's our internal Remedy ticketing system. I'm running on FC3 and I've tried both Redhat's 2.6.9-1.667 kernel and a plain 2.6.9 I built from kernel.org.
There is a message in the log, but it may just be a failure handling the error, not the cause of the crash itself. err:seh:setup_exception stack overflow 644 bytes in thread 0009 eip 77ee762e esp 77830d7c stack 0x77830000-0x77930000
Paul Rupe wrote:
I've got an app now that I can reliably provoke into crashing under 2.6.9, but unfortunately it's our internal Remedy ticketing system. I'm running on FC3 and I've tried both Redhat's 2.6.9-1.667 kernel and a plain 2.6.9 I built from kernel.org.
Well, i use FC2 with plain Linus 2.6.9 + NVidia binary graphics card driver and no problem so far (besides make test crashing sometimes X with the xrandr tests). Btw. does wine crash only with Remedy or does winemine crash too?
There is a message in the log, but it may just be a failure handling the error, not the cause of the crash itself. err:seh:setup_exception stack overflow 644 bytes in thread 0009 eip 77ee762e esp 77830d7c stack 0x77830000-0x77930000
You could check if the glibc behaves differently under a kernel < 2.6.9. Asked the Red Hat glibc maintainer and he said "maybe waitid()".
bye michael
On Friday November 12 2004 11:48 am, Michael Stefaniuc wrote:
Btw. does wine crash only with Remedy or does winemine crash too?
Most apps (winemine included) are ok. When I get home I'll try to find a downloadable app that reproduces the problem consistently.
Usually wine just hangs until I kill -9 everything, but this time I managed to get a stack trace. It looks like a recursive loop: =>1 0x7759b155 cxx_frame_handler+0x401 in msvcrt (0x77927f90) 2 0x7759b5c3 in msvcrt (+0xb5c3) (0x77927fb4) 3 0x77ee7be1 __wine_call_from_32_regs+0xb5 in ntdll (0x7792831c) 4 0x7759ac79 __CxxFrameHandler+0x5 in msvcrt (0x77928358) 5 0x77ec63b8 EXC_RtlRaiseException+0x18c in ntdll (0x779283ec) 6 0x77edf32b raise_segv_exception+0x2f in ntdll (0x77928408) 7 0x77ee7c50 __wine_call_from_32_restore_regs+0x0 in ntdll (0x779287d4) ... 90 0x77edf32b raise_segv_exception+0x2f in ntdll (0x7792f7d8) Frames 2-7 repeat all the way down to 90. This is after a 'make clean' and a full rebuild of Wine, btw.
On Fri, 12 Nov 2004 14:19:30 -0500, Paul Rupe prupe@myrealbox.com wrote:
On Friday November 12 2004 11:48 am, Michael Stefaniuc wrote:
Btw. does wine crash only with Remedy or does winemine crash too?
Most apps (winemine included) are ok. When I get home I'll try to find a downloadable app that reproduces the problem consistently.
Usually wine just hangs until I kill -9 everything, but this time I managed to get a stack trace. It looks like a recursive loop: =>1 0x7759b155 cxx_frame_handler+0x401 in msvcrt (0x77927f90) 2 0x7759b5c3 in msvcrt (+0xb5c3) (0x77927fb4) 3 0x77ee7be1 __wine_call_from_32_regs+0xb5 in ntdll (0x7792831c) 4 0x7759ac79 __CxxFrameHandler+0x5 in msvcrt (0x77928358) 5 0x77ec63b8 EXC_RtlRaiseException+0x18c in ntdll (0x779283ec) 6 0x77edf32b raise_segv_exception+0x2f in ntdll (0x77928408) 7 0x77ee7c50 __wine_call_from_32_restore_regs+0x0 in ntdll (0x779287d4) ... 90 0x77edf32b raise_segv_exception+0x2f in ntdll (0x7792f7d8) Frames 2-7 repeat all the way down to 90. This is after a 'make clean' and a full rebuild of Wine, btw.
-- Paul Rupe prupe@myrealbox.com
I just installed Mandrake 10.1 Official and I'm getting this exact error with any app I try to run with wine.
kernel: 2.6.8.1-12mdk
I will be doing regression tests to see what's going on here.
On Fri, 12 Nov 2004 17:47:05 -0500, James Hawkins truiken@gmail.com wrote:
On Fri, 12 Nov 2004 14:19:30 -0500, Paul Rupe prupe@myrealbox.com wrote:
On Friday November 12 2004 11:48 am, Michael Stefaniuc wrote:
Btw. does wine crash only with Remedy or does winemine crash too?
Most apps (winemine included) are ok. When I get home I'll try to find a downloadable app that reproduces the problem consistently.
Usually wine just hangs until I kill -9 everything, but this time I managed to get a stack trace. It looks like a recursive loop: =>1 0x7759b155 cxx_frame_handler+0x401 in msvcrt (0x77927f90) 2 0x7759b5c3 in msvcrt (+0xb5c3) (0x77927fb4) 3 0x77ee7be1 __wine_call_from_32_regs+0xb5 in ntdll (0x7792831c) 4 0x7759ac79 __CxxFrameHandler+0x5 in msvcrt (0x77928358) 5 0x77ec63b8 EXC_RtlRaiseException+0x18c in ntdll (0x779283ec) 6 0x77edf32b raise_segv_exception+0x2f in ntdll (0x77928408) 7 0x77ee7c50 __wine_call_from_32_restore_regs+0x0 in ntdll (0x779287d4) ... 90 0x77edf32b raise_segv_exception+0x2f in ntdll (0x7792f7d8) Frames 2-7 repeat all the way down to 90. This is after a 'make clean' and a full rebuild of Wine, btw.
-- Paul Rupe prupe@myrealbox.com
I just installed Mandrake 10.1 Official and I'm getting this exact error with any app I try to run with wine.
kernel: 2.6.8.1-12mdk
I will be doing regression tests to see what's going on here.
-- James Hawkins
I forgot to mention that I'm using latest wine CVS.
On Fri, 12 Nov 2004 17:47:57 -0500, James Hawkins wrote:
Most apps (winemine included) are ok. When I get home I'll try to find a
downloadable app that reproduces the problem consistently.
Usually wine just hangs until I kill -9 everything, but this time I managed to get a stack trace. It looks like a recursive loop: =>1 0x7759b155 cxx_frame_handler+0x401 in msvcrt (0x77927f90) 2 0x7759b5c3 in msvcrt (+0xb5c3) (0x77927fb4) 3 0x77ee7be1 __wine_call_from_32_regs+0xb5 in ntdll (0x7792831c) 4 0x7759ac79 __CxxFrameHandler+0x5 in msvcrt (0x77928358) 5 0x77ec63b8 EXC_RtlRaiseException+0x18c in ntdll (0x779283ec) 6 0x77edf32b raise_segv_exception+0x2f in ntdll (0x77928408) 7 0x77ee7c50 __wine_call_from_32_restore_regs+0x0 in ntdll (0x779287d4) ... 90 0x77edf32b raise_segv_exception+0x2f in ntdll (0x7792f7d8) Frames 2-7 repeat all the way down to 90. This is after a 'make clean' and a full rebuild of Wine, btw.
This problem has been floating around for a while, though it doesn't seem to be easily reproduceable. Rob looked at it I think ... basically this isn't going to be easy. It looks like we're crashing inside the relay/thunk assembly.
Paul Rupe wrote:
Has anyone tried Wine with Linux kernel 2.6.9? I'm getting crashes with this version that don't happen when I reboot back to 2.6.8.1. I haven't had much luck debugging it so far, but each time, ps shows a <defunct> wine-preloader process and wineserver still running.
What happens when you kill the wineserver?
I have seen errors where killed wine processes remained defunct even after their parent has died. They were rebooted to init, but still remained defunct. In certain (RedHat 2.4) kernels, such processes could even keep sockets bound to ports, requiring a reboot.
While this is obviously a kernel bug, I wasn't able to form a reconstruction in a way suiteable for having a kernel guru have a look at it. The system with which this problem was happening was too complex (and proprietary) to ship to someone else, and the problem was inconsistant.
Shachar
Shachar Shemesh wrote:
I have seen errors where killed wine processes remained defunct even after their parent has died. They were rebooted to init, but still remained defunct. In certain (RedHat 2.4) kernels, such processes could even keep sockets bound to ports, requiring a reboot.
I had zombie process problems like that with Linux 2.6.[0-7] but they seem to have gone away in Linux 2.6.[89]. They tended to happen when wine-kthreads processes crashed.
Mike
-
David Gümbel -
James Hawkins -
Michael Stefaniuc -
Mike Hearn -
Mike McCormack -
Paul Rupe -
Shachar Shemesh