Re: [MiNT] tfork() bug.

[Alan Hourihane <alanh@fairlite.co.uk>]

On 05/16/12 13:30, Ole wrote:
> Am Mittwoch, den 16.05.2012, 13:29 +0200 schrieb Alan Hourihane
> <alanh@fairlite.co.uk>:
>
>> It sounds like a bug, but the kernel is guarding against any problems
>> with Mfree() in tfork().
>
> No - there is an BIG problem. It's an race condition.

You're using threads, so things are racy, until you start using locks.

> The Mfree() was meant to free the p_env of the new thread, not of the
> main thread.
>
> If anything access the environment in the main thread - it will access an
> pointer which is already freed.
>

Can you demonstrate in your test, as I don't see any crashes.

> If there is no race condition ( for example because you lock the
> thread until
> tfork() finished - I already tried that) - then the tfork function
> will double
> free the environment pointer of the thread.
> (which is another bug - but it doesn't trigger, because of the race
> condition)
>
> The kernel probably just returns failure
> because the memory block isn't allocated. If there is an
> malloc(sizeof(environment)) before the free()
> (maybe from within another thread), then I'm pretty sure it will not
> return an error
> (because there is an allocated block with that address). It will free
> an memory pointer which is allocated
> by something totally different. And so on...

Demonstrate a crash in your program and I can take a look. I've limited
time at the moment, so can't dig in entirely. So if you have the time to
demonstrate the crash and potential propose a fix, that'd be great.

Thanks,

Alan.