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 cursor before entering the for loop and not after the execution of the for loop A+
2006/11/10, Mike McCormack mike@codeweavers.com:
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. Since the LIST macros doesn't understand pointer grabbing, I don't see a way to fix it by changing the macro...
Mike