wine-pthread hangs

[Jeremy Shaw]

Hello,

I was trying to run wine-pthread, but it hangs immediately after
startup -- I can't even hit cntl-c to exit.  If I try to run it under
gdb, it seg faults. A backtrace looks like:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14857)]
0x40040fd9 in __errno_location () from /lib/libpthread.so.0
(gdb) bt
#0  0x40040fd9 in __errno_location () from /lib/libpthread.so.0
#1  0x40515ae6 in DOSFS_ToDosFCBFormat () from /usr/lib/wine/kernel32.dll.so
#2  0x40516223 in DOSFS_FindUnixName () from /usr/lib/wine/kernel32.dll.so
#3  0x40516f21 in DOSFS_GetFullName () from /usr/lib/wine/kernel32.dll.so
#4  0x4051e8c9 in CreateFileW () from /usr/lib/wine/kernel32.dll.so
#5  0x4021c879 in RtlDoesFileExists_U () from /usr/lib/wine/ntdll.dll.so
#6  0x4021cedf in RtlDosSearchPath_U () from /usr/lib/wine/ntdll.dll.so
#7  0x40218862 in LdrGetProcedureAddress () from /usr/lib/wine/ntdll.dll.so
#8  0x40218c1c in LdrGetProcedureAddress () from /usr/lib/wine/ntdll.dll.so
#9  0x40216c80 in _aullrem () from /usr/lib/wine/ntdll.dll.so
#10 0x402170d3 in _aullrem () from /usr/lib/wine/ntdll.dll.so
#11 0x4021984b in LdrInitializeThunk () from /usr/lib/wine/ntdll.dll.so
#12 0x405511e4 in SetThreadExecutionState () from /usr/lib/wine/kernel32.dll.so
(gdb)

I am using the latest wine from CVS (as of 5pm, 11/14/2003).
Linux 2.4.22
libc6 2.3.2

Do I need to do something special to get this working?

I am trying to use wine-pthread because I want to use the winejack
driver. The winejack driver does not work correctly with wine-kthread,
because in libjack, there is a call to pthread_create which never
returns. According to usenet, this could happen because wine-kthread
is not linked against libpthread explicitly. I tried adding an
explicit -lpthread to wine-kthread, but this just cause wine-kthread
to hang (similar to wine-pthread, but in a different location).

I also tried running ./configure --enable-nptl and installing a
version of libc with nptl support, but I think nptl requires features
added in 2.5.x -- so this was probably just wishful thinking.

Thanks!
Jeremy Shaw.

[Mike Hearn]

On Sat, 2003-11-15 at 03:06, Jeremy Shaw wrote:
> I am trying to use wine-pthread because I want to use the winejack
> driver. The winejack driver does not work correctly with wine-kthread,
> because in libjack, there is a call to pthread_create which never
> returns.

That sounds like a bug in Wine. My understanding is that when using
kthreads, we emulate pthreads - hence Wine must NOT be linked against
the system pthreads lib.
> According to usenet, this could happen because wine-kthread
> is not linked against libpthread explicitly. I tried adding an
> explicit -lpthread to wine-kthread, but this just cause wine-kthread
> to hang (similar to wine-pthread, but in a different location).

Yes, I don't think that will work.

The main wine binary should now detect which version (kthread or
pthread) you need, and select it for you at runtime. You need latest CVS
for that though. If you think it's choosing the wrong one, then that
also is a bug, but you should not need to override its choice.

[Jeremy Shaw]

Hello,
> From reading some of the other messages sent today, I gather wine-pthreads requires nptl and the new (2.5.x/2.6.x) kernel?

Currently, the winejack driver itself (winejack.drv.so), is not explicitly linked against libjack or libpthread. Instead, winejack uses some function pointer and wine_dlsym tricks to load libjack at runtime. libjack (which is part of the jackit source, not wine), IS explicitly linked against libpthread.

Is there any chance this is going to work with wine-kthread? Is the function pointer/wine_dlsym tricks some work around related to the fact that libjack is linked against pthread, but wine can't be? For example, it is my understanding that wine-kthread provides pthread emulation -- is this method of loading libjack with wine_dlsym a way to get libjack to uses wine's pthread emulation instead of /lib/libpthread?

Jeremy Shaw.

On Nov 15, 2003 5:11 AM, Mike Hearn  wrote:
> On Sat, 2003-11-15 at 03:06, Jeremy Shaw wrote:
> > I am trying to use wine-pthread because I want to use the winejack 
> > driver. The winejack driver does not work correctly with wine-kthread, 
> > because in libjack, there is a call to pthread_create which never 
> > returns.
>
> That sounds like a bug in Wine. My understanding is that when using 
> kthreads, we emulate pthreads - hence Wine must NOT be linked against 
> the system pthreads lib.
> > According to usenet, this could happen because wine-kthread 
> > is not linked against libpthread explicitly. I tried adding an 
> > explicit -lpthread to wine-kthread, but this just cause wine-kthread 
> > to hang (similar to wine-pthread, but in a different location).
>
> Yes, I don't think that will work.
>
> The main wine binary should now detect which version (kthread or 
> pthread) you need, and select it for you at runtime. You need latest CVS 
> for that though. If you think it's choosing the wrong one, then that 
> also is a bug, but you should not need to override its choice.

[Marcus Meissner]

> From reading some of the other messages sent today, I gather wine-pthreads requires nptl and the new (2.5.x/2.6.x) kernel?

Yes.
> Is there any chance this is going to work with wine-kthread? Is the
> function pointer/wine_dlsym tricks some work around related to the fact
> that libjack is linked against pthread, but wine can't be?

No, just for dynamic loading of a potential present libjack.so.
> For example,
> it is my understanding that wine-kthread provides pthread emulation --
> is this method of loading libjack with wine_dlsym a way to get libjack
> to uses wine's pthread emulation instead of /lib/libpthread?

No.

Ciao, Marcus

[Jeremy Shaw]

Hello,

So, if winejack.drv.so requires libjack which is linked against
libpthread -- should it work with wine-kthread? And, if it does work,
will libjack be calling the real pthread functions in libpthread or
the emulated pthread functions in wine?

Jeremy Shaw.

At Sat, 15 Nov 2003 22:42:27 +0100,
Marcus Meissner wrote:
> > From reading some of the other messages sent today, I gather wine-pthreads requires nptl and the new (2.5.x/2.6.x) kernel?
>
> Yes.
> > Is there any chance this is going to work with wine-kthread? Is the
> > function pointer/wine_dlsym tricks some work around related to the fact
> > that libjack is linked against pthread, but wine can't be?
>
> No, just for dynamic loading of a potential present libjack.so.
> > For example,
> > it is my understanding that wine-kthread provides pthread emulation --
> > is this method of loading libjack with wine_dlsym a way to get libjack
> > to uses wine's pthread emulation instead of /lib/libpthread?
>
> No.
>
> Ciao, Marcus

[Alexandre Julliard]

Jeremy Shaw  writes:
> So, if winejack.drv.so requires libjack which is linked against
> libpthread -- should it work with wine-kthread? And, if it does work,
> will libjack be calling the real pthread functions in libpthread or
> the emulated pthread functions in wine?

Yes it should work with wine-kthread, and it will call the emulated
pthread functions. At least that's the theory, it's quite possible
that with all the recent changes something got broken; but in any case
using wine-pthread instead won't do what you want.

[Jeremy Shaw]

Hello,

I did some experiments, and I believe that something did get broken in
the recent changes -- specifically, libjack is now calling the real
pthread functions instead of the wine emulated functions.

In cvs head, in loader/kthread.c, in pthread_create() I added a
P_OUTPUT. I never see 'pthread_create' get printed.

int pthread_create(pthread_t* thread, const pthread_attr_t* attr, void*
        (*start_routine)(void *), void* arg)
{
    assert( funcs.ptr_pthread_create );
    P_OUTPUT("pthread_create.\n");
    return funcs.ptr_pthread_create( thread, attr, start_routine, arg );
}

In wine-20030618, in schedular/pthread.c, in pthread_create() I added
a similar P_OUTPUT statement, and I did see 'pthread_create get
printed.' In addition, the pthread_create() function actually
returned.

I ran nm on wine-kthread, and pthread_create() is defined:

3c0014b0 T pthread_create

Any idea how I can get things working again? I assume this is some
sort of linking issue, but I don't know where to go from here...

Jeremy Shaw.

At Sat, 15 Nov 2003 16:44:00 -0800,
Alexandre Julliard wrote:
> Jeremy Shaw  writes:
> > So, if winejack.drv.so requires libjack which is linked against
> > libpthread -- should it work with wine-kthread? And, if it does work,
> > will libjack be calling the real pthread functions in libpthread or
> > the emulated pthread functions in wine?
>
> Yes it should work with wine-kthread, and it will call the emulated
> pthread functions. At least that's the theory, it's quite possible
> that with all the recent changes something got broken; but in any case
> using wine-pthread instead won't do what you want.
>
> -- 
> Alexandre Julliard
> [e-mail]

wine-pthread hangs -- a work around

[Jeremy Shaw]

Hello,

I have a work-around -- I put loader/kthread.c in its own shared library and things work again:

I changed:

distcc -c -I. -I. -I../include -I../include    -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith  -O2 -g -o kthread.o kthread.c

to:

distcc -shared -I. -I. -I../include -I../include    -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith  -O2 -g -o libkthread.so kthread.c

and:

distcc -o wine-kthread -Wl,--section-start,.interp=0x3c000100 main.o kthread.o -L../libs/wine -lwine -L../libs/port -lwine_port

to:

distcc -o wine-kthread -Wl,--section-start,.interp=0x3c000100 main.o -L. -lkthread -L../libs/wine -lwine -L../libs/port -lwine_port

and now the pthread_create() in kthread.c gets called.

Hopefully someone who understands linker magic better than me can come
up with a better fix...

Jeremy Shaw.

At Sat, 15 Nov 2003 18:44:32 -0800,
Jeremy Shaw wrote:
> Hello,
>
> I did some experiments, and I believe that something did get broken in
> the recent changes -- specifically, libjack is now calling the real
> pthread functions instead of the wine emulated functions.
>
> In cvs head, in loader/kthread.c, in pthread_create() I added a
> P_OUTPUT. I never see 'pthread_create' get printed.
>
> int pthread_create(pthread_t* thread, const pthread_attr_t* attr, void*
>         (*start_routine)(void *), void* arg)
> {
>     assert( funcs.ptr_pthread_create );
>     P_OUTPUT("pthread_create.\n");
>     return funcs.ptr_pthread_create( thread, attr, start_routine, arg );
> }
>
> In wine-20030618, in schedular/pthread.c, in pthread_create() I added
> a similar P_OUTPUT statement, and I did see 'pthread_create get
> printed.' In addition, the pthread_create() function actually
> returned.
>
> I ran nm on wine-kthread, and pthread_create() is defined:
>
> 3c0014b0 T pthread_create
>
> Any idea how I can get things working again? I assume this is some
> sort of linking issue, but I don't know where to go from here...
>
> Jeremy Shaw.
>
> At Sat, 15 Nov 2003 16:44:00 -0800,
> Alexandre Julliard wrote:
> > Jeremy Shaw  writes:
> > > So, if winejack.drv.so requires libjack which is linked against
> > > libpthread -- should it work with wine-kthread? And, if it does work,
> > > will libjack be calling the real pthread functions in libpthread or
> > > the emulated pthread functions in wine?
> >
> > Yes it should work with wine-kthread, and it will call the emulated
> > pthread functions. At least that's the theory, it's quite possible
> > that with all the recent changes something got broken; but in any case
> > using wine-pthread instead won't do what you want.
> >
> > -- 
> > Alexandre Julliard
> > [e-mail]

wine-pthread hangs -- a work around

[Alexandre Julliard]

Jeremy Shaw  writes:
> Hopefully someone who understands linker magic better than me can come
> up with a better fix...

I think adding --export-dynamic to the link should be
enough. Something like this should do the trick:

Index: configure.ac
===================================================================
RCS file: /opt/cvs-commit/wine/configure.ac,v
retrieving revision 1.205
diff -u -p -r1.205 configure.ac
--- configure.ac	14 Nov 2003 21:12:03 -0000	1.205
+++ configure.ac	16 Nov 2003 20:40:57 -0000
@@ -891,6 +891,13 @@ case $host_os in
         then
           AC_SUBST(LDEXECFLAGS,["-Wl,--section-start,.interp=0x3c000100"])
         fi
+        AC_CACHE_CHECK([whether the linker accepts --export-dynamic], ac_cv_c_export_dynamic,
+          [WINE_TRY_CFLAGS([-fPIC -Wl,--export-dynamic],
+                           ac_cv_c_export_dynamic="yes",ac_cv_c_export_dynamic="no")])
+        if test "$ac_cv_c_export_dynamic" = "yes"
+        then
+          LDEXECFLAGS="$LDEXECFLAGS -Wl,--export-dynamic"
+        fi
       else
         AC_CACHE_CHECK(whether we can build a UnixWare (Solaris) dll, ac_cv_c_dll_unixware,
             [WINE_TRY_CFLAGS([-fPIC -Wl,-G,-h,conftest.so.1.0,-B,symbolic],

wine-pthread hangs -- a work around

[Jeremy Shaw]

Thanks, that seemed to fix it.

Jeremy Shaw.

On Nov 16, 2003 12:42 PM, Alexandre Julliard  wrote:
> Jeremy Shaw  writes:
> > Hopefully someone who understands linker magic better than me can come 
> > up with a better fix...
>
> I think adding --export-dynamic to the link should be 
> enough. Something like this should do the trick:
> Index: configure.ac
>
> RCS file: /opt/cvs-commit/wine/configure.ac,v 
> retrieving revision 1.205 
> diff -u -p -r1.205 configure.ac 
> --- configure.ac	14 Nov 2003 21:12:03 -0000	1.205 
> +++ configure.ac	16 Nov 2003 20:40:57 -0000 
> @@ -891,6 +891,13 @@ case $host_os in 
>          then 
>            AC_SUBST(LDEXECFLAGS,["-Wl,--section-start,.interp=0x3c000100"]) 
>          fi
> -
>    AC_CACHE_CHECK([whether the linker accepts --export-dynamic], ac_cv_c_export_dynamic, 
> -
>      [WINE_TRY_CFLAGS([-fPIC -Wl,--export-dynamic], 
> -
>                       ac_cv_c_export_dynamic="yes",ac_cv_c_export_dynamic="no")]) 
> -
>    if test "$ac_cv_c_export_dynamic" = "yes" 
> -
>    then 
> -
>      LDEXECFLAGS="$LDEXECFLAGS -Wl,--export-dynamic" 
> -
>    fi 
>  else 
>    AC_CACHE_CHECK(whether we can build a UnixWare (Solaris) dll, ac_cv_c_dll_unixware, 
>        [WINE_TRY_CFLAGS([-fPIC -Wl,-G,-h,conftest.so.1.0,-B,symbolic], 
>
> --  
> Alexandre Julliard 
> [e-mail]