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
"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. 06151 162516 -------- Fax. 06151 164321 ----------
participants (2)
-
Christian Costa -
Uwe Bonnes