problem : win16 stack selector freed twice

[Christian Costa]

Hi everybody,

I encountered the following problem that completely broke MapLS.
I investigated a little and here is what I've found :

1) a selector is allocated for the win16 stack in THREAD_InitStack
2) the selector is freed and the stack replaced by another (the DGROUP 
of the module) in NE_StartTask
3) MapLS is called, allocates the freed selector and keep it in a linked 
list
4) the selector is freed in SYSDEPS_ExitThread which believes it to be 
the selector of the initial task
5) the selector being freed is allocated (from where is not important) 
and the associated descriptor is modified
6) further call to MapLS (wich makes the function to use this selector) 
make wine to crash because the
descriptor has been overwritten

So 2) and 4) are conflicting but I think only 4) is wrong.

4) should free the selector of the new stack instead of the old one.
Or should do nothing if the stack has been changed.

Any idea?

A+
Christian

[Uwe Bonnes]

> > > > > "Christian" == Christian Costa <titan.costa(a)wanadoo.fr> writes:

Christian> Hi everybody, I encountered the following problem that
    Christian> completely broke MapLS.  I investigated a little and here is
    Christian> what I've found :

    Christian> 1) a selector is allocated for the win16 stack in
    Christian> THREAD_InitStack 2) the selector is freed and the stack
    Christian> replaced by another (the DGROUP of the module) in
    Christian> NE_StartTask 3) MapLS is called, allocates the freed selector
    Christian> and keep it in a linked list 4) the selector is freed in
    Christian> SYSDEPS_ExitThread which believes it to be the selector of
    Christian> the initial task 5) the selector being freed is allocated
    Christian> (from where is not important) and the associated descriptor
    Christian> is modified 6) further call to MapLS (wich makes the function
    Christian> to use this selector) make wine to crash because the
    Christian> descriptor has been overwritten

    Christian> So 2) and 4) are conflicting but I think only 4) is wrong.

    Christian> 4) should free the selector of the new stack instead of the
    Christian> old one.  Or should do nothing if the stack has been changed.

    Christian> Any idea?

What about locking the alloceted handle? Refertencecounting should inhibit
it from getting freed to early.

Bye

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------