Subject: Re: bug#7190: Crash in menus on w32

From: Eli Zaretskii <[email-masked]>
Date: Tue, 12 Oct 2010 21:05:55 +0200

> From: Lennart Borgman <[email-masked]>
> Date: Tue, 12 Oct 2010 11:37:52 +0200
> Cc: [email-masked]
> 
> > I didn't mean that you need to remember what you did.  I meant to use
> > the debugger _when_ it crashes to find out what was the menu in
> > question.
> 
> Exactly how do I see that?

By looking at the menu data structures accessed by these functions:

  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
  #8  0x011c4e5f in w32_free_submenu_strings (menu=0x205f3) at w32menu.c:1706
  #9  0x011c4e5f in w32_free_submenu_strings (menu=0xdd10145) at w32menu.c:1706
  #10 0x011c4eaa in w32_free_menu_strings (hwnd=0x900ca) at w32menu.c:1723
  #11 0x011c2b6e in menubar_selection_callback (f=0x3f63000, client_data=0x2510)
      at w32menu.c:353

In menubar_selection_callback, you will find that Emacs stores in the
keyboard buffer a couple of events produced by a menu selection.  If
my reading of the code is correct, this code:

	  entry = AREF (vector, i + MENU_ITEMS_ITEM_VALUE);

retrieves the selected menu item, and `vector' is the entire menu bar,
computed as

  vector = f->menu_bar_vector;

See frame.h for the structure of this vector.

By looking at `entry' you can find which menu item is being selected.

Then in w32_free_submenu_strings, you can see the same info in its
bare C form.

> >> Maybe it would be useful to trace the order of events with DebPrint
> >> since they seem to be wrong? Any suggestions on what to trace?
> >
> > I have no idea, because I don't know how to guess that from the
> > backtrace alone.  At least some data regarding the reason(s) of the
> > crash is needed, see above.
> 
> I just meant adding some DebPrint statements and recompile.

I wouldn't know where to add these statements, because we have no idea
what is causing the memory corruption which leads to the crash.