* bug#7190: Crash in menus on w32 @ 2010-10-11 15:13 Lennart Borgman 2010-10-11 19:20 ` Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 41+ messages in thread From: Lennart Borgman @ 2010-10-11 15:13 UTC (permalink / raw) To: 7190 Crash in menus on w32, my patched version of course. Any suggestions? warning: HEAP[emacs.exe]: warning: Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 ) Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll (gdb) bt #0 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll #1 0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll #2 0x7c96e576 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll #3 0x7c96f75e in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll #4 0x7c94bc4c in ntdll!LdrFindEntryForAddress () from C:\WINDOWS\system32\ntdll.dll #5 0x00850000 in ?? () #6 0x7c927573 in ntdll!RtlPcToFileHeader () from C:\WINDOWS\system32\ntdll.dll #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 #12 0x011dc6fc in w32_read_socket (terminal=0x3053c00, expected=0, hold_quit=0x82f6e0) at w32term.c:4624 #13 0x0100e484 in read_avail_input (expected=0) at keyboard.c:6986 #14 0x0100e38e in gobble_input (expected=0) at keyboard.c:6907 #15 0x0100e341 in get_input_pending (addr=0x13fab50, flags=1) at keyboard.c:6870 #16 0x0101489c in detect_input_pending_run_timers (do_display=0) at keyboard.c:10511 #17 0x01007d44 in read_char (commandflag=1, nmaps=22, maps=0x82f990, prev_event=45467674, used_mouse_menu=0x82fb6c, end_time=0x0) at keyboard.c:2556 #18 0x01011c8e in read_key_sequence (keybuf=0x82fc60, bufsize=30, prompt=45467674, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9349 #19 0x010064a7 in command_loop_1 () at keyboard.c:1618 #20 0x01020721 in internal_condition_case (bfun=0x1006185 <command_loop_1>, handlers=45521258, hfun=0x1005b7a <cmd_error>) at eval.c:1460 #21 0x01005eea in command_loop_2 (ignore=45467674) at keyboard.c:1338 #22 0x01020212 in internal_catch (tag=45519378, func=0x1005ec7 <command_loop_2>, arg=45467674) at eval.c:1204 #23 0x01005ea2 in command_loop () at keyboard.c:1317 #24 0x01005796 in recursive_edit_1 () at keyboard.c:940 #25 0x010058fa in Frecursive_edit () at keyboard.c:1002 #26 0x0100264c in main (argc=1, argv=0xa928e8) at emacs.c:1704 (gdb) ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-11 15:13 bug#7190: Crash in menus on w32 Lennart Borgman @ 2010-10-11 19:20 ` Eli Zaretskii 2010-10-11 21:21 ` Lennart Borgman 2010-10-13 11:02 ` grischka ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2010-10-11 19:20 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Mon, 11 Oct 2010 17:13:55 +0200 > Cc: > > Crash in menus on w32, my patched version of course. Any suggestions? > > > warning: HEAP[emacs.exe]: > warning: Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 ) > > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll > (gdb) bt > #0 0x7c90120f in ntdll!DbgUiConnectToDbg () > from C:\WINDOWS\system32\ntdll.dll > #1 0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey () > from C:\WINDOWS\system32\ntdll.dll > #2 0x7c96e576 in ntdll!RtlpNtMakeTemporaryKey () > from C:\WINDOWS\system32\ntdll.dll > #3 0x7c96f75e in ntdll!RtlpNtMakeTemporaryKey () > from C:\WINDOWS\system32\ntdll.dll > #4 0x7c94bc4c in ntdll!LdrFindEntryForAddress () > from C:\WINDOWS\system32\ntdll.dll > #5 0x00850000 in ?? () > #6 0x7c927573 in ntdll!RtlPcToFileHeader () > from C:\WINDOWS\system32\ntdll.dll > #7 0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701 Looks identical to bug #7170. Why did you open a new one? And I don't understand what suggestion do you expect. This happened only for you so far, so you need to debug it on your machine. One thing to do would be to see, each time this happen, which menu, submenu, menu item(s) are involved. If they are the same every time, you will have to take a closer look at the code which creates them. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-11 19:20 ` Eli Zaretskii @ 2010-10-11 21:21 ` Lennart Borgman 2010-10-12 4:04 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-11 21:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Mon, Oct 11, 2010 at 9:20 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Lennart Borgman <lennart.borgman@gmail.com> >> Date: Mon, 11 Oct 2010 17:13:55 +0200 >> Cc: >> >> Crash in menus on w32, my patched version of course. Any suggestions? >> >> >> warning: HEAP[emacs.exe]: >> warning: Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 ) >> >> >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll >> (gdb) bt >> #0 0x7c90120f in ntdll!DbgUiConnectToDbg () >> from C:\WINDOWS\system32\ntdll.dll >> #1 0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey () >> from C:\WINDOWS\system32\ntdll.dll >> #2 0x7c96e576 in ntdll!RtlpNtMakeTemporaryKey () >> from C:\WINDOWS\system32\ntdll.dll >> #3 0x7c96f75e in ntdll!RtlpNtMakeTemporaryKey () >> from C:\WINDOWS\system32\ntdll.dll >> #4 0x7c94bc4c in ntdll!LdrFindEntryForAddress () >> from C:\WINDOWS\system32\ntdll.dll >> #5 0x00850000 in ?? () >> #6 0x7c927573 in ntdll!RtlPcToFileHeader () >> from C:\WINDOWS\system32\ntdll.dll >> #7 0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701 > > Looks identical to bug #7170. Why did you open a new one? Yes, it was a bit stupid to open a new one. > And I don't understand what suggestion do you expect. This happened > only for you so far, so you need to debug it on your machine. > > One thing to do would be to see, each time this happen, which menu, > submenu, menu item(s) are involved. If they are the same every time, > you will have to take a closer look at the code which creates them. I will try to remember what I did next time. I was in a hurry when this happened so I am not quite sure. 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-11 21:21 ` Lennart Borgman @ 2010-10-12 4:04 ` Eli Zaretskii 2010-10-12 9:37 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2010-10-12 4:04 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Mon, 11 Oct 2010 23:21:27 +0200 > Cc: 7190@debbugs.gnu.org > > > One thing to do would be to see, each time this happen, which menu, > > submenu, menu item(s) are involved. If they are the same every time, > > you will have to take a closer look at the code which creates them. > > I will try to remember what I did next time. I was in a hurry when > this happened so I am not quite sure. 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. > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 4:04 ` Eli Zaretskii @ 2010-10-12 9:37 ` Lennart Borgman 2010-10-12 19:05 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-12 9:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Tue, Oct 12, 2010 at 6:04 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Lennart Borgman <lennart.borgman@gmail.com> >> Date: Mon, 11 Oct 2010 23:21:27 +0200 >> Cc: 7190@debbugs.gnu.org >> >> > One thing to do would be to see, each time this happen, which menu, >> > submenu, menu item(s) are involved. If they are the same every time, >> > you will have to take a closer look at the code which creates them. >> >> I will try to remember what I did next time. I was in a hurry when >> this happened so I am not quite sure. > > 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? >> 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 9:37 ` Lennart Borgman @ 2010-10-12 19:05 ` Eli Zaretskii 2010-10-12 19:13 ` Lennart Borgman 2010-10-19 0:20 ` Lennart Borgman 0 siblings, 2 replies; 41+ messages in thread From: Eli Zaretskii @ 2010-10-12 19:05 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Tue, 12 Oct 2010 11:37:52 +0200 > Cc: 7190@debbugs.gnu.org > > > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 19:05 ` Eli Zaretskii @ 2010-10-12 19:13 ` Lennart Borgman 2010-10-12 19:40 ` Eli Zaretskii 2010-10-19 0:20 ` Lennart Borgman 1 sibling, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-12 19:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Tue, Oct 12, 2010 at 9:05 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > Then in w32_free_submenu_strings, you can see the same info in its > bare C form. Thanks. I will use all this info you gave in the next crash. >> 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. I would assume that is all happens within the menus. Is the menu code synched with the other code? Is it perhaps running in a separate thread and not in Emacs normal GUI thread? ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 19:13 ` Lennart Borgman @ 2010-10-12 19:40 ` Eli Zaretskii 2010-10-12 20:09 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2010-10-12 19:40 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Tue, 12 Oct 2010 21:13:08 +0200 > Cc: 7190@debbugs.gnu.org > > >> 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. > > I would assume that is all happens within the menus. No, it happens within Emacs. We allocate the memory that we free when Emacs crashes. > Is the menu code synched with the other code? Is it perhaps running > in a separate thread and not in Emacs normal GUI thread? You can see in the backtrace that the code which crashes is called from command_loop -> read_key_sequence -> read_socket chain, which is part of the normal Emacs input processing of the main thread. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 19:40 ` Eli Zaretskii @ 2010-10-12 20:09 ` Lennart Borgman 2010-10-12 20:14 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-12 20:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Tue, Oct 12, 2010 at 9:40 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Lennart Borgman <lennart.borgman@gmail.com> >> Date: Tue, 12 Oct 2010 21:13:08 +0200 >> Cc: 7190@debbugs.gnu.org >> >> >> 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. >> >> I would assume that is all happens within the menus. > > No, it happens within Emacs. We allocate the memory that we free when > Emacs crashes. I mean that the failing code is among the code handling menus in Emacs. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 20:09 ` Lennart Borgman @ 2010-10-12 20:14 ` Eli Zaretskii 2010-10-12 20:49 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2010-10-12 20:14 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Tue, 12 Oct 2010 22:09:24 +0200 > Cc: 7190@debbugs.gnu.org > > >> >> 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. > >> > >> I would assume that is all happens within the menus. > > > > No, it happens within Emacs. We allocate the memory that we free when > > Emacs crashes. > > I mean that the failing code is among the code handling menus in Emacs. Yes. But how does that help with adding debug prints? The code that handles menus is spread across several nontrivial functions, and we have no idea which of them causes the problem and where. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 20:14 ` Eli Zaretskii @ 2010-10-12 20:49 ` Lennart Borgman 2010-10-13 11:30 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-12 20:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Tue, Oct 12, 2010 at 10:14 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> >> I mean that the failing code is among the code handling menus in Emacs. > > Yes. But how does that help with adding debug prints? The code that > handles menus is spread across several nontrivial functions, and we > have no idea which of them causes the problem and where. I assume that their is either a logical problem with the code inside Emacs or a bad assumption on how menu callbacks are actually run. By adding DebPrint call we could perhaps see if some code where called in an order we did not expect. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 20:49 ` Lennart Borgman @ 2010-10-13 11:30 ` Eli Zaretskii 0 siblings, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2010-10-13 11:30 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Tue, 12 Oct 2010 22:49:11 +0200 > Cc: 7190@debbugs.gnu.org > > On Tue, Oct 12, 2010 at 10:14 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> > >> I mean that the failing code is among the code handling menus in Emacs. > > > > Yes. But how does that help with adding debug prints? The code that > > handles menus is spread across several nontrivial functions, and we > > have no idea which of them causes the problem and where. > > I assume that their is either a logical problem with the code inside > Emacs or a bad assumption on how menu callbacks are actually run. By > adding DebPrint call we could perhaps see if some code where called in > an order we did not expect. Good luck doing that; without at least some idea where the problem happens, I would be unable to recommend where to put such DebPrint's or what to print. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-12 19:05 ` Eli Zaretskii 2010-10-12 19:13 ` Lennart Borgman @ 2010-10-19 0:20 ` Lennart Borgman 2010-10-19 5:59 ` Eli Zaretskii 1 sibling, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-19 0:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Tue, Oct 12, 2010 at 9:05 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Lennart Borgman <lennart.borgman@gmail.com> >> Date: Tue, 12 Oct 2010 11:37:52 +0200 >> Cc: 7190@debbugs.gnu.org >> >> > 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. I just got a new crash, but unfortunately I have still not understand how to look at those values. With "bt full" I get this (part of the bt): #6 0x7c927573 in ntdll!RtlPcToFileHeader () from C:\WINDOWS\system32\ntdll.dll No symbol table info available. #7 0x011c5399 in w32_free_submenu_strings (menu=0x9a05c5) at w32menu.c:1692 info = { cbSize = 44, fMask = 52, fType = 256, fState = 0, wID = 0, hSubMenu = 0x0, hbmpChecked = 0x0, hbmpUnchecked = 0x0, dwItemData = 8975208, dwTypeData = 0x0, cch = 0 } i = 6 num = 17 #8 0x011c53ad in w32_free_submenu_strings (menu=0x5e80611) at w32menu.c:1697 info = { cbSize = 44, fMask = 52, fType = 0, fState = 0, wID = 0, hSubMenu = 0x9a05c5, hbmpChecked = 0x0, hbmpUnchecked = 0x0, dwItemData = 0, dwTypeData = 0x0, cch = 10 } i = 10 num = 30 #9 0x011c53ad in w32_free_submenu_strings (menu=0x464d04eb) at w32menu.c:1697 info = { cbSize = 44, fMask = 52, fType = 0, fState = 0, wID = 0, hSubMenu = 0x5e80611, hbmpChecked = 0x0, hbmpUnchecked = 0x0, dwItemData = 0, dwTypeData = 0x0, cch = 4 } i = 5 num = 10 #10 0x011c53f8 in w32_free_menu_strings (hwnd=0x220048) at w32menu.c:1714 menu = 0x464d04eb #11 0x011c311a in menubar_selection_callback (f=0x411dc00, client_data=0x184a) at w32menu.c:353 j = 1 buf = { kind = MENU_BAR_EVENT, code = 0, part = scroll_bar_above_handle, modifiers = 0, x = 0, y = 0, timestamp = 0, padding = {0x0, 0x0}, frame_or_window = 68279301, arg = 59691226 } frame = 68279301 prefix = 59691298 entry = 59691226 vector = 92061701 subprefix_stack = 0x825f00 submenu_depth = 1 i = 6218 #12 0x011dcc2c in w32_read_socket (terminal=0x2d04c00, expected=0, hold_quit=0x82f6e0) at w32term.c:4623 inev = { kind = NO_EVENT, code = 0, part = scroll_bar_above_handle, modifiers = 0, x = 0, y = 0, timestamp = 0, padding = {0x0, 0x0}, frame_or_window = 0, arg = 45484058 } do_help = 0 count = 0 check_visibility = 0 msg = { msg = { hwnd = 0x220048, message = 273, wParam = 6218, lParam = 0, time = 59842578, pt = { x = 7, y = 327687 } }, dwModifiers = 0, rect = { left = 545258848, top = 2118300673, right = 13317672, bottom = 0 } } f = 0x411dc00 dpyinfo = 0x14061b0 ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-19 0:20 ` Lennart Borgman @ 2010-10-19 5:59 ` Eli Zaretskii 2010-10-19 10:33 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2010-10-19 5:59 UTC (permalink / raw) To: Lennart Borgman; +Cc: 7190 > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Tue, 19 Oct 2010 02:20:42 +0200 > Cc: 7190@debbugs.gnu.org > > > 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. > > I just got a new crash, but unfortunately I have still not understand > how to look at those values. Please be specific: what parts in the explanation above you don't understand? I don't know how to answer a question "I don't understand how to do X", when I already explained how to do it. > With "bt full" "bt full" is useless in this case, because the problem is a corruption of the heap. We need to establish which menu item(s) are corrupted, and the information about that is not in local variables displayed by "bt full", it's in the data structures manipulated by w32_free_submenu_strings and w32_free_menu_strings. I gave you above the way to start looking at these data structures. Please try using that as the starting point, and if the problem is not immediately obvious, come back and report your findings. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-19 5:59 ` Eli Zaretskii @ 2010-10-19 10:33 ` Lennart Borgman 0 siblings, 0 replies; 41+ messages in thread From: Lennart Borgman @ 2010-10-19 10:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7190 On Tue, Oct 19, 2010 at 7:59 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Lennart Borgman <lennart.borgman@gmail.com> >> Date: Tue, 19 Oct 2010 02:20:42 +0200 >> Cc: 7190@debbugs.gnu.org >> >> > 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. >> >> I just got a new crash, but unfortunately I have still not understand >> how to look at those values. > > Please be specific: what parts in the explanation above you don't > understand? I don't know how to answer a question "I don't understand > how to do X", when I already explained how to do it. > >> With "bt full" > > "bt full" is useless in this case, because the problem is a corruption > of the heap. We need to establish which menu item(s) are corrupted, > and the information about that is not in local variables displayed by > "bt full", it's in the data structures manipulated by > w32_free_submenu_strings and w32_free_menu_strings. I gave you above > the way to start looking at these data structures. Could you please tell me the exact commands to look at those data structures? ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-11 15:13 bug#7190: Crash in menus on w32 Lennart Borgman 2010-10-11 19:20 ` Eli Zaretskii @ 2010-10-13 11:02 ` grischka 2010-10-13 11:08 ` Lennart Borgman 2010-10-21 11:11 ` grischka 2010-11-12 7:53 ` Glenn Morris 3 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-10-13 11:02 UTC (permalink / raw) To: lennart.borgman; +Cc: bug-gnu-emacs > I assume that their is either a logical problem with the code inside > Emacs or a bad assumption on how menu callbacks are actually run. Is there a difference between logical problem and bad assumption? > 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-13 11:02 ` grischka @ 2010-10-13 11:08 ` Lennart Borgman 2010-10-13 14:03 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-13 11:08 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs On Wed, Oct 13, 2010 at 1:02 PM, grischka <grishka@gmx.de> wrote: >> I assume that their is either a logical problem with the code inside >> Emacs or a bad assumption on how menu callbacks are actually run. > > Is there a difference between logical problem and bad assumption? Yes. The code could be correct under some bad assumptions regarding the way the interface to the OS works. Is not that an important difference? >> 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-13 11:08 ` Lennart Borgman @ 2010-10-13 14:03 ` grischka 2010-10-13 14:43 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-10-13 14:03 UTC (permalink / raw) To: Lennart Borgman; +Cc: bug-gnu-emacs Lennart Borgman wrote: > On Wed, Oct 13, 2010 at 1:02 PM, grischka <grishka@gmx.de> wrote: >>> I assume that their is either a logical problem with the code inside >>> Emacs or a bad assumption on how menu callbacks are actually run. >> Is there a difference between logical problem and bad assumption? > > Yes. The code could be correct under some bad assumptions regarding > the way the interface to the OS works. > > Is not that an important difference? Not if you want to fix the bug. >>> 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? ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-13 14:03 ` grischka @ 2010-10-13 14:43 ` Lennart Borgman 2010-10-13 15:51 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-10-13 14:43 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs On Wed, Oct 13, 2010 at 4:03 PM, grischka <grishka@gmx.de> wrote: > Lennart Borgman wrote: >> >> On Wed, Oct 13, 2010 at 1:02 PM, grischka <grishka@gmx.de> wrote: >>>> >>>> I assume that their is either a logical problem with the code inside >>>> Emacs or a bad assumption on how menu callbacks are actually run. >>> >>> Is there a difference between logical problem and bad assumption? >> >> Yes. The code could be correct under some bad assumptions regarding >> the way the interface to the OS works. >> >> 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. >>>> 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.) ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-13 14:43 ` Lennart Borgman @ 2010-10-13 15:51 ` grischka 2010-10-13 16:06 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-10-13 15:51 UTC (permalink / raw) To: Lennart Borgman; +Cc: bug-gnu-emacs 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. >>>>> 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 ... ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-13 15:51 ` grischka @ 2010-10-13 16:06 ` Lennart Borgman 0 siblings, 0 replies; 41+ messages in thread From: Lennart Borgman @ 2010-10-13 16:06 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-11 15:13 bug#7190: Crash in menus on w32 Lennart Borgman 2010-10-11 19:20 ` Eli Zaretskii 2010-10-13 11:02 ` grischka @ 2010-10-21 11:11 ` grischka 2010-10-21 15:27 ` Jason Rumney 2010-11-12 7:53 ` Glenn Morris 3 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-10-21 11:11 UTC (permalink / raw) To: lennart.borgman; +Cc: bug-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 369 bytes --] Here's a patch that fixes the bug. Actually 4 bugs: 1) the initial cause: was freeing items prematurely and trying to free already freed items 2) memory leak: was trying to free items from already deleted menu 3) memory leak: was trying to free menu from already deleted window 4) other: was trying to set cursor in window with no associated frame --- grischka [-- Attachment #2: free-menu-strings.diff --] [-- Type: text/plain, Size: 7179 bytes --] commit 064225db78640a1fb48b68aac603c8e05cc69b80 Author: grischka <grischka> Date: Thu Oct 14 13:23:38 2010 +0200 fix w32menu ownerdraw string alloc/free diff --git a/src/w32fns.c b/src/w32fns.c index 8085035..83d577e 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -76,7 +76,6 @@ extern void free_frame_menubar (struct frame *); extern double atof (const char *); extern int w32_console_toggle_lock_key (int, Lisp_Object); extern void w32_menu_display_help (HWND, HMENU, UINT, UINT); -extern void w32_free_menu_strings (HWND); extern const char *map_w32_filename (const char *, const char **); extern int quit_char; @@ -280,12 +279,7 @@ unsigned int msh_mousewheel = 0; /* Timers */ #define MOUSE_BUTTON_ID 1 #define MOUSE_MOVE_ID 2 -#define MENU_FREE_ID 3 #define HOURGLASS_ID 4 -/* The delay (milliseconds) before a menu is freed after WM_EXITMENULOOP - is received. */ -#define MENU_FREE_DELAY 1000 -static unsigned menu_free_timer = 0; /* In dispnew.c */ @@ -3387,21 +3381,6 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) KillTimer (hwnd, mouse_move_timer); mouse_move_timer = 0; } - else if (wParam == menu_free_timer) - { - KillTimer (hwnd, menu_free_timer); - menu_free_timer = 0; - f = x_window_to_frame (dpyinfo, hwnd); - /* If a popup menu is active, don't wipe its strings. */ - if (menubar_in_use - && current_popup_menu == NULL) - { - /* Free memory used by owner-drawn and help-echo strings. */ - w32_free_menu_strings (hwnd); - f->output_data.w32->menubar_active = 0; - menubar_in_use = 0; - } - } else if (wParam == hourglass_timer) { KillTimer (hwnd, hourglass_timer); @@ -3465,14 +3444,11 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) case WM_EXITMENULOOP: f = x_window_to_frame (dpyinfo, hwnd); - /* If a menu is still active, check again after a short delay, - since Windows often (always?) sends the WM_EXITMENULOOP - before the corresponding WM_COMMAND message. - Don't do this if a popup menu is active, since it is only - menubar menus that require cleaning up in this way. - */ if (f && menubar_in_use && current_popup_menu == NULL) - menu_free_timer = SetTimer (hwnd, MENU_FREE_ID, MENU_FREE_DELAY, NULL); + { + f->output_data.w32->menubar_active = 0; + menubar_in_use = 0; + } /* If hourglass cursor should be displayed, display it now. */ if (f && f->output_data.w32->hourglass_p) @@ -3632,15 +3608,6 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) goto command; case WM_COMMAND: menubar_in_use = 0; - f = x_window_to_frame (dpyinfo, hwnd); - if (f && HIWORD (wParam) == 0) - { - if (menu_free_timer) - { - KillTimer (hwnd, menu_free_timer); - menu_free_timer = 0; - } - } case WM_MOVE: case WM_SIZE: command: @@ -3748,6 +3715,8 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) if (LOWORD (lParam) == HTCLIENT) { f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + return 0; if (f->output_data.w32->hourglass_p && !menubar_in_use && !current_popup_menu) SetCursor (f->output_data.w32->hourglass_cursor); diff --git a/src/w32menu.c b/src/w32menu.c index ff6bd97..78d59fc 100644 --- a/src/w32menu.c +++ b/src/w32menu.c @@ -108,7 +108,7 @@ static Lisp_Object simple_dialog_show (FRAME_PTR, Lisp_Object, Lisp_Object); static void utf8to16 (unsigned char *, int, WCHAR *); static int fill_in_menu (HMENU, widget_value *); -void w32_free_menu_strings (HWND); +static void w32_free_menu_strings (HMENU); \f /* This is set nonzero after the user activates the menu bar, and set @@ -347,8 +347,6 @@ menubar_selection_callback (FRAME_PTR f, void * client_data) buf.kind = MENU_BAR_EVENT; buf.frame_or_window = frame; buf.arg = entry; - /* Free memory used by owner-drawn and help-echo strings. */ - w32_free_menu_strings (FRAME_W32_WINDOW (f)); kbd_buffer_store_event (&buf); f->output_data.w32->menubar_active = 0; @@ -357,8 +355,6 @@ menubar_selection_callback (FRAME_PTR f, void * client_data) i += MENU_ITEMS_ITEM_LENGTH; } } - /* Free memory used by owner-drawn and help-echo strings. */ - w32_free_menu_strings (FRAME_W32_WINDOW (f)); f->output_data.w32->menubar_active = 0; } @@ -588,6 +584,7 @@ set_frame_menubar (FRAME_PTR f, int first_time, int deep_p) if (menubar_widget) { + w32_free_menu_strings (menubar_widget); /* Empty current menubar, rather than creating a fresh one. */ while (DeleteMenu (menubar_widget, 0, MF_BYPOSITION)) ; @@ -643,6 +640,7 @@ free_frame_menubar (FRAME_PTR f) HMENU old = GetMenu (FRAME_W32_WINDOW (f)); SetMenu (FRAME_W32_WINDOW (f), NULL); f->output_data.w32->menubar_widget = NULL; + w32_free_menu_strings (old); DestroyMenu (old); } @@ -898,10 +896,11 @@ w32_menu_show (FRAME_PTR f, int x, int y, int for_click, int keymaps, /* Free the widget_value objects we used to specify the contents. */ free_menubar_widget_value_tree (first_wv); + /* Free the owner-drawn and help-echo menu strings. */ + w32_free_menu_strings (menu); DestroyMenu (menu); + current_popup_menu = NULL; - /* Free the owner-drawn and help-echo menu strings. */ - w32_free_menu_strings (FRAME_W32_WINDOW (f)); f->output_data.w32->menubar_active = 0; /* Find the selected item, and its pane, to return @@ -1651,9 +1650,11 @@ w32_menu_display_help (HWND owner, HMENU menu, UINT item, UINT flags) /* Free memory used by owner-drawn strings. */ static void -w32_free_submenu_strings (HMENU menu) +w32_free_menu_strings (HMENU menu) { int i, num = GetMenuItemCount (menu); + if (!get_menu_item_info) + return; for (i = 0; i < num; i++) { MENUITEMINFO info; @@ -1674,29 +1675,10 @@ w32_free_submenu_strings (HMENU menu) /* Recurse down submenus. */ if (info.hSubMenu) - w32_free_submenu_strings (info.hSubMenu); + w32_free_menu_strings (info.hSubMenu); } } -void -w32_free_menu_strings (HWND hwnd) -{ - HMENU menu = current_popup_menu; - - if (get_menu_item_info) - { - /* If there is no popup menu active, free the strings from the frame's - menubar. */ - if (!menu) - menu = GetMenu (hwnd); - - if (menu) - w32_free_submenu_strings (menu); - } - - current_popup_menu = NULL; -} - #endif /* HAVE_MENUS */ /* The following is used by delayed window autoselection. */ diff --git a/src/w32term.c b/src/w32term.c index 1f53860..0cef1b7 100644 --- a/src/w32term.c +++ b/src/w32term.c @@ -5734,11 +5734,11 @@ x_free_frame_resources (struct frame *f) if (FRAME_FACE_CACHE (f)) free_frame_faces (f); + free_frame_menubar (f); + if (FRAME_W32_WINDOW (f)) my_destroy_window (f, FRAME_W32_WINDOW (f)); - free_frame_menubar (f); - unload_color (f, FRAME_FOREGROUND_PIXEL (f)); unload_color (f, FRAME_BACKGROUND_PIXEL (f)); unload_color (f, f->output_data.w32->cursor_pixel); ^ permalink raw reply related [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-21 11:11 ` grischka @ 2010-10-21 15:27 ` Jason Rumney 2010-10-21 17:07 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Jason Rumney @ 2010-10-21 15:27 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs grischka <grishka@gmx.de> writes: > case WM_EXITMENULOOP: > f = x_window_to_frame (dpyinfo, hwnd); > > - /* If a menu is still active, check again after a short delay, > - since Windows often (always?) sends the WM_EXITMENULOOP > - before the corresponding WM_COMMAND message. > - Don't do this if a popup menu is active, since it is only > - menubar menus that require cleaning up in this way. > - */ > if (f && menubar_in_use && current_popup_menu == NULL) > - menu_free_timer = SetTimer (hwnd, MENU_FREE_ID, MENU_FREE_DELAY, NULL); > + { > + f->output_data.w32->menubar_active = 0; > + menubar_in_use = 0; > + } I don't see anything in your change to handle freeing of the menubar structures in the case where the user clicks on the menubar then clicks away without selecting anything. The above code was to fix a memory and resource leak in that case. Jason ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-21 15:27 ` Jason Rumney @ 2010-10-21 17:07 ` grischka 2010-10-22 14:09 ` Jason Rumney 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-10-21 17:07 UTC (permalink / raw) To: Jason Rumney; +Cc: bug-gnu-emacs Jason Rumney wrote: > I don't see anything in your change to handle freeing of the menubar > structures in the case where the user clicks on the menubar then clicks > away without selecting anything. This is correct. The patch frees the item-string always when (and in the same place where) the MENUITEM structure itself is destroyed. Since this structure is the only place that has the pointer, it is hence impossible by design to access the pointer after it was freed. > The above code was to fix a memory and resource leak in that case. With the patch, leaking these strings cannot happen by design also provided the MENUITEMs themselves are destroyed correctly always which is made sure by bugs 2/3 fixed: >> 2) memory leak: was trying to free items from already deleted menu >> 3) memory leak: was trying to free menu from already deleted window --- grischka ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-21 17:07 ` grischka @ 2010-10-22 14:09 ` Jason Rumney 2010-10-22 16:20 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Jason Rumney @ 2010-10-22 14:09 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs grischka <grishka@gmx.de> writes: >> The above code was to fix a memory and resource leak in that case. > > With the patch, leaking these strings cannot happen by design also > provided the MENUITEMs themselves are destroyed correctly always which > is made sure by bugs 2/3 fixed: >>> 2) memory leak: was trying to free items from already deleted menu >>> 3) memory leak: was trying to free menu from already deleted window OK, I understand now - it seems you have fixed the underlying bug that caused that memory leak to happen in the first place, so the timer kludge is no longer neccesary. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-22 14:09 ` Jason Rumney @ 2010-10-22 16:20 ` grischka 2010-11-08 1:49 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-10-22 16:20 UTC (permalink / raw) To: Jason Rumney; +Cc: bug-gnu-emacs Jason Rumney wrote: > grischka <grishka@gmx.de> writes: > >>> The above code was to fix a memory and resource leak in that case. >> With the patch, leaking these strings cannot happen by design also >> provided the MENUITEMs themselves are destroyed correctly always which >> is made sure by bugs 2/3 fixed: >>>> 2) memory leak: was trying to free items from already deleted menu >>>> 3) memory leak: was trying to free menu from already deleted window > > OK, I understand now - it seems you have fixed the underlying bug that > caused that memory leak to happen in the first place, so the timer > kludge is no longer neccesary. > Just tried to be less clever. "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-22 16:20 ` grischka @ 2010-11-08 1:49 ` Lennart Borgman 2010-11-08 10:15 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-11-08 1:49 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs On Fri, Oct 22, 2010 at 6:20 PM, grischka <grishka@gmx.de> wrote: > > Just tried to be less clever. > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan What is the status of this? I just got a crash using my patched Emacs with sources as below. This Emacs was built from sources in bazaar identified as: Nick 'trunk' info: revision id: yamaoka@jpl.org-20101019081945-8auglqcd1ne2o0rb revno: 101998 date: 2010-10-19 08:19:45 +0000 Nick 'emacsw32' (from 'trunk') info: revision id: lennart.borgman@gmail.com-20101019140903-0x7gubo4o0c9voai revno: 99341 date: 2010-10-19 16:09:03 +0200 ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-08 1:49 ` Lennart Borgman @ 2010-11-08 10:15 ` grischka 2010-11-08 11:18 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-11-08 10:15 UTC (permalink / raw) To: Lennart Borgman; +Cc: bug-gnu-emacs Lennart Borgman wrote: > What is the status of this? I just got a crash using my patched Emacs > with sources as below. You're using the patch from above and still get the crash??? > > This Emacs was built from sources in bazaar identified as: > > Nick 'trunk' info: > revision id: yamaoka@jpl.org-20101019081945-8auglqcd1ne2o0rb > revno: 101998 > date: 2010-10-19 08:19:45 +0000 > > Nick 'emacsw32' (from 'trunk') info: > revision id: lennart.borgman@gmail.com-20101019140903-0x7gubo4o0c9voai > revno: 99341 > date: 2010-10-19 16:09:03 +0200 > ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-08 10:15 ` grischka @ 2010-11-08 11:18 ` Lennart Borgman 2010-11-08 19:51 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-11-08 11:18 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs On Mon, Nov 8, 2010 at 11:15 AM, grischka <grishka@gmx.de> wrote: > Lennart Borgman wrote: >> >> What is the status of this? I just got a crash using my patched Emacs >> with sources as below. > > You're using the patch from above and still get the crash??? > >> >> This Emacs was built from sources in bazaar identified as: >> >> Nick 'trunk' info: >> revision id: yamaoka@jpl.org-20101019081945-8auglqcd1ne2o0rb >> revno: 101998 >> date: 2010-10-19 08:19:45 +0000 >> >> Nick 'emacsw32' (from 'trunk') info: >> revision id: lennart.borgman@gmail.com-20101019140903-0x7gubo4o0c9voai >> revno: 99341 >> date: 2010-10-19 16:09:03 +0200 I do not know if I am using it, that is what I am asking ;-) I have not applied it myself. Should it be in the checkout I have made? (How do I see that?) ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-08 11:18 ` Lennart Borgman @ 2010-11-08 19:51 ` grischka 2010-11-08 23:11 ` Lennart Borgman 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-11-08 19:51 UTC (permalink / raw) To: Lennart Borgman; +Cc: bug-gnu-emacs Lennart Borgman wrote: > I do not know if I am using it, that is what I am asking ;-) > > I have not applied it myself. Should it be in the checkout I have > made? (How do I see that?) To know that you're using the patch, apply it. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-08 19:51 ` grischka @ 2010-11-08 23:11 ` Lennart Borgman 2010-11-09 16:16 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Lennart Borgman @ 2010-11-08 23:11 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs On Mon, Nov 8, 2010 at 8:51 PM, grischka <grishka@gmx.de> wrote: > Lennart Borgman wrote: >> >> I do not know if I am using it, that is what I am asking ;-) >> >> I have not applied it myself. Should it be in the checkout I have >> made? (How do I see that?) > > To know that you're using the patch, apply it. Has it been applied to the trunk yet? ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-08 23:11 ` Lennart Borgman @ 2010-11-09 16:16 ` grischka 2010-11-09 17:08 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-11-09 16:16 UTC (permalink / raw) To: Lennart Borgman; +Cc: bug-gnu-emacs Lennart Borgman wrote: > On Mon, Nov 8, 2010 at 8:51 PM, grischka <grishka@gmx.de> wrote: >> Lennart Borgman wrote: >>> I do not know if I am using it, that is what I am asking ;-) >>> >>> I have not applied it myself. Should it be in the checkout I have >>> made? (How do I see that?) >> To know that you're using the patch, apply it. > > Has it been applied to the trunk yet? > Obviously, if you want that and don't have commit rights yourself you need to find someone else who understands the patch and is willing to commit it. Also, before doing so it might make sense if you test the patch esp. since you seem to be the only person who sees this bug due to your personal setup (i.e. ownerdrawn items in the menu-bar menu). Of course the patch is correct but there is no reason to believe me ;) --- grischka ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-09 16:16 ` grischka @ 2010-11-09 17:08 ` Eli Zaretskii 2010-11-09 18:39 ` grischka 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2010-11-09 17:08 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs > Date: Tue, 09 Nov 2010 17:16:46 +0100 > From: grischka <grishka@gmx.de> > Cc: bug-gnu-emacs@gnu.org > > Obviously, if you want that and don't have commit rights yourself > you need to find someone else who understands the patch and is willing > to commit it. I think it's too large to be committed without your signing legal papers. And I don't see your name on file with the FSF copyright assignments list. If you want your patch to be installed, please contact Stefan or Chong and ask them for instructions. (They could also decide that I'm wrong, and the patch can be treated as "tiny", which doesn't need papers.) TIA ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-09 17:08 ` Eli Zaretskii @ 2010-11-09 18:39 ` grischka [not found] ` <jwvpqueyy9i.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-11-09 18:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnu-emacs Eli Zaretskii wrote: >> Date: Tue, 09 Nov 2010 17:16:46 +0100 >> From: grischka <grishka@gmx.de> >> Cc: bug-gnu-emacs@gnu.org >> >> Obviously, if you want that and don't have commit rights yourself >> you need to find someone else who understands the patch and is willing >> to commit it. > > I think it's too large to be committed without your signing legal > papers. And I don't see your name on file with the FSF copyright > assignments list. If you want your patch to be installed, please > contact Stefan or Chong and ask them for instructions. (They could > also decide that I'm wrong, and the patch can be treated as "tiny", > which doesn't need papers.) I will not assign my copyright to someone else however I do not claim copyright for this patch. Anyway it does not add one single new line. (~50 lines removed, ~20 lines moved to other places.) --- grischka > > TIA > ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <jwvpqueyy9i.fsf-monnier+emacs@gnu.org>]
* bug#7190: Crash in menus on w32 [not found] ` <jwvpqueyy9i.fsf-monnier+emacs@gnu.org> @ 2010-11-10 10:33 ` grischka 0 siblings, 0 replies; 41+ messages in thread From: grischka @ 2010-11-10 10:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, bug-gnu-emacs Stefan Monnier wrote: >> I will not assign my copyright to someone else however I do not claim >> copyright for this patch. Anyway it does not add one single new line. >> (~50 lines removed, ~20 lines moved to other places.) > > As you know, programming is not just writing the lines, but also putting > them in the right order ;-). Then again even more programming effort is required to put lines in wrong order ;). > Your patch is much too non-trivial to be accepted as a "tiny change", > which means we need you to sign some paperwork before we can install it. > > If you're willing to do that, then please fill the form below and email > it as instructed so the FSF can send you the relevant paperwork to sign. > Thank you very much for your help in improving Emacs, > Well, thanks very much too for developing emacs. Please understand that in order to preserve rsp. encourage symmetry and transparency in the meta-code I give this patch to you as I give it to anyone else who wants it, that is under the same terms and conditions as I received your code and without any further agreements beyond those terms with certain parties. --- grischka ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-10-11 15:13 bug#7190: Crash in menus on w32 Lennart Borgman ` (2 preceding siblings ...) 2010-10-21 11:11 ` grischka @ 2010-11-12 7:53 ` Glenn Morris 2010-11-12 22:40 ` grischka 3 siblings, 1 reply; 41+ messages in thread From: Glenn Morris @ 2010-11-12 7:53 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs grischka wrote: > I will not assign my copyright to someone else however I do not claim > copyright for this patch. Would you be willing to sign a copyright disclaimer to put this change in the public domain? (You seem to be saying that, but we need a signed piece of paper to that effect to be able to use it.) (It sounds like this may be being discussed off-list.) ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-12 7:53 ` Glenn Morris @ 2010-11-12 22:40 ` grischka 2010-11-13 17:08 ` Chong Yidong 0 siblings, 1 reply; 41+ messages in thread From: grischka @ 2010-11-12 22:40 UTC (permalink / raw) To: Glenn Morris; +Cc: bug-gnu-emacs Glenn Morris wrote: > grischka wrote: > >> I will not assign my copyright to someone else however I do not claim >> copyright for this patch. > > Would you be willing to sign a copyright disclaimer to put this change > in the public domain? > > (You seem to be saying that, but we need a signed piece of paper to > that effect to be able to use it.) Yes, I was saying that because to me there was no content with copyright really. If you say there is then I do not disclaim it. Note that giving up my copyright (if any) would allow you to bypass the GPL with the patch. As it is based on code that I received under GPL myself, this is not possible. --- grischka > > (It sounds like this may be being discussed off-list.) > ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-12 22:40 ` grischka @ 2010-11-13 17:08 ` Chong Yidong 2013-02-18 2:23 ` Glenn Morris 0 siblings, 1 reply; 41+ messages in thread From: Chong Yidong @ 2010-11-13 17:08 UTC (permalink / raw) To: grischka; +Cc: bug-gnu-emacs grischka <grishka@gmx.de> writes: > Note that giving up my copyright (if any) would allow you to bypass > the GPL with the patch. No it doesn't. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2010-11-13 17:08 ` Chong Yidong @ 2013-02-18 2:23 ` Glenn Morris 2013-02-18 2:39 ` Lennart Borgman 2013-02-18 3:43 ` Eli Zaretskii 0 siblings, 2 replies; 41+ messages in thread From: Glenn Morris @ 2013-02-18 2:23 UTC (permalink / raw) To: 7190 So IIUC there is some kind of issue here, and someone wrote a patch. However, they don't want to assign copyright for it (which is their prerogative, of course). But given this, I don't see how any progress can be made. ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2013-02-18 2:23 ` Glenn Morris @ 2013-02-18 2:39 ` Lennart Borgman 2013-02-18 3:43 ` Eli Zaretskii 1 sibling, 0 replies; 41+ messages in thread From: Lennart Borgman @ 2013-02-18 2:39 UTC (permalink / raw) To: Glenn Morris; +Cc: 7190 [-- Attachment #1: Type: text/plain, Size: 616 bytes --] My old suggestion was adding checks for all system calls. I started doing that, but since those checks were not added to the core I found the merging to difficult. I ran out of time and had to skip it. I still suggest adding checks for all system calls. Maybe someone else have time to catch the error now. On Mon, Feb 18, 2013 at 3:23 AM, Glenn Morris <rgm@gnu.org> wrote: > > So IIUC there is some kind of issue here, and someone wrote a patch. > However, they don't want to assign copyright for it (which is their > prerogative, of course). But given this, I don't see how any progress > can be made. > > > > [-- Attachment #2: Type: text/html, Size: 953 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#7190: Crash in menus on w32 2013-02-18 2:23 ` Glenn Morris 2013-02-18 2:39 ` Lennart Borgman @ 2013-02-18 3:43 ` Eli Zaretskii 1 sibling, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2013-02-18 3:43 UTC (permalink / raw) To: Glenn Morris; +Cc: 7190 > From: Glenn Morris <rgm@gnu.org> > Date: Sun, 17 Feb 2013 21:23:44 -0500 > > > So IIUC there is some kind of issue here, and someone wrote a patch. > However, they don't want to assign copyright for it (which is their > prerogative, of course). But given this, I don't see how any progress > can be made. Please close. ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2013-02-18 3:43 UTC | newest] Thread overview: 41+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-10-11 15:13 bug#7190: Crash in menus on w32 Lennart Borgman 2010-10-11 19:20 ` Eli Zaretskii 2010-10-11 21:21 ` Lennart Borgman 2010-10-12 4:04 ` Eli Zaretskii 2010-10-12 9:37 ` Lennart Borgman 2010-10-12 19:05 ` Eli Zaretskii 2010-10-12 19:13 ` Lennart Borgman 2010-10-12 19:40 ` Eli Zaretskii 2010-10-12 20:09 ` Lennart Borgman 2010-10-12 20:14 ` Eli Zaretskii 2010-10-12 20:49 ` Lennart Borgman 2010-10-13 11:30 ` Eli Zaretskii 2010-10-19 0:20 ` Lennart Borgman 2010-10-19 5:59 ` Eli Zaretskii 2010-10-19 10:33 ` Lennart Borgman 2010-10-13 11:02 ` grischka 2010-10-13 11:08 ` Lennart Borgman 2010-10-13 14:03 ` grischka 2010-10-13 14:43 ` Lennart Borgman 2010-10-13 15:51 ` grischka 2010-10-13 16:06 ` Lennart Borgman 2010-10-21 11:11 ` grischka 2010-10-21 15:27 ` Jason Rumney 2010-10-21 17:07 ` grischka 2010-10-22 14:09 ` Jason Rumney 2010-10-22 16:20 ` grischka 2010-11-08 1:49 ` Lennart Borgman 2010-11-08 10:15 ` grischka 2010-11-08 11:18 ` Lennart Borgman 2010-11-08 19:51 ` grischka 2010-11-08 23:11 ` Lennart Borgman 2010-11-09 16:16 ` grischka 2010-11-09 17:08 ` Eli Zaretskii 2010-11-09 18:39 ` grischka [not found] ` <jwvpqueyy9i.fsf-monnier+emacs@gnu.org> 2010-11-10 10:33 ` grischka 2010-11-12 7:53 ` Glenn Morris 2010-11-12 22:40 ` grischka 2010-11-13 17:08 ` Chong Yidong 2013-02-18 2:23 ` Glenn Morris 2013-02-18 2:39 ` Lennart Borgman 2013-02-18 3:43 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.