* bug#6284: Crash in w32_wnd_proc at frame deletion
@ 2010-05-27 17:44 Lennart Borgman
2010-05-27 18:26 ` Juanma Barranquero
0 siblings, 1 reply; 6+ messages in thread
From: Lennart Borgman @ 2010-05-27 17:44 UTC (permalink / raw)
To: 6284
Now I finally got a backtrace of this crash. Thanks for the (harsh)
reminders about running under gdb.
Here is part of the backtrace
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1836.0xef8]
0x011cc376 in w32_wnd_proc (hwnd=0x1001ac, msg=32, wParam=1049004,
lParam=33554433) at w32fns.c:4351
4351 if (f->output_data.w32->hourglass_p && !menubar_in_use
(gdb) bt
#0 0x011cc376 in w32_wnd_proc (hwnd=0x1001ac, msg=32, wParam=1049004,
lParam=33554433) at w32fns.c:4351
#1 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#2 0x001001ac in ?? ()
#3 0x00000020 in ?? ()
#4 0x001001ac in ?? ()
#5 0x02000001 in ?? ()
#6 0x011c9291 in post_character_message (hwnd=0x11c9291, msg=1049004,
wParam=32, lParam=1049004, dwmodifiers=33554433) at w32fns.c:3049
#7 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#8 0x011c9291 in post_character_message (hwnd=0x0, msg=18649745,
wParam=1049004, lParam=32, dwmodifiers=1049004) at w32fns.c:3049
#9 0x7e428ea0 in USER32!DefWindowProcW () from C:\WINDOWS\system32\user32.dll
#10 0x00000000 in ?? ()
Lisp Backtrace:
"delete-frame" (0x82af44)
It looks like the important part is line 4351. I tried to look at f:
(gdb) print f
$1 = (struct frame *) 0x0
(gdb) print f->output_data
Cannot access memory at address 0x104
Does this mean that f might be gone here and that there should be a
test for this?
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#6284: Crash in w32_wnd_proc at frame deletion 2010-05-27 17:44 bug#6284: Crash in w32_wnd_proc at frame deletion Lennart Borgman @ 2010-05-27 18:26 ` Juanma Barranquero 2010-05-27 18:34 ` Lennart Borgman 0 siblings, 1 reply; 6+ messages in thread From: Juanma Barranquero @ 2010-05-27 18:26 UTC (permalink / raw) To: Lennart Borgman; +Cc: 6284 On Thu, May 27, 2010 at 19:44, Lennart Borgman <lennart.borgman@gmail.com> wrote: > Now I finally got a backtrace of this crash. Thanks for the (harsh) > reminders about running under gdb. More like "stern" :-) > Here is part of the backtrace Is that with an optimized or non-optimized build? Is the crash repeatable at will? Juanma ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6284: Crash in w32_wnd_proc at frame deletion 2010-05-27 18:26 ` Juanma Barranquero @ 2010-05-27 18:34 ` Lennart Borgman 2010-05-27 22:33 ` Lennart Borgman 0 siblings, 1 reply; 6+ messages in thread From: Lennart Borgman @ 2010-05-27 18:34 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 6284 On Thu, May 27, 2010 at 8:26 PM, Juanma Barranquero <lekktu@gmail.com> wrote: > On Thu, May 27, 2010 at 19:44, Lennart Borgman > <lennart.borgman@gmail.com> wrote: > >> Now I finally got a backtrace of this crash. Thanks for the (harsh) >> reminders about running under gdb. > > More like "stern" :-) My English does not know that. >> Here is part of the backtrace > > Is that with an optimized or non-optimized build? Non-optimized. > Is the crash repeatable at will? Maybe, but I do not know whose will. I know how it happens, but not when. Anyway, I mailed Eli and asked him immediately since I feared my pc might hang (which it can do sometimes when bugs jumps in). Thee is a bug in w32fns.c where this happened. There should be a check if f is 0. There seems to be more places where this is not checked. I will look through them and add a patch here. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6284: Crash in w32_wnd_proc at frame deletion 2010-05-27 18:34 ` Lennart Borgman @ 2010-05-27 22:33 ` Lennart Borgman 2010-05-28 23:44 ` Lennart Borgman 0 siblings, 1 reply; 6+ messages in thread From: Lennart Borgman @ 2010-05-27 22:33 UTC (permalink / raw) To: Juanma Barranquero, Eli Zaretskii; +Cc: 6284 [-- Attachment #1: Type: text/plain, Size: 344 bytes --] On Thu, May 27, 2010 at 8:34 PM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > > There is a > bug in w32fns.c where this happened. There should be a check if f is > 0. > > There seems to be more places where this is not checked. I will look > through them and add a patch here. I have attached a patch. Please review it and install it. [-- Attachment #2: bug6284-1.diff --] [-- Type: text/x-patch, Size: 3617 bytes --] C:\emacs-lp\bld\emacs\bug6284>bzr diff --old c:\emacs-lp\bld\emacs\trunk -p trunk/:bug6284/ === modified file 'src/w32fns.c' --- trunk/src/w32fns.c 2010-05-11 21:02:32 +0000 +++ bug6284/src/w32fns.c 2010-05-27 19:59:34 +0000 @@ -3195,6 +3195,9 @@ break; f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + break; + w = XWINDOW (FRAME_SELECTED_WINDOW (f)); form.dwStyle = CFS_RECT; @@ -3349,8 +3352,10 @@ /* Ignore middle and extra buttons as long as the menu is active. */ f = x_window_to_frame (dpyinfo, hwnd); - if (f && f->output_data.w32->menubar_active) - return 0; + if (!f) + return 0; + if (f->output_data.w32->menubar_active) + return 0; if (parse_button (msg, HIWORD (wParam), &button, &up)) { @@ -3379,7 +3384,9 @@ it's wrong to handle them as if they happened on the underlying frame. */ f = x_window_to_frame (dpyinfo, hwnd); - if (f && f->output_data.w32->menubar_active) + if (!f) + return 0; + if (f->output_data.w32->menubar_active) return 0; /* If the mouse has just moved into the frame, start tracking @@ -3475,6 +3482,8 @@ KillTimer (hwnd, menu_free_timer); menu_free_timer = 0; f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + return 0; /* If a popup menu is active, don't wipe its strings. */ if (menubar_in_use && current_popup_menu == NULL) @@ -3489,7 +3498,10 @@ { KillTimer (hwnd, hourglass_timer); hourglass_timer = 0; - w32_show_hourglass (x_window_to_frame (dpyinfo, hwnd)); + f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + return 0; + w32_show_hourglass (f); } return 0; @@ -3522,14 +3534,15 @@ being active). */ f = x_window_to_frame (dpyinfo, hwnd); - if (f - && (f->output_data.w32->menubar_active - /* We can receive this message even in the absence of a - menubar (ie. when the system menu is activated) - in this - case we do NOT want to forward the message, otherwise it - will cause the menubar to suddenly appear when the user - had requested it to be turned off! */ - || f->output_data.w32->menubar_widget == NULL)) + if (!f) + return 0; + if (f->output_data.w32->menubar_active + /* We can receive this message even in the absence of a + menubar (ie. when the system menu is activated) - in this + case we do NOT want to forward the message, otherwise it + will cause the menubar to suddenly appear when the user + had requested it to be turned off! */ + || f->output_data.w32->menubar_widget == NULL) return 0; { === modified file 'src/w32term.c' --- trunk/src/w32term.c 2010-04-10 16:28:30 +0000 +++ bug6284/src/w32term.c 2010-05-27 20:06:13 +0000 @@ -4375,7 +4375,7 @@ But it was originally changed to this to fix a bug, so I have not removed it completely in case the bug is still there. */ if (help_echo_string != previous_help_echo_string || - (!NILP (help_echo_string) && !STRINGP (help_echo_string) && f->mouse_moved)) + (!NILP (help_echo_string) && !STRINGP (help_echo_string) && f && f->mouse_moved)) #else /* This is what xterm.c does. */ if (!NILP (help_echo_string) || !NILP (previous_help_echo_string)) @@ -4554,7 +4554,8 @@ else { f = x_window_to_frame (dpyinfo, msg.msg.hwnd); - f->async_visible = msg.msg.wParam; + if (f) + f->async_visible = msg.msg.wParam; } #endif ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6284: Crash in w32_wnd_proc at frame deletion 2010-05-27 22:33 ` Lennart Borgman @ 2010-05-28 23:44 ` Lennart Borgman 2011-07-08 12:53 ` Jason Rumney 0 siblings, 1 reply; 6+ messages in thread From: Lennart Borgman @ 2010-05-28 23:44 UTC (permalink / raw) To: Juanma Barranquero, Eli Zaretskii; +Cc: 6284 [-- Attachment #1: Type: text/plain, Size: 457 bytes --] New patch. I missed one place in the previous patch and this just hit me. It is great running under the debugger and finally being able to find and fix those bugs I have wondered about quite long now but have not had time to fix before. The only problem now is how to get them installed. As I said elsewhere I currently have no checkout from savannah so I can't checkin the patches myself AFAIK. Should I get a second checkout from savannah for this, or? [-- Attachment #2: bug6284-2.diff --] [-- Type: text/x-patch, Size: 3915 bytes --] C:\emacs-lp\bld\emacs\bug6284>bzr diff --old c:\emacs-lp\bld\emacs\trunk -p trunk/:bug6284/ === modified file 'src/w32fns.c' --- trunk/src/w32fns.c 2010-05-11 21:02:32 +0000 +++ bug6284/src/w32fns.c 2010-05-28 23:32:20 +0000 @@ -3195,6 +3195,9 @@ break; f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + break; + w = XWINDOW (FRAME_SELECTED_WINDOW (f)); form.dwStyle = CFS_RECT; @@ -3349,8 +3352,10 @@ /* Ignore middle and extra buttons as long as the menu is active. */ f = x_window_to_frame (dpyinfo, hwnd); - if (f && f->output_data.w32->menubar_active) - return 0; + if (!f) + return 0; + if (f->output_data.w32->menubar_active) + return 0; if (parse_button (msg, HIWORD (wParam), &button, &up)) { @@ -3379,7 +3384,9 @@ it's wrong to handle them as if they happened on the underlying frame. */ f = x_window_to_frame (dpyinfo, hwnd); - if (f && f->output_data.w32->menubar_active) + if (!f) + return 0; + if (f->output_data.w32->menubar_active) return 0; /* If the mouse has just moved into the frame, start tracking @@ -3475,6 +3482,8 @@ KillTimer (hwnd, menu_free_timer); menu_free_timer = 0; f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + return 0; /* If a popup menu is active, don't wipe its strings. */ if (menubar_in_use && current_popup_menu == NULL) @@ -3489,7 +3498,10 @@ { KillTimer (hwnd, hourglass_timer); hourglass_timer = 0; - w32_show_hourglass (x_window_to_frame (dpyinfo, hwnd)); + f = x_window_to_frame (dpyinfo, hwnd); + if (!f) + return 0; + w32_show_hourglass (f); } return 0; @@ -3522,14 +3534,15 @@ being active). */ f = x_window_to_frame (dpyinfo, hwnd); - if (f - && (f->output_data.w32->menubar_active - /* We can receive this message even in the absence of a - menubar (ie. when the system menu is activated) - in this - case we do NOT want to forward the message, otherwise it - will cause the menubar to suddenly appear when the user - had requested it to be turned off! */ - || f->output_data.w32->menubar_widget == NULL)) + if (!f) + return 0; + if (f->output_data.w32->menubar_active + /* We can receive this message even in the absence of a + menubar (ie. when the system menu is activated) - in this + case we do NOT want to forward the message, otherwise it + will cause the menubar to suddenly appear when the user + had requested it to be turned off! */ + || f->output_data.w32->menubar_widget == NULL) return 0; { @@ -3831,6 +3844,8 @@ 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); === modified file 'src/w32term.c' --- trunk/src/w32term.c 2010-04-10 16:28:30 +0000 +++ bug6284/src/w32term.c 2010-05-27 20:06:13 +0000 @@ -4375,7 +4375,7 @@ But it was originally changed to this to fix a bug, so I have not removed it completely in case the bug is still there. */ if (help_echo_string != previous_help_echo_string || - (!NILP (help_echo_string) && !STRINGP (help_echo_string) && f->mouse_moved)) + (!NILP (help_echo_string) && !STRINGP (help_echo_string) && f && f->mouse_moved)) #else /* This is what xterm.c does. */ if (!NILP (help_echo_string) || !NILP (previous_help_echo_string)) @@ -4554,7 +4554,8 @@ else { f = x_window_to_frame (dpyinfo, msg.msg.hwnd); - f->async_visible = msg.msg.wParam; + if (f) + f->async_visible = msg.msg.wParam; } #endif ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#6284: Crash in w32_wnd_proc at frame deletion 2010-05-28 23:44 ` Lennart Borgman @ 2011-07-08 12:53 ` Jason Rumney 0 siblings, 0 replies; 6+ messages in thread From: Jason Rumney @ 2011-07-08 12:53 UTC (permalink / raw) To: Lennart Borgman; +Cc: Juanma Barranquero, 6284-done Lennart Borgman <lennart.borgman@gmail.com> writes: > New patch. I missed one place in the previous patch and this just hit me. > > It is great running under the debugger and finally being able to find > and fix those bugs I have wondered about quite long now but have not > had time to fix before. > > The only problem now is how to get them installed. As I said elsewhere > I currently have no checkout from savannah so I can't checkin the > patches myself AFAIK. Should I get a second checkout from savannah for > this, or? I fixed the two locations where a bug could conceivably occur. Others were either #ifdef'ed out, or already protected against dereferencing the non-existent frame struct. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-07-08 12:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-05-27 17:44 bug#6284: Crash in w32_wnd_proc at frame deletion Lennart Borgman 2010-05-27 18:26 ` Juanma Barranquero 2010-05-27 18:34 ` Lennart Borgman 2010-05-27 22:33 ` Lennart Borgman 2010-05-28 23:44 ` Lennart Borgman 2011-07-08 12:53 ` Jason Rumney
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).