bug#7190: Crash in menus on w32

[Lennart Borgman]

On Wed, Oct 13, 2010 at 5:51 PM, grischka <grishka@gmx.de> wrote:
> Lennart Borgman wrote:
>>>>
>>>> Is not that an important difference?
>>>
>>> Not if you want to fix the bug.
>>
>> It looks like I am thinking nearly exactly the opposite.
>>
>> For a simple bug it does not matter. For a complicated bug you can not
>> look at all possible places. That would take too long time. So putting
>> some structure on the different places and evaluating them makes much
>> sense to me.
>
> This bug is simple.

Didn't someone say life is easier for pessimists... ;-)

>>>>>> By
>>>>>> adding DebPrint call we could perhaps see if some code where called in
>>>>>> an order we did not expect.
>>>>>
>>>>> Perhaps see the information that you already have?  For example
>>>>>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at
>>>>> w32menu.c:1701
>>>>> is telling where is "some code", and
>>>>>  "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
>>>>> is telling about "order we did not expect", as likely in:  Called
>>>>> twice for the same memory object.  If in doubt, try to prove that
>>>>> it can't happen.
>>>>
>>>> Yes, perhaps. But it could also be that memory objects are freed in an
>>>> order we did not expect.
>>>>
>>> Why should it matter in what order "Invalid Address" is passed to free?
>>
>> Maybe I am misunderstanding, I do not know much about this part of the
>> code. Are you saying that you could not get this error from calls to
>> RtlFreeHeap coming in the wrong order? (That would perhaps help much
>> to know.)
>
> Yes,  RtlFreeHeap (like any free) doesn't care about order.  It only
> cares that it's a valid object (which it isn't if it was already freed).
> Did not someone see corrupted first letters in menu strings and such?
> That is also a symptom of premature free, often.  Count 1+1 ...

Thanks, that helps. It makes it easier for me to put in some trace
messages in useful places.