Crashes on w32 and debugging

Crashes on w32 and debugging

[Lennart Borgman (gmail)]

I currently get a lot of crashes with my slightly patched Emacs on 
Windows XP Pro:

   GNU Emacs 23.0.50.1 (i386-mingw-nt5.1.2600) of 2008-01-30 (patched)

I guess they are related to starting either Firefox or Freemind (java) 
from within Emacs, but I am not sure.

Debugging would perhaps help, but when Emacs crashes I just get a 
message that asks me if I want to send a bug report to Microsoft.

I am configuring with

   configure --with-gcc --cflags

and compiling with gcc.

I looked in the documentation for how to start Emacs under gdb, but I 
can't find anything about it in nt/INSTALL.

Re: Crashes on w32 and debugging

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> I looked in the documentation for how to start Emacs under gdb, but I 
> can't find anything about it in nt/INSTALL.

1. Rebuild emacs after configure --no-opt (with optimisations on, 
stepping through the code doesn't always act as you expect it, and some 
variables cannot be inspected). 

2. cd ${emacs}/src          (where ${emacs} is your checkout directory). 
This serves two purposes - it makes it easy for gdb to find the emacs 
sources, and it also loads the .gdbinit in that directory, which defines 
some useful functions for looking at Lisp variables and backtraces.

3. gdb oo/i386/emacs.exe

4. Set any breakpoints using "break function_name" or "break 
file.c:linenumber"

5. run -Q

6. After the breakpoint is hit, step over functions with "next"/"n", or 
step in with "step"/"s". Inspect C variables with "print VARIABLE", if 
it is a lisp variable, "pr" immediately after the print will print its 
lisp value. "bt" will get a backtrace, including the Lisp backtrace as 
well as C.

Re: Crashes on w32 and debugging

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> I looked in the documentation for how to start Emacs under gdb, but I 
>> can't find anything about it in nt/INSTALL.
> 
> 1. Rebuild emacs after configure --no-opt (with optimisations on, 
> stepping through the code doesn't always act as you expect it, and some 
> variables cannot be inspected).

Thanks Jason, but I need a little clarification. After configure I 
suppose I should do only "make bootstrap", but not "make install", or?

> 2. cd ${emacs}/src          (where ${emacs} is your checkout directory). 
> This serves two purposes - it makes it easy for gdb to find the emacs 
> sources, and it also loads the .gdbinit in that directory, which defines 
> some useful functions for looking at Lisp variables and backtraces.
> 
> 3. gdb oo/i386/emacs.exe
> 
> 4. Set any breakpoints using "break function_name" or "break 
> file.c:linenumber"
> 
> 5. run -Q

I just started testing this, but with just "run". The crashes are 
intermittent so I have to just use it for a while.

> 6. After the breakpoint is hit, step over functions with "next"/"n", or 
> step in with "step"/"s". Inspect C variables with "print VARIABLE", if 
> it is a lisp variable, "pr" immediately after the print will print its 
> lisp value. "bt" will get a backtrace, including the Lisp backtrace as 
> well as C.

Should not these instructions go into nt/INSTALL or somewhere else?

Re: Crashes on w32 and debugging

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Thanks Jason, but I need a little clarification. After configure I 
> suppose I should do only "make bootstrap", but not "make install", or? 
Just make should be enough - the .elc files will not be affected by C 
optimisations.

Re: Crashes on w32 and debugging

[Stefan Monnier]

>>> I looked in the documentation for how to start Emacs under gdb, but
>>> I can't find anything about it in nt/INSTALL.
>> 
>> 1. Rebuild emacs after configure --no-opt (with optimisations on, stepping
>> through the code doesn't always act as you expect it, and some variables
>> cannot be inspected).

> Thanks Jason, but I need a little clarification. After configure I suppose
> I should do only "make bootstrap", but not "make install", or?

>> 2. cd ${emacs}/src          (where ${emacs} is your checkout
>> directory). This serves two purposes - it makes it easy for gdb to find
>> the emacs sources, and it also loads the .gdbinit in that directory, which
>> defines some useful functions for looking at Lisp variables
>> and backtraces.
>> 
>> 3. gdb oo/i386/emacs.exe
>> 
>> 4. Set any breakpoints using "break function_name" or "break
>> file.c:linenumber"
>> 
>> 5. run -Q

> I just started testing this, but with just "run". The crashes are
> intermittent so I have to just use it for a while.

>> 6. After the breakpoint is hit, step over functions with "next"/"n", or
>> step in with "step"/"s". Inspect C variables with "print VARIABLE", if it
>> is a lisp variable, "pr" immediately after the print will print its lisp
>> value. "bt" will get a backtrace, including the Lisp backtrace as well
>> as C.

> Should not these instructions go into nt/INSTALL or somewhere else?

Maybe not in INSTALL, but adding such information to etc/DEBUG would
probably be helpful,


        Stefan

Re: Crashes on w32 and debugging

[Eli Zaretskii]

> Date: Thu, 28 Feb 2008 09:30:51 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> 
> I looked in the documentation for how to start Emacs under gdb, but I 
> can't find anything about it in nt/INSTALL.

That's because starting Emacs under GDB is no different from starting
any other program under GDB.  The only significant difference is
documented at the beginning of etc/DEBUG:

    ** When you debug Emacs with GDB, you should start it in the directory
    where the executable was made.  That directory has a .gdbinit file
    that defines various "user-defined" commands for debugging Emacs.
    (These commands are described below under "Examining Lisp object
    values" and "Debugging Emacs Redisplay problems".)

Re: Crashes on w32 and debugging

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 28 Feb 2008 21:02:13 -0500
> Cc: Emacs Devel <emacs-devel@gnu.org>, Jason Rumney <jasonr@gnu.org>
> 
> > Should not these instructions go into nt/INSTALL or somewhere else?
> 
> Maybe not in INSTALL, but adding such information to etc/DEBUG would
> probably be helpful,

etc/DEBUG already says that.

Re: Crashes on w32 and debugging

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Thanks Jason, but I need a little clarification. After configure I 
>> suppose I should do only "make bootstrap", but not "make install", or? 
> Just make should be enough - the .elc files will not be affected by C 
> optimisations.

Now I got a crash. Could you please tell me what to examine and how to 
do it?

I am starting to wonder if the problem happens during a call to 
yes-or-no-p in a timer. I have a little library pause.el that does such 
calls to chase me away from the keyboard.



Here are some messages I see before the crash:

  warning: obscured frame 02ECF000 ( *Minibuf-1* - Emacs) found to be 
visible

  warning: msg c113 not expected by w32_msg_pump

  warning: frame 02ECF000 (freemind.el - Emacs) obscured

  warning: msg c113 not expected by w32_msg_pump

  warning: obscured frame 02ECF000 (freemind.el - Emacs) found to be visible

  warning: msg c113 not expected by w32_msg_pump

  warning: msg c113 not expected by w32_msg_pump

  warning: msg c113 not expected by w32_msg_pump

  warning: frame 02ECF000 (freemind.el - Emacs) obscured


  Program received signal SIGSEGV, Segmentation fault.
  0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at 
xdisp.c:6063
  6063      if (INTEGERP (*it->dpvec)
  (gdb)




Here is a backtrace:

(gdb) bt
#0  0x0103a4ef in next_element_from_display_vector (it=0x82dbe0)
     at xdisp.c:6063
#1  0x01039585 in get_next_display_element (it=0x82dbe0) at xdisp.c:5590
#2  0x0104f914 in display_line (it=0x82dbe0) at xdisp.c:16113
#3  0x01049b30 in try_window (window=37262852, pos={charpos = 1, bytepos 
= 1},
     check_margins=1) at xdisp.c:13692
#4  0x010489a8 in redisplay_window (window=37262852, just_this_one_p=0)
     at xdisp.c:13310
#5  0x01044dbc in redisplay_window_0 (window=37262852) at xdisp.c:11901
#6  0x01020837 in internal_condition_case_1 (
     bfun=0x1044d8a <redisplay_window_0>, arg=37262852, handlers=23811365,
     hfun=0x1044d69 <redisplay_window_error>) at eval.c:1542
#7  0x01044d59 in redisplay_windows (window=37262852) at xdisp.c:11880
#8  0x01043de6 in redisplay_internal (preserve_echo_area=1) at xdisp.c:11437
#9  0x010446e3 in redisplay_preserve_echo_area (from_where=7) at 
xdisp.c:11688
#10 0x0100b645 in swallow_events (do_display=1) at keyboard.c:4453
#11 0x010b3caa in sit_for (timeout=240, reading=1, do_display=1)
     at dispnew.c:6573
#12 0x01008fb2 in read_char (commandflag=1, nmaps=17, maps=0x82f040,
     prev_event=23828481, used_mouse_menu=0x82f19c, end_time=0x0)
     at keyboard.c:2966
#13 0x01012302 in read_key_sequence (keybuf=0x82f300, bufsize=30,
     prompt=23828481, dont_downcase_last=0, can_return_switch_frame=1,
---Type <return> to continue, or q <return> to quit---
     fix_current_buffer=1) at keyboard.c:9457
#14 0x010062aa in command_loop_1 () at keyboard.c:1655
#15 0x01020727 in internal_condition_case (bfun=0x1005f6f <command_loop_1>,
     handlers=23901353, hfun=0x100599d <cmd_error>) at eval.c:1494
#16 0x01005cf8 in command_loop_2 () at keyboard.c:1370
#17 0x01020218 in internal_catch (tag=23930001,
     func=0x1005cd5 <command_loop_2>, arg=23828481) at eval.c:1230
#18 0x01005c5d in command_loop () at keyboard.c:1335
#19 0x010055b9 in recursive_edit_1 () at keyboard.c:958
#20 0x010dbd65 in read_minibuf (map=23816653, initial=23828481,
     prompt=37612675, backup_n=0, expflag=0, histvar=23895881, histpos=0,
     defalt=23828481, allow_props=0, inherit_input_method=0) at 
minibuf.c:757
#21 0x010ddb18 in Fcompleting_read (prompt=37612675, collection=23830532,
     predicate=23930049, require_match=23828529, initial_input=23828481,
     hist=23895881, def=23828481, inherit_input_method=23828481)
     at minibuf.c:1830
#22 0x01014543 in Fexecute_extended_command (prefixarg=23828481)
     at keyboard.c:10471
#23 0x01022ba2 in Ffuncall (nargs=2, args=0x82f8b0) at eval.c:3025
#24 0x0115498b in Fcall_interactively (function=23893545,
     record_flag=23828481, keys=23896068) at callint.c:842
#25 0x01022bf6 in Ffuncall (nargs=4, args=0x82fb30) at eval.c:3031
#26 0x0102278e in call3 (fn=23958625, arg1=23893545, arg2=23828481,
---Type <return> to continue, or q <return> to quit---
     arg3=23828481) at eval.c:2851
#27 0x010143d6 in Fcommand_execute (cmd=23893545, record_flag=23828481,
     keys=23828481, special=23828481) at keyboard.c:10411
#28 0x0100729b in command_loop_1 () at keyboard.c:1910
#29 0x01020727 in internal_condition_case (bfun=0x1005f6f <command_loop_1>,
     handlers=23901353, hfun=0x100599d <cmd_error>) at eval.c:1494
#30 0x01005cf8 in command_loop_2 () at keyboard.c:1370
#31 0x01020218 in internal_catch (tag=23893329,
     func=0x1005cd5 <command_loop_2>, arg=23828481) at eval.c:1230
#32 0x01005cae in command_loop () at keyboard.c:1349
#33 0x010055b9 in recursive_edit_1 () at keyboard.c:958
#34 0x0100571d in Frecursive_edit () at keyboard.c:1020
#35 0x0100270d in main (argc=3, argv=0xa82788) at emacs.c:1743
#36 0x0100124b in __mingw_CRTStartup ()
#37 0x01001298 in mainCRTStartup ()

Lisp Backtrace:
"execute-extended-command" (0x82f8b4)
"call-interactively" (0x82fb34)
(gdb)

Re: Crashes on w32 and debugging

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Now I got a crash. Could you please tell me what to examine and how to 
> do it?


 Program received signal SIGSEGV, Segmentation fault.
 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at 
xdisp.c:6063
 6063      if (INTEGERP (*it->dpvec)


Start by examining the C variables around the point where it crashes, 
looking for any obvious problems like null pointers. The "print" command 
will print values, as I wrote in my previous mail. A good start would be:

print it
print it->dpvec
print *it->dpvec

Re: Crashes on w32 and debugging

[Jason Rumney]

> Program received signal SIGSEGV, Segmentation fault.
> 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at 
> xdisp.c:6063
> 6063      if (INTEGERP (*it->dpvec)

You might want to do a cvs update before spending too much time 
debugging this, as I can't find any such line in the latest version of 
xdisp.c. Perhaps the bug has already been fixed.

Re: Crashes on w32 and debugging

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at 
>> xdisp.c:6063
>> 6063      if (INTEGERP (*it->dpvec)
> 
> You might want to do a cvs update before spending too much time 
> debugging this, as I can't find any such line in the latest version of 
> xdisp.c. Perhaps the bug has already been fixed.

Thanks, I will have to think about what to do. I do not have the crashed 
session available any more (I had to reboot).

Re: Crashes on w32 and debugging

[Eli Zaretskii]

> Date: Fri, 29 Feb 2008 22:59:21 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: Emacs Devel <emacs-devel@gnu.org>
> 
> Here are some messages I see before the crash:
> 
>   warning: obscured frame 02ECF000 ( *Minibuf-1* - Emacs) found to be 
> visible
> 
>   warning: msg c113 not expected by w32_msg_pump
> 
>   warning: frame 02ECF000 (freemind.el - Emacs) obscured
> 
>   warning: msg c113 not expected by w32_msg_pump
> 
>   warning: obscured frame 02ECF000 (freemind.el - Emacs) found to be visible
> 
>   warning: msg c113 not expected by w32_msg_pump
> 
>   warning: msg c113 not expected by w32_msg_pump
> 
>   warning: msg c113 not expected by w32_msg_pump
> 
>   warning: frame 02ECF000 (freemind.el - Emacs) obscured

Jason, could it be that this "msg c113 not expected" thing is
something to worry about?

Re: Crashes on w32 and debugging

[Jason Rumney]

Eli Zaretskii wrote:
> Jason, could it be that this "msg c113 not expected" thing is
> something to worry about?
>   

No. I've tracked these messages down to IME and third party extensions 
(such as virus scanners) that either broadcast or hook into every 
application and send messages from the RegisterWindowMessage range to 
themselves via any Window the application has created. I think this 
debugging statement can be disabled now, it is probably left over from 
early development when private messages were being created for Emacs' 
use and the developers wanted to double check that they were handling 
all the messages they had created.

Re: Crashes on w32 and debugging

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at 
>> xdisp.c:6063
>> 6063      if (INTEGERP (*it->dpvec)
> 
> You might want to do a cvs update before spending too much time 
> debugging this, as I can't find any such line in the latest version of 
> xdisp.c. Perhaps the bug has already been fixed.

I just got a new crash, but unfortunately not running under the 
debugger. However this crash happened after working mostly in org-mode 
(I had not started any external programs from Emacs this time).

I had been using occur quite a lot in the org-mode buffer. I always 
start it from isearch.

Remember that the crash when running under the debugger was a SIGSEV in 
next_element_from_display_vector.

To avoid confusion I say again that that this is

  GNU Emacs 23.0.50.1 (i386-mingw-nt5.1.2600) of 2008-01-30 (patched)

Re: Crashes on w32 and debugging

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at 
>>> xdisp.c:6063
>>> 6063      if (INTEGERP (*it->dpvec)
>>
>> You might want to do a cvs update before spending too much time 
>> debugging this, as I can't find any such line in the latest version of 
>> xdisp.c. Perhaps the bug has already been fixed.
> 
> I just got a new crash, but unfortunately not running under the 
> debugger. However this crash happened after working mostly in org-mode 
> (I had not started any external programs from Emacs this time).
> 
> I had been using occur quite a lot in the org-mode buffer. I always 
> start it from isearch.
> 
> Remember that the crash when running under the debugger was a SIGSEV in 
> next_element_from_display_vector.
> 
> To avoid confusion I say again that that this is
> 
>  GNU Emacs 23.0.50.1 (i386-mingw-nt5.1.2600) of 2008-01-30 (patched)

Switched to run under gdb and immediately got a new crash. As above 
working in an org-mode buffer. I had just used occur and then I typed 
`C-x 1'. That operation was never made (ie the frame was still divided 
when I switched to the debugger. (Not sure however if the crash actually 
happened before `C-x 1' or after.)

Here are some data as suggested by Jason before:

Program received signal SIGSEGV, Segmentation fault.
0x0103a4ef in next_element_from_display_vector (it=0x82e5d0) at xdisp.c:6063
6063      if (INTEGERP (*it->dpvec)
(gdb) print it
$1 = (struct it *) 0x82e5d0
(gdb) print it->dpvec
$2 = (Lisp_Object *) 0x0
(gdb) print *it->dpvec
Cannot access memory at address 0x0
(gdb)

Re: Crashes on w32 and debugging

[Kim F. Storm]

>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at
>>>> xdisp.c:6063
>>>> 6063      if (INTEGERP (*it->dpvec)
>>>
>>> You might want to do a cvs update before spending too much time
>>> debugging this, as I can't find any such line in the latest version
>>> of xdisp.c. Perhaps the bug has already been fixed.

Hi Lennart,

Like Jason, I don't see that line in the current sources.

Can you pls. make a diff between your local xdisp.c and CVS
to see if that is a local change...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Crashes on w32 and debugging

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x0103a4ef in next_element_from_display_vector (it=0x82dbe0) at
>>>>> xdisp.c:6063
>>>>> 6063      if (INTEGERP (*it->dpvec)
>>>> You might want to do a cvs update before spending too much time
>>>> debugging this, as I can't find any such line in the latest version
>>>> of xdisp.c. Perhaps the bug has already been fixed.
> 
> Hi Lennart,
> 
> Like Jason, I don't see that line in the current sources.
> 
> Can you pls. make a diff between your local xdisp.c and CVS
> to see if that is a local change...

Thanks Kim, I looked at the diff that was made when I built that 
emacs.exe and there was no patches to xdisp.c. However it looks like 
there are a lot of changes to CVS xdisp.c after that.

So I will take Jasons advice and rebuild Emacs with a fresh checkout (+ 
my patches, none of them in xdisp.c -- can't patch that since I do not 
understand anything there) and see if the problem is gone.