Quoting Marcus Meissner marcus@jet.franken.de:
On Thu, Dec 08, 2005 at 12:35:32PM +1000, Cihan Altinay wrote:
Hi,
having a Xen system my Linux tls library path is not in place (renamed to /lib/tls.disabled). When I run a program that uses OLE/DCOM (with native ole libraries) it crashes immediately. Using LD_LIBRARY_PATH=/lib/tls.disabled wine program makes it work again. I am not sure if this is true for all OLE apps.
Is this known/expected behaviour or a bug?
Do you have a backtrace of the crash or similar?
Just wanted to create one with the latest CVS but it seems it was fixed some days ago. I investigated a bit and to my surprise the problem was in x11drv which was patched 2005-12-06. We had that problem since weeks and were "happy" with the library path solution until I thought I might ask here. So it was quite a surprise that it was fixed just now :-)
Thanks anyway, Cihan
Ok, I am replying to myself as the problem persists.
Quoting Cihan Altinay cihan@uq.edu.au:
Quoting Marcus Meissner marcus@jet.franken.de:
On Thu, Dec 08, 2005 at 12:35:32PM +1000, Cihan Altinay wrote:
Hi,
having a Xen system my Linux tls library path is not in place (renamed to /lib/tls.disabled). When I run a program that uses OLE/DCOM (with native ole libraries) it crashes immediately. Using LD_LIBRARY_PATH=/lib/tls.disabled wine program makes it work again. I am not sure if this is true for all OLE apps.
Is this known/expected behaviour or a bug?
Do you have a backtrace of the crash or similar?
Just wanted to create one with the latest CVS but it seems it was fixed some days ago. I investigated a bit and to my surprise the problem was in x11drv which was patched 2005-12-06.
Obviously this is not true. I found out that the following happens: When I ran the program first thing this morning I got the following (with disabled tls libraries):
wine: Unhandled page fault on read access to 0x7e7ffd80 at address 0xb7f223a3 (thread 000f), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x7f6c5560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000d, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7f6c5560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000b, blocked by 000f, retrying (60 sec) err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file rpcrt4.dbg ("rpcrt4.dbg") wine: Unhandled exception 0x0eedfade at address 0x0000:0x404cc6f0 (thread 0009), starting debugger... WineDbg starting on pid 0x8
(I couldn't get it to crash yet with WINEDEBUG=relay so that's all output I can give at the moment...)
If I run it again directly afterwards it works fine - until I wait for some time (after wineserver has quit) or if I start other programs (like firefox) it seems. That makes me suspect that it crashes if the process memory of one of the libraries (or the program itself) is not in the cache anymore and has to be reloaded.
The program is G-Ware which can be downloaded here: http://clearone.com/docs/downloads/G-Ware5.0.6.zip [~20MB] (works only with native ole)
When starting up it uses DCOM to start a "server" (PSRServe.exe). Two comments on this: - Even if it crashes it succeeds starting the server - If the server is started manually (wine psrserve.exe) the program doesn't crash
As said before, the program works fine when the TLS libraries are in the library path.
Cheers, Cihan
Hi, A very basic C++ program fails with
err:ntdll:RtlpWaitForCriticalSection section 0x7f64c560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001c, blocked by 001e, retrying (60 sec)
when the Linux TLS libraries are not in the library path (it works fine otherwise). The program does: CoInitialize() CoCreateInstance(<powerpoint viewer 97 clsid>) <dispatch the method "NewShow" to load and start a powerpoint presentation> CoUninitialize() quit
I am happy to send the source/binary if it is of any help. I am trying to find out what is going on but the problem is that wine does not crash - the program does its job, powerpoint viewer starts up and shows the first slide but then after my program has quit the critical section times out (ie. the message is from the viewer). I tried different trace outputs with no luck. Note that since wine's builtin OLE libraries can't handle CoCreateInstance yet I am using natives.
Does anybody have a suggestion how to track that down?
Thanks a lot, Cihan
Cihan Altinay cihan@uq.edu.au writes:
Hi, A very basic C++ program fails with
err:ntdll:RtlpWaitForCriticalSection section 0x7f64c560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001c, blocked by 001e, retrying (60 sec)
when the Linux TLS libraries are not in the library path (it works fine otherwise).
Non-TLS libraries in recent glibc versions are not compatible with Wine. What are you trying to do that requires not using TLS?
Quoting Alexandre Julliard julliard@winehq.org:
Cihan Altinay cihan@uq.edu.au writes:
Hi, A very basic C++ program fails with
err:ntdll:RtlpWaitForCriticalSection section 0x7f64c560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001c, blocked by 001e,
retrying (60
sec)
when the Linux TLS libraries are not in the library path (it works fine otherwise).
Non-TLS libraries in recent glibc versions are not compatible with Wine. What are you trying to do that requires not using TLS?
Thanks for the info. I am running a Xen[1] system which currently has to emulate unsupported lib/tls library calls. And that makes the system very slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls folder out of the way. Everything seems to work fine except wine apps that use OLE. Do you think the dependency of wine on TLS will stay in future versions?
Thanks, Cihan
Cihan Altinay cihan@uq.edu.au writes:
Thanks for the info. I am running a Xen[1] system which currently has to emulate unsupported lib/tls library calls. And that makes the system very slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls folder out of the way. Everything seems to work fine except wine apps that use OLE. Do you think the dependency of wine on TLS will stay in future versions?
Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc 2.3. They work fine with glibc 2.2 though.
Alexandre Julliard wrote:
Do you think the dependency of wine on TLS will stay in future versions?
Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc 2.3. They work fine with glibc 2.2 though.
TLS can work with Xen, but you have to patch glibc and use -mno-tls-direct-seg-refs.
More info (well mostly just assembler code): http://wiki.xensource.com/xenwiki/XenSpecificGlibc
Can we change our linuxwrappers for a work-around?
Thanks, Vijay
On 12/16/05, Alexandre Julliard julliard@winehq.org wrote:
Cihan Altinay cihan@uq.edu.au writes:
Thanks for the info. I am running a Xen[1] system which currently has to emulate unsupported lib/tls library calls. And that makes the system very slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls folder out of the way. Everything seems to work fine except wine apps that use OLE. Do you think the dependency of wine on TLS will stay in future versions?
Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc 2.3. They work fine with glibc 2.2 though.
-- Alexandre Julliard julliard@winehq.org
Vijay Kiran Kamuju infyquest@gmail.com writes:
Can we change our linuxwrappers for a work-around?
No, there's nothing we can do, it's due to the way glibc references pthread functions internally. It would have to be fixed in glibc, but that's unlikely to happen, especially since linuxthreads is (fortunately) being phased out.
-
Alexandre Julliard -
Cihan Altinay -
Molle Bestefich -
Vijay Kiran Kamuju