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 ;-) > 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); > ---------------------------------------------------------------------- > > 2. location and output > > menus.c:4141 > if ((MST_FACE(mr).type != SolidMenu && > ---------------------------------------------------------------------- > > 3. location and output > > menuitem.c:320 > y_offset = MI_Y_OFFSET(mi); > ----------------------------------------------------------------------
They have all one thing in common: they are triggered asynchronously by an expose event. Somehow I managed to delete the menu structure while the X server still stored the connection between the structure and the window. When an expose event arrived, fvwm queried the X server for an associated menu structure and got the address of the deleted one. This was caused by some funny interaction between the Display used to create the menu and the one that created the context. I'm puzzled how this could happen: XDestroyWindow(menu_display, menu_window, ...); XFlush(menu_display); XDeleteContext(normal_display, menu_context, ...); ... (Expose event arrives) XFindContext(normal_diplay, event_window, ...); So, the XFindContext after the XDeleteContext returned the already deleted context. It seems that those two calls are not strictly serialized on the server. I have committed a fix along with a lot of temporary debug code that creates a core dump when an inconsistent menu structure is detected. 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]
