On Thu, Jul 25, 2002 at 09:42:12PM +0200, Uwe Pross wrote: > On Thu, Jul 25, 2002 at 12:00:48PM +0200, Dominik Vogt wrote: > > > > If you look closely you can see that mr->ms->s is involved in all > > cases (the static part of the menu style). Mikhael posted a > > similar core dumps a few weeks ago. In his and one of the similar > > crashes I got, the contents of mr->ms had been overwritten with > > random data, so mr->ms->s pointed to a random location. > > Sounds to me like a needle in a haystack ;-) > > I played a little bit around and found the three locations > below where a seg fault occured. Meanwhile I am well trained in > provoking one of the seg faults ;-)
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 am not that sure anymore that they have a common source. I inserted > some debug statements in menus.c in function paint_menu to see the > locations of the pointer which may cause the violation. The pointers > are printed out three times to see if they were changed inside the > function. > > To understand the following lines here is the printf-command: > fprintf(stderr,"1. mr = %d %d %d\n",(mr),(mr->s),(mr->s->ms)); > ---------------------------------------------------------------------- > > 1. location and output > > menus.c:4064 > int bw = MST_BORDER_WIDTH(mr); > > 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. contains trash > This case is clear. The pointer mr->s->ms points to nirvana. This is > the case you described, Dominik. > ---------------------------------------------------------------------- > > 2. location and output > > menus.c:4141 > if ((MST_FACE(mr).type != SolidMenu && > 3. mr = 135843984 135749536 135139680 ... > 3. mr = 135836320 135836336 135139680 > > 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. > ---------------------------------------------------------------------- > > 3. location and output > > menuitem.c:320 > y_offset = MI_Y_OFFSET(mi); > > This statement is called from the position where the previous seg > fault occured. So it may go away if the reason for the previous seg > fault is found. So, more evidence for some code overwriting random data? > Any further ideas? 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. 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]
