kernel/comm.c - page fault in thread
Mr Cihan ALTINAY
cihan at uq.edu.au
Mon Nov 7 18:45:26 CST 2005
Hi again,
Sorry for the double post and the stupid default From-Header
(not my machine).
I replaced my modified comm.c with the latest CVS, made the changes
as described below and still got communication errors (the device
replies that commands are malformed). So I attempted to apply the
changes I made one-by-one to see when the errors disappear. And the
first (and easiest) change helped:
When replacing both
tcflush(fd,TCOFLUSH)
by
tcdrain(fd)
in the PurgeComm function all errors disappear and the program works
as expected.
Now, I know that the two functions do different things and according
to the API specification of PurgeComm tcflush seems more appropriate.
So I wonder if this is not really a fix but only a workaround for a
different problem (maybe a race condition as mentioned earlier?).
I know that G-Ware does some funny (stupid?) things and there are
always at least 2 threads running that poll for input/output. One
effect is that it still opens ~200 file handles to the port but,
more importantly, maybe they interact in a way it shouldn't happen?
Anyone?
----- Original Message -----
From: Mr Cihan ALTINAY <cihan at uq.edu.au>
Date: Tuesday, November 8, 2005 10:13 am
Subject: kernel/comm.c - page fault in thread
> Hi,
>
> I finally got G-Ware to work flawlessly under wine after some
> tweaks in the comm.c file. One problem was in the (thread) function
> COMM_WaitCommEventService().
> When I 'disconnect' in the client program it calls purge and sets
> the event mask to 0 (ie. it is no longer interested in events from
> the port). But there are still threads running that poll the port.
>
> The program crashes when the thread exits the loop (with abort!=0)
> and tries to set
> *commio->buffer = rc;
> (line 2010) but this buffer is already freed by the client.
> Replacing
>
> if (abort) rc = 0;
> *commio->buffer = rc;
>
> by
>
> if (!abort)
> *commio->buffer = rc;
>
> fixes this problem.
>
> There were other communication errors which I managed to fix but
> I have to find out first which changes are really necessary to
> make things work because I tried a lot of things in comm.c.
> It looks as if there are race conditions when more than one
> polling thread is running. Currently I check if a thread is already
> running and don't start a second one if so. But I will find out if
> that is responsible for the errors or something else and report it
> on the list.
>
> Cheers,
> Cihan
>
>
>
>
More information about the wine-devel
mailing list