April 2002 - Wine-Devel - list.winehq.org

Re: Debugger looping busy

by Sylvain Petreolle

> some questions: > - do you use the wineconsole or directly from the > Unix console I run it directly from the Unix console. > - was winedbg started from an exception or from the > command line from an exception > - did you try to redirect input and/or output to > some files no, was the direct output on the Unix console. Redirect as >stdout_log 2>stderr_log gives the same messages in the file stderr_log. > > (sounds like an error in reading the input stream, > which doesn't > seem to be correctly set up) > > A+ > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 16, 2002

Re: Debugger looping busy

by Eric Pouech

Sylvain Petreolle a écrit : > > Hi, > > Using some programs with wine (last CVS), > the debugger enters a loop and cannot be > stopped other way than a kill on it. > > If I let it go, i see pages of these : > Wine-dbg>parse error some questions: - do you use the wineconsole or directly from the Unix console - was winedbg started from an exception or from the command line - did you try to redirect input and/or output to some files (sounds like an error in reading the input stream, which doesn't seem to be correctly set up) A+

April 16, 2002

Debugger looping busy

by Sylvain Petreolle

Hi, Using some programs with wine (last CVS), the debugger enters a loop and cannot be stopped other way than a kill on it. If I let it go, i see pages of these : Wine-dbg>parse error Cannot pass on last chance exception. You must use cont Wine-dbg>parse error Cannot pass on last chance exception. You must use cont Wine-dbg>parse error Cannot pass on last chance exception. You must use cont Had someone the same behaviour ? RH 7.2, kernel 2.4.9-31, glibc-2.2.4-24 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 16, 2002

Re: Sorry for spamming wine bugs list

by Jeremy Newman

Hmmm, that is an issue isn't it. Can you enter that as a bug for Bugzilla itself. There should be a category for it. I'll see if I can update Bugzilla so it does not spam the list like that. Thanks for pointing it out. On Tue, 2002-04-16 at 13:56, Andriy Palamarchuk wrote: > I just changed a dependency of some task list bug and > a message was sent to the wine bugs list for each > entry in the task list. > Probably we need better filter for notifications which > sent to the bugs list. > > Andriy Palamarchuk -- __ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

April 16, 2002

Re: fixme:win32:PeekNamedPipe

by Mike McCormack

Hi Michael's, Implementing PeekNamedPipe will probably be difficult to do properly. Named pipes work through unix domain sockets at the moment. The code is in dlls/ntdll/sync.c and server/named_pipe.c. (I was the one who wrote most of it.) Unfortunately I don't have time to work on this at the moment, but i can give you a few hints on how to procede. You might be able to use recvfrom with the MSG_PEEK flag to do it... Tell me how it goes... Mike Michael Cardenas wrote: > Michael Riedel wrote: > >> Thanks for the hint, and yes it is a kernel32 function. > > > ok, then there's some work to do. > >> fixme:win32:PeekNamedPipe (00000080, (nil), 00000000, (nil), >> 0x406a2194, (nil)): stub >> >> this means that at least a valid handle was created so that there is >> already some code for CreateNamedPipe or CreatePipe? > > > This means there's a stub. So, there's a placeholder with no code in it. > >> Is there anybody knowing more before I am going to try looking into >> the sources? > > > I'm not more knowing about this function per se, I'm sure whoever else > wrote the rest of the named pipe implementation will know. But I do know > that you can do this to find the stub, and possibly the file that has > the other named pipe functions: > > find (winesrcdir) -name *.c | xargs grep PeekNamedPipe >

April 16, 2002

Followup: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

I just might remark that with the two changes I discussed in the previous message (do not call set_select_events (..., -1), signal FD_CLOSE only once) I seem to finally get rid of the problems with the close()/shutdown() semantics that I talked about before. But only at the cost of very high wineserver CPU usage. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 16, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

On Tue, 16 Apr 2002, Michael Cardenas wrote: > Could you use the set_select_events to say that you don't want any more > POLLHUP events? No you can't - that's how poll() works (at least on Linux). <man poll> int poll(struct pollfd *ufds, unsigned int nfds, int timeout); [...] The field revents is an output parameter, filled by the kernel with the events that actually occurred, either of the type requested, or of one of the types POLLERR or POLLHUP or POLLNVAL. (These three bits are meaningless in the events field, and will be set in the revents field whenever the corresponding condition is true.) </man poll> Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 16, 2002

Sorry for spamming wine bugs list

by Andriy Palamarchuk

I just changed a dependency of some task list bug and a message was sent to the wine bugs list for each entry in the task list. Probably we need better filter for notifications which sent to the bugs list. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 16, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Michael Cardenas

Martin Wilck wrote: >My first reaction to this was to comment out the above call to >set_select_events() and continue listening to events from the socket. >However, due to the semantics of poll(), this will cause a POLLHUP event >on this socket for each and every iteration of the wineserver's main select >loop, putting the server basically into a busy-wait state. > Could you use the set_select_events to say that you don't want any more POLLHUP events? -- michael cardenas lead windows compatibility engineer www.lindows.com "Be the change you want to see in the world." -Mahatma Gandhi

April 16, 2002

Urgent need for advice: POLLHUP and sockets

by Martin Wilck

Hi all, please consider the following problem: On sockets, when POLLHUP is received, it is perfectly legitimate to continue reading data until a read() or recv() call returns 0 bytes. The current wine implementation calls set_select_events( &sock->obj, -1 ) when POLLHUP or POLLERR is received, disabling any future events from the socket. However, if an application uses asynchronous IO (or only asynchronous notification via WSAAsyncSelect() or WSAEventSelect()), this also inhibits reception of POLLIN events which can perfectly well occur if there are still unread data in the kernel buffers. Thus the app will never notice that there is still data to be read. My first reaction to this was to comment out the above call to set_select_events() and continue listening to events from the socket. However, due to the semantics of poll(), this will cause a POLLHUP event on this socket for each and every iteration of the wineserver's main select loop, putting the server basically into a busy-wait state. How can this be resolved? We seem to have the choice between a) busy loop in the server (bad) b) discarding data which could be legitimately read by the application (very bad). Any hints/comments/ideas? Please note that it is insufficient to queue all pending APCs on the socket when POLLHUP is received, because the app may very well queue some _after_ the close event arrives. A minor point is that sock_poll_event() also sets a FD_CLOSE event (if present) everytime it is called with POLLHUP set, effectively preventing any APC from being called, at least if the app waits for FD_CLOSE and asynchronous send/recv operations at the same time (likely). This can be worked around by setting FD_CLOSE only once and then blocking it, although I am not sure if that is correct behaviour (permanently signalling FD_CLOSE is obviously incorrect). I hope someone has a good idea how to resolve this, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 16, 2002