* 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).