On Fri, Jul 26, 2002 at 01:43:29PM +0200, Uwe Pross wrote:
> On July 26, 2002 at 11:43 +0200, Dominik Vogt wrote:
> >
> > So, please post the responsible config file and describe exactly
> > what you are doing to provoke it. Since exposing a menu is part
> > of one of the core dumps, the problem may even be related *where*
> > you open the menus (they bounce off the right side and may overlap
> > their grandparents). Running Purify does not make much sense
> > without this information. The only info I have is that dynamic
> > menus (MissingSubmenuFunc) and multiple menu styles are involved.
> > It may be necessary that the autogenerated menus destroy
> > themselves after use.
>
> I thought you have reproduced the crash already. I am at the
> university now and I don't have the responsible config here. I will
> post it together with a description tonight or tommorow.
>
> > > 3. mr = 135959280 135978328 135139680
> > ...
> > > 1. mr = 135959280 135960248 209
> > > ^^^
> >
> > Look closely: it's not the mr->s->ms pointer that was trashed.
> > The mr->s pointer changed between the two invocations. This must
> > not happen unless the menu style was changed.
>
> So I do not change menu styles. But the pointer mr->s changes
> frequently and 135960248 seems to be a proper value.
I have to correct myself: It must *never* happen. The 's' bit is
not the menu style but the static part of the menu structure.
This is never changed while the menu exists.
> I will have a double check of this.
>
> > > The last debug statement was printed out shortly before the seg
> > > fault occured. But all pointers seem to be normal :-| Actually no
> > > idea what happend here.
> > > This case happens most times.
> >
> > Could be an attempt to access freed memory.
>
> That would be an explanation. According to my experience one can
> access freed memory without a segfault.
Even moreso because the memory often gets allocated again almost
instantly and is filled with new data.
> An often made programmer
> mistake is to access memory which was alloced locally by a function
> and freed after its return. This happens to work in most cases.
>
> > Yes. Scatter these debug statements all over the
> > MenuInteraction() function. We might be able to hunt down the
> > statement that overwrites the mr->s pointer this way. I'll commit
> > a debug patch for this shortly.
>
> I will do some further checks. Maybe I am lucky ;-)
(with my bugfix, I hope). Before the fix, the crash could be
provoked like this:
1) Open the root menu.
2) Open a directory menu from the root menu.
3) Hierarchically open submenus of the directory menu until one
of these menus overlaps a different directory menu.
4) Move the pointer back to the root menu without passing over
any other menu (this can be tricky).
=> The submenus are closed and destroyed. The partially hidden
menu gets an Expose event - after it was destroyed.
=> Boom!
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
