Alexandre Julliard wrote:
Eric Pouech <[EMAIL PROTECTED]> writes:
reading from wine/list.h
#define LIST_FOR_EACH_SAFE(cursor, cursor2, list) \
for ((cursor) = (list)->next, (cursor2) = (cursor)->next; \
(cursor) != (list); \
(cursor) = (cursor2), (cursor2) = (cursor)->next)
Eric Pouech <[EMAIL PROTECTED]> writes:
> reading from wine/list.h
> #define LIST_FOR_EACH_SAFE(cursor, cursor2, list) \
>for ((cursor) = (list)->next, (cursor2) = (cursor)->next; \
> (cursor) != (list); \
> (cursor) = (cursor2), (cursor2) = (cursor)->next)
>
> well, to me, the
- the generic issue in the SAFE version, where we still access the
cursor after it has been potentially fixed
No, in the SAFE macros we don't, that's the whole point of having
them.
reading from wine/list.h
#define LIST_FOR_EACH_SAFE(cursor, cursor2, list) \
for ((cursor) = (list)
Eric Pouech <[EMAIL PROTECTED]> writes:
> I've seen it too, but it was only for current cursor not next, which
> still means we have :
> - the issue in process termination, where an iteration in the loop can
> kill more than one item in the list
This is fixed now.
> - the generic issue in the
Mike McCormack wrote:
Eric Pouech wrote:
well, the kill_thread in that case in only done when the waiting
thread also died while waiting (ie has been killed by some other way)
(in normal cases, the wait operation on the waiting side would just
return an error code)
the I'm not still convic
Eric Pouech wrote:
well, the kill_thread in that case in only done when the waiting thread
also died while waiting (ie has been killed by some other way) (in
normal cases, the wait operation on the waiting side would just return
an error code)
the I'm not still conviced this path is actually
2006/11/10, Mike McCormack <[EMAIL PROTECTED]>:
Eric Pouech wrote:> IIRC, the issue in this code is that you access in _SAFE macro the next
> field in the current cursor *after* the current cursor has been freed> the issue is not that the next item has been freed while itering on the> current curs
Eric Pouech wrote:
IIRC, the issue in this code is that you access in _SAFE macro the next
field in the current cursor *after* the current cursor has been freed
the issue is not that the next item has been freed while itering on the
current cursor
(this was at least the issue I had)
It looks
IIRC, the issue in this code is that you access in _SAFE macro the next field in the current cursor *after* the current cursor has been freed
the issue is not that the next item has been freed while itering on the current cursor
(this was at least the issue I had)
so the first is to set the next cu
Eric Pouech wrote:
IMO this should be fixed by rewriting correctly the _SAFE version of the
list macros, which are to blame here.
I have this somewhere, I'll send it later on.
The only way to prevent the next pointer (or any other pointer in the
thread list) from being free'd is to grab it.
IMO this should be fixed by rewriting correctly the _SAFE version of the list macros, which are to blame here.
I have this somewhere, I'll send it later on.
2006/11/10, Mike McCormack <[EMAIL PROTECTED]>:
---server/process.c | 28 1 files changed, 24 insertions(+), 4 d
11 matches
Mail list logo
