bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Angelo Graziosi]

My Emacs builds [1] from master, I did in April, crash when PC is 
suspended and then waked up. This seems related to the use of 
tabbar-ruler package. This is the minimal init.el file with which I can 
reproduce the issue:

----------------------------------------------
$ cat .emacs.d/init.el

(when (>= emacs-major-version 24)
   (require 'package)
   (package-initialize))

(require 'tabbar-ruler)
----------------------------------------------

Commenting out the line "(require 'tabbar-ruler)", the crash does not 
occur. Also starting Emacs with "-Q" option does not give the crash.

It seems, I cannot reproduce the crash on other systems (GNU/Linux, macOS)

This crash occurs only with April builds (and on Windows). I cannot 
reproduce the crash (also with a full init.el file) with builds I did, 
for example, in March (<= 20170327, r128789.8ce827426e-1)

I wonder if someone could reproduce the crash.. Mayebe one need to try 
few times so see the crash. Usually it occurs regularly.

Below [2] there is what I got following the suggestions of the crash 
window. Please, notice that I have some reluctance (i.e., _repulsion_) 
to use debuggers..

Ciao, Angelo.

-----
[1] Builds on Win 10 15063.138, on MSYS2/MinGW64:

./autogen.sh
./configure --prefix=/c/LocalApps/Emacs
make -j3
...

[2] $ gdb -p 5424
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 5424
[New Thread 5424.0x1f44]
[New Thread 5424.0x1a58]
[New Thread 5424.0x1360]
[New Thread 5424.0xab0]
[New Thread 5424.0x1e4c]
Reading symbols from C:\LocalApps\Emacs\bin\emacs.exe...done.
(gdb) continue
Continuing.
[Thread 5424.0x1e4c exited with code 0]

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 5424.0x1f44]
0x00007ff9e93ca963 in KERNELBASE!DebugBreak ()
    from C:\WINDOWS\System32\KernelBase.dll
(gdb) bt
#0  0x00007ff9e93ca963 in KERNELBASE!DebugBreak ()
    from C:\WINDOWS\System32\KernelBase.dll
#1  0x0000000400180078 in emacs_abort () at w32fns.c:10875
#2  0x00000004000acd89 in terminate_due_to_signal (sig=11,
     backtrace_limit=<optimized out>) at emacs.c:393
#3  0x00000004000c4b5e in handle_fatal_signal (sig=13708528, sig@entry=11)
     at sysdep.c:1714
#4  0x00000004000c593c in deliver_thread_signal (sig=11,
     handler=0x4000c4b50 <handle_fatal_signal>) at sysdep.c:1688
#5  0x00000004001d2468 in _gnu_exception_handler (exception_data=0xbfd580)
     at 
C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
#6  0x00007ff9ec2f6476 in ntdll!__C_specific_handler ()
    from C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x00007ff9ec30a08d in ntdll!.chkstk () from 
C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00007ff9ec279c58 in ntdll!RtlLookupFunctionEntry ()
    from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x00007ff9ec30910e in ntdll!KiUserExceptionDispatcher ()
    from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x000000040018f043 in w32_mouse_position (fp=0xbfe3b0, insist=-1,
     bar_window=0xbfe3b8, part=0xbfe3a8, x=<optimized out>, y=<optimized 
out>,
     time=<optimized out>) at w32term.c:3505
#11 0x000000040000acfc in Fmouse_pixel_position () at frame.c:2082
#12 0x000000040011dcd2 in Ffuncall (nargs=nargs@entry=1,
     args=args@entry=0xbfe468) at eval.c:2742
#13 0x0000000400153312 in exec_byte_code (bytestr=<optimized out>,
     vector=74897728, maxdepth=<optimized out>,
     args_template=args_template@entry=0, nargs=nargs@entry=0,
     args=<optimized out>, args@entry=0x0) at bytecode.c:641
#14 0x000000040011d86a in funcall_lambda (fun=17190255061,
     nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfe8e0) at 
eval.c:3020
#15 0x000000040011dc4b in Ffuncall (nargs=nargs@entry=1,
     args=args@entry=0xbfe8d8) at eval.c:2756
#16 0x000000040011f74c in Fapply (nargs=2, args=0xbfe8d8) at eval.c:2326
#17 0x000000040011dcd2 in Ffuncall (nargs=nargs@entry=3,
     args=args@entry=0xbfe8d0) at eval.c:2742
#18 0x0000000400153312 in exec_byte_code (bytestr=<optimized out>, 
vector=-3,
     maxdepth=<optimized out>, args_template=args_template@entry=1030,
     nargs=nargs@entry=1, args=<optimized out>, args@entry=0xbfebf8)
     at bytecode.c:641
#19 0x000000040011d980 in funcall_lambda (fun=17183382013,
     nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfebf8) at 
eval.c:2942
#20 0x000000040011dc4b in Ffuncall (nargs=nargs@entry=2,
     args=args@entry=0xbfebf0) at eval.c:2756
#21 0x000000040011dd8d in call1 (fn=fn@entry=59640, 
arg1=arg1@entry=74563637)
     at eval.c:2604
#22 0x00000004000b3945 in timer_check_2 (idle_timers=<optimized out>,
     timers=<optimized out>) at keyboard.c:4467
#23 timer_check () at keyboard.c:4529
#24 0x00000004000b3dfa in readable_events (flags=1) at keyboard.c:3345
#25 0x00000004000b46a5 in get_input_pending (flags=flags@entry=1)
     at keyboard.c:6799
#26 0x00000004000b6a70 in detect_input_pending_run_timers (
     do_display=do_display@entry=false) at keyboard.c:9926
#27 0x00000004000b7873 in read_char (commandflag=160, commandflag@entry=1,
     map=1, map@entry=75372707, prev_event=17207923560,
     used_mouse_menu=0x1f00000000, used_mouse_menu@entry=0xbff45b,
     end_time=end_time@entry=0x0) at keyboard.c:2734
#28 0x00000004000b9cb3 in read_key_sequence (keybuf=keybuf@entry=0xbff5b0,
     prompt=prompt@entry=0, 
dont_downcase_last=dont_downcase_last@entry=false,
     can_return_switch_frame=can_return_switch_frame@entry=true,
     fix_current_buffer=fix_current_buffer@entry=true,
     prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
     at keyboard.c:9122
#29 0x00000004000bb833 in command_loop_1 () at keyboard.c:1370
#30 0x000000040011c1fd in internal_condition_case (
     bfun=bfun@entry=0x4000bb5e0 <command_loop_1>,
     handlers=handlers@entry=23408, hfun=hfun@entry=0x4000b2c30 <cmd_error>)
     at eval.c:1324
#31 0x00000004000ad3e4 in command_loop_2 (ignore=<optimized out>)
     at keyboard.c:1112
#32 0x000000040011c18b in internal_catch (tag=tag@entry=60368,
     func=func@entry=0x4000ad3c0 <command_loop_2>, arg=arg@entry=0)
     at eval.c:1091
#33 0x00000004000ad397 in command_loop () at keyboard.c:1091
#34 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) q
A debugging session is active.

         Inferior 1 [process 5424] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: C:\LocalApps\Emacs\bin\emacs.exe, Pid 5424

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Sun, 23 Apr 2017 00:38:22 +0200
> 
> My Emacs builds [1] from master, I did in April, crash when PC is 
> suspended and then waked up.

Can you tell what does "suspended" mean, exactly?  How is your laptop
configured for this -- is this hibernation or sleep?  Does it matter,
or does the problem happen in both cases?

Thanks.

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Angelo Graziosi]

Il 23/04/2017 04:36, Eli Zaretskii ha scritto:
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Sun, 23 Apr 2017 00:38:22 +0200
>>
>> My Emacs builds [1] from master, I did in April, crash when PC is
>> suspended and then waked up.
> 
> Can you tell what does "suspended" mean, exactly?  How is your laptop
> configured for this -- is this hibernation or sleep?  Does it matter,
> or does the problem happen in both cases?

Even if I discovered the crash with the little notebook (2 in 1, 
transformer book), all my report is based on the results I got with PC, 
the desktop.

On Win10, when you click on Start and then on the Stop button, you have 
3 elements:

Sospendi (Suspend ?)
Arresta il sistema (Stop the system)
Riavvia il sistema (Reboot the system)

Now I am not sure as "Sospendi" is in English. It is some more of 
"Sleep" because when I click "Sospendi" the led flagging that the PC is 
"switched on" bilinks and to resume the PC I have to type on keyboard 
(moving the mouse does nothing). The the scanner is reactivated and I 
have to relogin. I would say it is an hibernation.

When the PC is sleeping, moving the mouse is enough to wake up it and I 
don't need to relogin, and it seems that Emacs does not crash...

Thanks,
  Angelo.

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Sun, 23 Apr 2017 00:38:22 +0200
> 
> This crash occurs only with April builds (and on Windows). I cannot 
> reproduce the crash (also with a full init.el file) with builds I did, 
> for example, in March (<= 20170327, r128789.8ce827426e-1)

Martin, this seems to be due to your changes in 3fdd3bb56.  Could you
please take a look?

The crash is here:

	if (f1)
	  {
	    /* Ok, we found a frame.  Store all the values.
	       last_mouse_glyph is a rectangle used to reduce the
	       generation of mouse events.  To not miss any motion
	       events, we must divide the frame into rectangles of the
	       size of the smallest character that could be displayed
	       on it, i.e. into the same rectangles that matrices on
	       the frame are divided into.  */

	    dpyinfo = FRAME_DISPLAY_INFO (f1);
	    ScreenToClient (FRAME_W32_WINDOW (f1), &pt);  <<<<<<<<<<<<<<<<<<<
	    remember_mouse_glyph (f1, pt.x, pt.y, &dpyinfo->last_mouse_glyph);
	    dpyinfo->last_mouse_glyph_frame = f1;

So maybe this has something to d with computing f1?

TIA

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[martin rudalics]

 > Martin, this seems to be due to your changes in 3fdd3bb56.  Could you
 > please take a look?
 >
 > The crash is here:
 >
 > 	if (f1)
 > 	  {
 > 	    /* Ok, we found a frame.  Store all the values.
 > 	       last_mouse_glyph is a rectangle used to reduce the
 > 	       generation of mouse events.  To not miss any motion
 > 	       events, we must divide the frame into rectangles of the
 > 	       size of the smallest character that could be displayed
 > 	       on it, i.e. into the same rectangles that matrices on
 > 	       the frame are divided into.  */
 >
 > 	    dpyinfo = FRAME_DISPLAY_INFO (f1);
 > 	    ScreenToClient (FRAME_W32_WINDOW (f1), &pt);  <<<<<<<<<<<<<<<<<<<
 > 	    remember_mouse_glyph (f1, pt.x, pt.y, &dpyinfo->last_mouse_glyph);
 > 	    dpyinfo->last_mouse_glyph_frame = f1;
 >
 > So maybe this has something to d with computing f1?

Likely.  But I have no idea what went wrong here.  cwfp could obviously
be a scroll bar window but then x_any_window_to_frame shouldn't have
accepted it.  I suppose neither of these

#6  0x00007ff9ec2f6476 in ntdll!__C_specific_handler ()
    from C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x00007ff9ec30a08d in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00007ff9ec279c58 in ntdll!RtlLookupFunctionEntry ()
    from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x00007ff9ec30910e in ntdll!KiUserExceptionDispatcher ()
    from C:\WINDOWS\SYSTEM32\ntdll.dll

would tell us much?  I tweaked the code a bit, maybe it helps.

Angelo please try with latest master.  If it crashes again we'll have to
dig further.

martin

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Angelo Graziosi]

Il 23/04/2017 11:16, martin rudalics ha scritto:
> Angelo please try with latest master.  If it crashes again we'll have to
> dig further.

I did and it seems I can't reproduce the crash any more!

Thank you!

Ciao,
Angelo.

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[npostavs]

tags 26615 fixed
close 26615 
quit

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Il 23/04/2017 11:16, martin rudalics ha scritto:
>> Angelo please try with latest master.  If it crashes again we'll have to
>> dig further.
>
> I did and it seems I can't reproduce the crash any more!

Closing as fixed then.

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Eli Zaretskii]

> Date: Sun, 23 Apr 2017 11:16:32 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 26615@debbugs.gnu.org
> 
> I tweaked the code a bit, maybe it helps.

Thanks.  However, this line looks wrong (and triggers a compiler
warning):

	    /* Try to check for a child window first.  */
	    HWND wfp = ChildWindowFromPoint (wfp, pt);

You are using wfp before it was initialized.

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[martin rudalics]

 > Thanks.  However, this line looks wrong (and triggers a compiler
 > warning):
 >
 > 	    /* Try to check for a child window first.  */
 > 	    HWND wfp = ChildWindowFromPoint (wfp, pt);
 >
 > You are using wfp before it was initialized.

Silly me.  I removed all embedded assignments now and hopefully fixed
that part too.  I still have no idea what may have caused the original
bug.

martin

bug#26615: Recent Emacs crashes when PC is suspended and using tabbar-ruler package

[Eli Zaretskii]

> Date: Wed, 26 Apr 2017 15:32:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: angelo.graziosi@alice.it, 26615@debbugs.gnu.org
> 
>  > 	    /* Try to check for a child window first.  */
>  > 	    HWND wfp = ChildWindowFromPoint (wfp, pt);
>  >
>  > You are using wfp before it was initialized.
> 
> Silly me.  I removed all embedded assignments now and hopefully fixed
> that part too.

Thanks, it did.