September 2001 - Wine-Devel

Re: fixme:pthread_kill_other_threads

by Dan Kegel

Uwe Bonnes wrote: > I don't understand why pthread_kill_other_threads ist called when a programm > creates a new process. With the pthread_kill_other_threads call, the starting > process dies. ... > What can happen between chdir() and execve() to trigger the > pthread_kill_other_threads() call? This is per the Posix standard; http://www.opengroup.org/onlinepubs/007908799/xsh/exec.html says: "A call to any exec function from a process with more than one thread results in all threads being terminated and the new executable image being loaded and executed." Maybe this is hurting you because LinuxThreads implements fork() in a nonstandard way, i.e. maybe it only forks the current thread rather than the whole process? In any case, what you're trying to do is so common and important that maybe it's a glibc bug. Which glibc and kernel are you using? - Dan

Sept. 27, 2001

Re: fixme:pthread_kill_other_threads

by Ove Kaaven

On Thu, 27 Sep 2001, Uwe Bonnes wrote: > What can happen between chdir() and execve() to trigger the > pthread_kill_other_threads() call? Well, not much... glibc's execve() implementation calls pthread_kill_other_threads_np() itself to prepare the threading system for an exec. This is a feature, not a bug.

Sept. 27, 2001

fixme:pthread_kill_other_threads

by Uwe Bonnes

Hallo, I don't understand why pthread_kill_other_threads ist called when a programm creates a new process. With the pthread_kill_other_threads call, the starting process dies. This is a +relay,+server,+... log: trace:dosfs:DOSFS_GetFullName returning /home/dosd/cae/ql82/scs/TKWDOG.EXE = D:\CAE\QL82\SCS\TKWDOG.EXE 08068938: new_process( inherit_all=0, create_flags=67108864, start_flags=257, exe_file=200, hstdin=4, hstdout=8, hstderr=12, cmd_show=1, filename="D:\cae\ql82\scs\TKWDOG.EXE" ) 08068938: new_process() = 0 { info=204 } fixme:pthread_kill_other_threads_np 08068938: select( flags=12, cookie=0x405c5778, sec=1001624181, usec=913175, handles={204} ) 08068938: select() = PENDING 00000000: *fd* 0 -> 46 08625a70: *fd* 6 <- 46 08625a70: *fd* 8 <- 47 08625a70: init_thread( unix_pid=2070, teb=0x40127ce0, entry=(nil), reply_fd=6, wait_fd=8 ) 08625a70: init_thread() = 0 { pid=0x86259a0, tid=0x8625a70, boot=0, version=53 } This is an strace of that part: 1898 close(28) = 0 1898 chdir("/home/dosd/cae/ql82/scs") = 0 1898 write(2, "fixme:pthread_kill_other_threads"..., 36) = 36 1898 execve("/usr/local/bin/wine", ["/usr/local/bin/wine", "--", "tkwdog.exe"], [/* 57 vars */] <unfinished ...> and I think this relates to scheduler/process.c:fork_and_exec if (newdir) chdir(newdir); if (argv && envp) { if (!filename) { argv[1] = "--"; exec_wine_binary( argv, envp ); } else execve( filename, argv, envp ); } What can happen between chdir() and execve() to trigger the pthread_kill_other_threads() call? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

Sept. 27, 2001

Problem in installation of Wine on SPARC Solaris 8.0

by Mrugan Bhorkar

I am trying to install Wine on UltraSPARC Solaris 8.0 using tools/wineinstall. The installation script fails at following point...... gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -D__WINE__ -D_REENTRANT -I/usr/openwin/include -o lex.ppl.o lex.ppl.c In file included from ./ppl.l:141: ../../include/config.h:486: warning: `_FILE_OFFSET_BITS' redefined /usr/include/sys/feature_tests.h:96: warning: this is the location of the previous definition ./ppl.l: In function `pplex': ./ppl.l:336: `pplval' undeclared (first use in this function) ./ppl.l:336: (Each undeclared identifier is reported only once ./ppl.l:336: for each function it appears in.) make: *** [lex.ppl.o] Error 1 Can anybody suggest how to fix this?? Thanks Mrugan __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com

Sept. 27, 2001

Re: pthread_atfork and PTHREAD_FORK

by Ove Kaaven

On Wed, 26 Sep 2001, Bill Medland wrote: > Is it legal for pthread_atfork to be called with null parameters (in which > case I will correct PTHREAD_FORK, otherwise I'll assert the pointers). NAME pthread_atfork - register handlers to be called at fork(2) time SYNOPSIS #include <pthread.h> int pthread_atfork(void (*prepare)(void), void (*par ent)(void), void (*child)(void)); DESCRIPTION pthread_atfork registers handler functions to be called just before and just after a new process is created with fork(2). The prepare handler will be called from the par ent process, just before the new process is created. The parent handler will be called from the parent process, just before fork(2) returns. The child handler will be called from the child process, just before fork(2) returns. => One or several of the three handlers prepare, parent and => child can be given as NULL, meaning that no handler needs => to be called at the corresponding point. pthread_atfork can be called several times to install sev eral sets of handlers. At fork(2) time, the prepare han dlers are called in LIFO order (last added with pthread_atfork, first called before fork), while the par ent and child handlers are called in FIFO order (first added, first called). To understand the purpose of pthread_atfork, recall that fork(2) duplicates the whole memory space, including mutexes in their current locking state, but only the call ing thread: other threads are not running in the child process. Thus, if a mutex is locked by a thread other than the thread calling fork, that mutex will remain locked forever in the child process, possibly blocking the execu tion of the child process. To avoid this, install handlers with pthread_atfork as follows: the prepare handler locks the global mutexes (in locking order), and the parent and child handlers unlock them (in reverse order). Alterna tively, prepare and parent can be set to NULL and child to a function that calls pthread_mutex_init on the global mutexes. RETURN VALUE pthread_atfork returns 0 on success and a non-zero error code on error. ERRORS ENOMEM insufficient memory available to register the han dlers. AUTHOR Xavier Leroy <Xavier.Leroy(a)inria.fr> SEE ALSO fork(2), pthread_mutex_lock(3), pthread_mutex_unlock(3). LinuxThreads PTHREAD_ATFORK(3)

Sept. 26, 2001

pthread_atfork and PTHREAD_FORK

by Bill Medland

Can someone tell me what we should have here? (It might be interesting to know how it's supposed to work too but that's beside the point). I had a case where pthread_atfork was being called with two null pointers, so it all blew up when PTHREAD_FORK tried to execute the code they pointed to. Is it legal for pthread_atfork to be called with null parameters (in which case I will correct PTHREAD_FORK, otherwise I'll assert the pointers). Bill

Sept. 26, 2001

pthread_atfork problems

by Bill Medland

Any chance of a hand with this please? I have just traced a problem to the fact that __pthread_atfork is passed a couple of null pointers, which I presume is an illegal thing to do. Can anyone point me at the code that results in __pthread_atfork being called and/or explain why it would be called with null pointers? TIA Bill

Sept. 26, 2001

Re: GetMessageTime

by Alexandre Julliard

"David Hammerton" <david(a)transgaming.com> writes: > BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, > GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the > game Alice seems to make it return 0) - so the value sent to XSetInputFocus for > the time is too small, and hence X refuses to give the window focus. The real fix is that XSetInputFocus should not use GetMessageTime at all, this is only a temporary hack. To conform to the ICCCM the focus time should be based on the timestamp of a previous X event, and the focus should never be changed if we didn't receive an event. To do this right probably requires supporting the take focus protocol, as was discussed some time ago. -- Alexandre Julliard julliard(a)winehq.com

Sept. 26, 2001

Re: Getting Routing tables

by Michael Stefaniuc

On Wed, Sep 26, 2001 at 07:17:36AM +1000, Robert Lunnon wrote: > In my pitiful attempt to hack on WINE I have come to an impasse. I have > managed to find portable equivalents to get the interface name and the number > of interfaces in winsock/wsock32 but I can't seem to find a portable way to > get to the routing table. In Solaris (why I'm doing the hacking) there is a > vague mention in the man pages of being able to get this info by reading > /dev/ip but no information about how to actually do it. > > Can anyone provide a hint on how this can be done portably or to a multi-os > implementation of netstat that might serve as an example. (Only netstat > sources I have found are OS specific) You can't realy do that in a portable way. That's why I choosed to parse /proc/net/route (and because most of the winsock stuff was also only Linux specific). > Hurry because in desperation I am actually thinking of piping the output of > netstat -r That seems to be the most resonable way to go. If you want to also parse the header of the netstat output you should set LANG=C before. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Sept. 26, 2001

Getting Routing tables

by Robert Lunnon

In my pitiful attempt to hack on WINE I have come to an impasse. I have managed to find portable equivalents to get the interface name and the number of interfaces in winsock/wsock32 but I can't seem to find a portable way to get to the routing table. In Solaris (why I'm doing the hacking) there is a vague mention in the man pages of being able to get this info by reading /dev/ip but no information about how to actually do it. Can anyone provide a hint on how this can be done portably or to a multi-os implementation of netstat that might serve as an example. (Only netstat sources I have found are OS specific) Hurry because in desperation I am actually thinking of piping the output of netstat -r Thanks Bob

Sept. 25, 2001