On Tue, 8 Jun 2004, Robert Shearman wrote:
> Shachar Shemesh wrote:
> > It seems Wine has been > generating lots of zombie processes
> when it's not 100% cleanly killed. I > have also seen the system hold
> a socket created from a wine process in > "ESTABLISHED" state, when no
> process is r
Robert Shearman wrote:
I've experienced the same thing on a perfectly clean kernel (I think
2.6.5-mm1), but I assumed it was because we were messing around with
signals. If I can reproduce the problem I will report it, although Mike
McCormack seems to have had quite a bit of contact already with t
Luca Capello wrote:
>
> Hi Robert,
>
>
> Well, it seems that the problem is somewhere but not due to the .lnk
> path... I'm still here for other testings, as I'd like to solve it. Next
> step will be solving the 'wineshelllink' script (but I can do the
> latter, while for the former I've not enough
Shachar Shemesh wrote:
> Hi all,
>
> Mike M told me on IRC that this matter has come up before, but I have
> not been able to find it in the archives. It seems Wine has been
> generating lots of zombie processes when it's not 100% cleanly killed. I
> have also seen the system hold a socket created
Hi all,
Sometimes it is convenient to do a "killall -9 wine-pthread" to kill Wine
for whatever reason. This no longer works:
$ ps ax | grep wine-pthread | grep -v grep
10425 pts/4S 0:00 /opt/wine/bin/wine-pthread notepad.exe
$ killall wine-pthread
wine-pthread: no process killed
$ kill
Hi all,
Mike M told me on IRC that this matter has come up before, but I have
not been able to find it in the archives. It seems Wine has been
generating lots of zombie processes when it's not 100% cleanly killed. I
have also seen the system hold a socket created from a wine process in
"ESTABLI
Why should expecting a NULL return be wrong? It happens, as the the crashes
show.
no. the cases are different. The ones you refer to (mainly in driver.c)
use a hDrvr passed by the called. So, we have to catch erroneous hDrvr
values.
The case in lolvldrv.c is different. The hDrvr used is the one
Hallo,
I sent a patch to prevent wine from crashing last friday. It happend, when
DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that
patch before last year. Eric answered
> this doesn't seem right to me: either the loading fails and we shouldn't
> get a valid handle, or it
On Sun, 06 Jun 2004 16:15:43 -0400, Robert Reif wrote:
> Interesting read. I would have thought Microsoft would have
> checked if the memory range was already mapped and had the
> proper access permission rather than just accessing it and catching
> the page fault. The whole point of the check is
On Sun, 06 Jun 2004 14:49:05 -0600, Erich Hoover wrote:
> Wine-dbg>bt
> Backtrace:
> =>1 0x558fc8e4 (0x5584fc20)
> 2 0x558fcd6b (0x5584fc44)
> 3 0x558fcd96 (0x5584fc68)
> 4 0x558fccea (0x5584fc8c)
> 5 0x004070d6 (0x5584ff2c)
> 6 0x554af3e7 (0x5584fff4)
> 7 0x5502d525 (0x)
> Wine
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
> /***
> + * SetFilePointerEx (KERNEL32.@)
> + */
> +BOOL WINAPI SetFilePointerEx( HANDLE hFile, LARGE_INTEGER distance,
> + LARGE_INTEGER *new
11 matches
Mail list logo
