GNU bug report logs - #11367
24.0.95.1 Crash: Windows 7 using egg

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11367 in the body.
You can then email your comments to 11367 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.95.1 Crash: Windows 7 using egg
Date: Fri, 27 Apr 2012 15:03:51 -0500

[Message part 1 (text/plain, inline)]

I can pretty consistently crash 24.0.95.1 (and could some previous
pre-releases).

Since I am on Windows, I'm not sure how to help debug this.  How can I
generate a useful stack trace for this?

The step that crashes is to add a new file to egg (the emacs git interface).

The steps to reproduce are:
 * Create an empty repository.
 * Create file1, add, and commit with our without egg.
 * Create 2 new files.
 * Run egg-status on the directory which will show 2 untracked files.
 * Put the cursor on the first untracked file and press 's' to stage it.

After the crash, the file is staged, so the error is probably during the
refresh of the status, but I am not sure.

Is there anything else I can do to test this?

I'm using msysgit: git version 1.7.7.msysgit.1

I am an admin on this box.

The information from report-emacs-bug (which I can't use because I can't
send email from it) is below.  Note that the recent input is not useful
since this is a new instance.

In GNU Emacs 24.0.95.1 (i386-mingw-nt6.1.7601)
 of 2012-04-02 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  iswitchb-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  icomplete-mode: t
  global-auto-revert-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  unify-8859-on-decoding-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x v e r s i o n <return> M-x r e p o r t - e m <tab>
<return>

Recent messages:
Loading ~/.emacs.d/init-05-cmode...done
Loading ~/.emacs.d/init-05-dired...done
Loading ~/.emacs.d/init-05-python...done
Loading ~/.emacs.d/init-05-sql...done
Loading ~/.emacs.d/init-07-compilation...done
Loading ~/.emacs.d/init-07-modes...done
Loading ~/.emacs.d/init-09-bindings...done
Loading c:/Users/Michael/.emacs.d/init-99-local.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
GNU Emacs 24.0.95.1 (i386-mingw-nt6.1.7601) of 2012-04-02 on MARVIN

Load-path shadows:
~/.emacs.d/custom hides c:/bin/emacs/lisp/custom
~/.emacs.d/misc/python hides c:/bin/emacs/lisp/progmodes/python

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums
mail-utils server windmove tramp tramp-compat auth-source eieio byte-opt
bytecomp byte-compile
cconv macroexp assoc gnus-util mm-util mail-prsvr password-cache shell
pcomplete format-spec
tramp-loaddefs ack-emacs thingatpt egg edmacro kmacro derived diff-mode
easy-mmode ffap
ediff-merg ediff-diff ediff-wind ediff-help ediff-util ediff-mult
ediff-init ediff electric cl
python-21 python dired-x easymenu dired compile comint regexp-opt
ansi-color ring undo-tree
uniquify iswitchb avoid cua-base browse-kill-ring+ browse-kill-ring advice
help-fns
advice-preload whitespace align2 align icomplete+ which-func imenu paren
icomplete autorevert
cus-start cus-load time-date tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32
disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe
lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet
lao korean japanese
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese case-table
epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files
text-properties overlay sha1 md5 base64 format env code-pages mule custom
widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

Michael Kleehammer

[Message part 2 (text/html, inline)]

Message #8 received at 11367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>
Cc: 11367 <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 10:13:54 +0300

> From: Michael Kleehammer <michael <at> kleehammer.com>
> Date: Fri, 27 Apr 2012 15:03:51 -0500
> 
> I can pretty consistently crash 24.0.95.1 (and could some previous
> pre-releases).
> 
> Since I am on Windows, I'm not sure how to help debug this.  How can I
> generate a useful stack trace for this?

Like this:

 . Download and install a MinGW build of GDB (you can find it here:

     http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/GDB-7.4/gdb-7.4-2-mingw32-bin.tar.lzma/download

 . From the Emacs source repository, download the file .gdbinit,
   available here:

     http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/src/.gdbinit

 . Start GDB from the shell prompt in the same directory where you put
   .gdbinit, like this:

    gdb /path/to/emacs.exe

 . When GDB starts and displays its prompt, run emacs:

    (gdb) run

 . Perform the steps to reproduce the problem.  When Emacs crashes (or
   aborts, see below), GDB will kick in, and you can type the
   backtrace command:

    (gdb) bt full

 . Post here the backtrace.  Keep the crashed session running, because
   we might ask you to find out more by using additional GDB commands.

> The step that crashes is to add a new file to egg (the emacs git interface).
> 
> The steps to reproduce are:
>  * Create an empty repository.
>  * Create file1, add, and commit with our without egg.
>  * Create 2 new files.
>  * Run egg-status on the directory which will show 2 untracked files.
>  * Put the cursor on the first untracked file and press 's' to stage it.

Is it a crash or an abort?  In the latter case, Emacs displays an
"Emacs Abort Dialog", telling that a fatal error has occurred and
asking you whether you'd like to attach a debugger.

Also, is the above reproducible from "emacs -Q"?

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 09:55:42 -0500

First, thanks for the helpful response.  Also, I hope the mailing
recognizes the subject line
and isn't looking for the reply header.  I apologize in advance if
this opens a new report.

> Post here the backtrace.  Keep the crashed session running, because
> we might ask you to find out more by using additional GDB commands.

(gdb) bt
#0  0x759c280d in KERNELBASE!DeleteAce () from
C:\Windows\syswow64\KernelBase.dll
#1  0x0114f32a in w32_abort () at w32fns.c:7210
#2  0x011d6e49 in pos_visible_p (w=0x3600800, charpos=462, x=0x88e2f8,
y=0x88e2f4, rtop=0x88e308, rbot=0x88e304, rowh=0x88e300,
vpos=0x88e2fc) at xdisp.c:1460
#3  0x011bbc90 in Fpos_visible_in_window_p (pos=54736922,
window=56625157, partially=54736946) at window.c:1457
#4  0x010226e3 in Fposn_at_point (pos=54736922, window=56625157) at
keyboard.c:11373
#5  0x01036ce9 in Ffuncall (nargs=1, args=0x88e444) at eval.c:3005
#6  0x010dec82 in exec_byte_code (bytestr=57709329, vector=57737349,
maxdepth=20, args_template=54736922, nargs=0, args=0x0) at
bytecode.c:785
#7  0x01037b9c in funcall_lambda (fun=56330469, nargs=0,
arg_vector=0x343381a) at eval.c:3233
#8  0x01037082 in Ffuncall (nargs=1, args=0x88e740) at eval.c:3051
#9  0x010dec82 in exec_byte_code (bytestr=57708833, vector=59670533,
maxdepth=16, args_template=54736922, nargs=0, args=0x0) at
bytecode.c:785
#10 0x01037b9c in funcall_lambda (fun=56329733, nargs=1,
arg_vector=0x343381a) at eval.c:3233
#11 0x01037082 in Ffuncall (nargs=2, args=0x88ea30) at eval.c:3051
#12 0x010dec82 in exec_byte_code (bytestr=57709569, vector=59674373,
maxdepth=12, args_template=54736922, nargs=0, args=0x0) at
bytecode.c:785
#13 0x01037b9c in funcall_lambda (fun=56348229, nargs=0,
arg_vector=0x343381a) at eval.c:3233
#14 0x01037082 in Ffuncall (nargs=1, args=0x88ee34) at eval.c:3051
#15 0x0103543b in Fapply (nargs=2, args=0x88ee34) at eval.c:2450
#16 0x01036a00 in Ffuncall (nargs=3, args=0x88ee30) at eval.c:2984
#17 0x010dec82 in exec_byte_code (bytestr=20761657, vector=20761709,
maxdepth=16, args_template=54736922, nargs=0, args=0x0) at
bytecode.c:785
#18 0x010de220 in Fbyte_code (bytestr=20761657, vector=20761709,
maxdepth=16) at bytecode.c:423
#19 0x01034ebc in eval_sub (form=20761646) at eval.c:2356
#20 0x01032b6d in internal_lisp_condition_case (var=54736922,
bodyform=20761646, handlers=20011046) at eval.c:1469
#21 0x010df6a7 in exec_byte_code (bytestr=20761401, vector=20761533,
maxdepth=20, args_template=54736922, nargs=0, args=0x0) at
bytecode.c:981
#22 0x01037b9c in funcall_lambda (fun=20761373, nargs=1,
arg_vector=0x343381a) at eval.c:3233
#23 0x01037082 in Ffuncall (nargs=2, args=0x88f4f8) at eval.c:3051
#24 0x010361f9 in call1 (fn=54782218, arg1=59674309) at eval.c:2771
#25 0x0100e1de in timer_check_2 () at keyboard.c:4465
#26 0x0100e24f in timer_check () at keyboard.c:4511
#27 0x0100bfba in readable_events (flags=1) at keyboard.c:3392
#28 0x01014a63 in get_input_pending (addr=0x1653000, flags=1) at keyboard.c:6741
#29 0x0102042f in detect_input_pending_run_timers (do_display=1) at
keyboard.c:10508
#30 0x0104ba3c in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54736922,
wait_proc=0x0, just_wait_proc=0)
    at process.c:4733
#31 0x010f8b12 in sit_for (timeout=120, reading=1, do_display=1) at
dispnew.c:6063
#32 0x0100924d in read_char (commandflag=1, nmaps=6, maps=0x88f970,
prev_event=54736922, used_mouse_menu=0x88fa58, end_time=0x0) at
keyboard.c:2692
#33 0x0101c26d in read_key_sequence (keybuf=0x88fbd4, bufsize=30,
prompt=54736922, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1)
    at keyboard.c:9328
#34 0x01005c93 in command_loop_1 () at keyboard.c:1449
#35 0x01032c4f in internal_condition_case (bfun=0x100569b
<command_loop_1>, handlers=54794698, hfun=0x1004eba <cmd_error>) at
eval.c:1515
#36 0x010052f7 in command_loop_2 (ignore=54736922) at keyboard.c:1160
#37 0x01032672 in internal_catch (tag=54792698, func=0x10052d3
<command_loop_2>, arg=54736922) at eval.c:1272
#38 0x010052b3 in command_loop () at keyboard.c:1139
#39 0x0100488f in recursive_edit_1 () at keyboard.c:759
#40 0x01004baa in Frecursive_edit () at keyboard.c:823
#41 0x010028b5 in main (argc=1, argv=0x8e2d98) at emacs.c:1715
(gdb)

> Is it a crash or an abort?  In the latter case, Emacs displays an
> "Emacs Abort Dialog", telling that a fatal error has occurred and
> asking you whether you'd like to attach a debugger.

As you already know from the backtrace, it is an abort.  I've left it
open but it is easy to
reproduce if necessary.

> Also, is the above reproducible from "emacs -Q"?

Yes.

Michael Kleehammer

Message #14 received at 11367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>
Cc: 11367 <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 18:34:04 +0300

> From: Michael Kleehammer <michael <at> kleehammer.com>
> Date: Sat, 28 Apr 2012 09:55:42 -0500
> 
> First, thanks for the helpful response.  Also, I hope the mailing
> recognizes the subject line
> and isn't looking for the reply header.  I apologize in advance if
> this opens a new report.

No new bug report was created.

> (gdb) bt
> #0  0x759c280d in KERNELBASE!DeleteAce () from
> C:\Windows\syswow64\KernelBase.dll
> #1  0x0114f32a in w32_abort () at w32fns.c:7210
> #2  0x011d6e49 in pos_visible_p (w=0x3600800, charpos=462, x=0x88e2f8,
> y=0x88e2f4, rtop=0x88e308, rbot=0x88e304, rowh=0x88e300,
> vpos=0x88e2fc) at xdisp.c:1460

This is an assertion violation here:

		  /* Normally, we would exit the above loop because we
		     found the display element whose character
		     position is CHARPOS.  For the contingency that we
		     didn't, and stopped at the first newline from the
		     display string, move back over the glyphs
		     produced from the string, until we find the
		     rightmost glyph not from the string.  */
		  if (IT_CHARPOS (it3) != charpos && EQ (it3.object, string))
		    {
		      struct glyph *g = it3.glyph_row->glyphs[TEXT_AREA]
					+ it3.glyph_row->used[TEXT_AREA];

		      while (EQ ((g - 1)->object, string))
			{
			  --g;
			  top_x -= g->pixel_width;
			}
  >>>>>>>>>>>>>>      xassert (g < it3.glyph_row->glyphs[TEXT_AREA]
				    + it3.glyph_row->used[TEXT_AREA]);
		    }

Please show the result of the following commands:

 (gdb) frame 2
 (gdb) p g
 (gdb) p it3.glyph_row->glyphs[1] + it3.glyph_row->used[1]
 (gdb) p it3.current
 (gdb) p charpos
 (gdb) p it3.object
 (gdb) p (g-1)->object
 (gdb) pgrowx it3.glyph_row

If the "pgrowx" command doesn't work, load .gdbinit manually and try
again:

 (gdb) source .gdbinit
 (gdb) pgrowx it3.glyph_row

> #40 0x01004baa in Frecursive_edit () at keyboard.c:823
> #41 0x010028b5 in main (argc=1, argv=0x8e2d98) at emacs.c:1715
> (gdb)

There should have been a Lisp-level backtrace after this; didn't you
see it?  Perhaps that's because .gdbinit was not loaded (did you start
GDB from the same directory where you saved .gdbinit?), so try this:

 (gdb) source .gdbinit
 (gdb) xbacktrace

> > Also, is the above reproducible from "emacs -Q"?
> 
> Yes.

Then it would help to have a full recipe starting with "emacs -Q".

Thanks.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 11:32:10 -0500

Sorry for the delay.  It stopped aborting at exactly the same place,
on multiple machines, with
and without -Q.  I tried a lot of combinations and it seems that
adding one more step, a C-n, does it.

The abort is sporadic during development, but this seemed to do it
every time.  Perhaps it
isn't as certain as I thought.

On Sat, Apr 28, 2012 at 10:34 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

...

> Please show the result of the following commands:
>
>  (gdb) frame 2

#2  0x011d6e49 in pos_visible_p (w=0x3600800, charpos=462, x=0x88e2f8,
y=0x88e2f4, rtop=0x88e308, rbot=0x88e304, rowh=0x88e300,
vpos=0x88e2fc) at xdisp.c:1460
1460    xdisp.c: No such file or directory.

>  (gdb) p g

$1 = (struct glyph *) 0x4fd90fc

>  (gdb) p it3.glyph_row->glyphs[1] + it3.glyph_row->used[1]

$2 = (struct glyph *) 0x4fd90fc

>  (gdb) p it3.current

$3 = {
  pos = {
    charpos = 445,
    bytepos = 445
  },
  overlay_string_index = -1,
  string_pos = {
    charpos = 0,
    bytepos = 0
  },
  dpvec_index = -1
}

>  (gdb) p charpos

$4 = 462

>  (gdb) p it3.object

$5 = 84618657

>  (gdb) p (g-1)->object

$6 = 0

>  (gdb) pgrowx it3.glyph_row

TEXT: 7 glyphs
  0    0: CHAR[m] pos=1 blev=0,btyp=L w=14 a+d=16+5 face=19 MB
  1   14: CHAR[a] pos=2 blev=0,btyp=L w=8 a+d=16+5 face=19 MB
  2   22: CHAR[s] pos=3 blev=0,btyp=L w=7 a+d=16+5 face=19 MB
  3   29: CHAR[t] pos=4 blev=0,btyp=L w=6 a+d=16+5 face=19 MB
  4   35: CHAR[e] pos=5 blev=0,btyp=L w=8 a+d=16+5 face=19 MB
  5   43: CHAR[r] pos=6 blev=0,btyp=L w=6 a+d=16+5 face=19 MB
  6   49: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB


I'm impressed with your remote debugging ;)

>> #40 0x01004baa in Frecursive_edit () at keyboard.c:823
>> #41 0x010028b5 in main (argc=1, argv=0x8e2d98) at emacs.c:1715
>> (gdb)
>
> There should have been a Lisp-level backtrace after this; didn't you
> see it?  Perhaps that's because .gdbinit was not loaded (did you start
> GDB from the same directory where you saved .gdbinit?), so try this:
>
>  (gdb) source .gdbinit
>  (gdb) xbacktrace

My mistake.  I had to download mingw from scratch and install gdb,
etc. and forgot a step.

"posn-at-point" (0x88e448)
"mouse-avoidance-point-position" (0x88e744)
"mouse-avoidance-too-close-p" (0x88ea34)
"mouse-avoidance-fancy" (0x88ee38)
"apply" (0x88ee34)
"byte-code" (0x88f084)
"timer-event-handler" (0x88f4fc)

This original backtrace was without -Q, so the mouse avoidance setting
may be non-default.  Let me know if I should kill it and get a -Q
backtrace.

> Then it would help to have a full recipe starting with "emacs -Q".

* Download the egg library from https://github.com/bogolisk/egg

  I am using the latest version.

* Create new git repository in an empty directory:

  $ git init

* Create readme.txt with "1st line\n" and commit.

  $ git add readme.txt
  $ git commit -m "initial commit"

* Append "2nd line\n" to the readme.txt file.

* Create two new text files with one line each:

  * file1 with "file1\n"
  * file2 with "file2\n"

* Start emacs while in repo directory: $ emacs -Q

  (You can start from any directory, but egg-status uses the current
directory.  Use can use
  any other method, such as cd or dired to set the current directory
to the repository
  directory.)

* Load the egg library: M-x load-file , then find egg.el

* M-x egg-status

  Splits window and creates status buffer on bottom.

* Put the cursor on file1 at the bottom of the status window.

  C-x o    ; switch to status buffer
  C-n ...  ; move to file1

* Press 's' to stage the file which will remove file1 from the bottom
section and create a new file1 section
  showing a diff.

  s

* At this point it may crash.  If not, the cursor should be on the
file1 filename in the new
  section.  Press C-n once to crash.

Message #20 received at 11367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>
Cc: 11367 <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 20:22:51 +0300

> From: Michael Kleehammer <michael <at> kleehammer.com>
> Date: Sat, 28 Apr 2012 11:32:10 -0500
> 
> Sorry for the delay.  It stopped aborting at exactly the same place,
> on multiple machines, with
> and without -Q.  I tried a lot of combinations and it seems that
> adding one more step, a C-n, does it.

Whatever you do to reproduce this, please keep all your steps
identical, so that values reported in different messages are
consistent.  If you need to change the steps for some reason, please
make sure that the values you reported in previous mails are still the
same, or if not, show the new values.  TIA.

> >  (gdb) pgrowx it3.glyph_row
> 
> TEXT: 7 glyphs
>   0    0: CHAR[m] pos=1 blev=0,btyp=L w=14 a+d=16+5 face=19 MB
>   1   14: CHAR[a] pos=2 blev=0,btyp=L w=8 a+d=16+5 face=19 MB
>   2   22: CHAR[s] pos=3 blev=0,btyp=L w=7 a+d=16+5 face=19 MB
>   3   29: CHAR[t] pos=4 blev=0,btyp=L w=6 a+d=16+5 face=19 MB
>   4   35: CHAR[e] pos=5 blev=0,btyp=L w=8 a+d=16+5 face=19 MB
>   5   43: CHAR[r] pos=6 blev=0,btyp=L w=6 a+d=16+5 face=19 MB
>   6   49: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=13+4 MB

??? This is entirely unexpected, since it3.current shows that the
iterator is at position 445.  I'm probably missing something important
here...

What do these commands produce:

 (gdb) p top
 (gdb) p start
 (gdb) p end
 (gdb) p top_y
 (gdb) p (g-20)->object

> * Press 's' to stage the file which will remove file1 from the bottom
> section and create a new file1 section
>   showing a diff.
> 
>   s
> 
> * At this point it may crash.  If not, the cursor should be on the
> file1 filename in the new
>   section.  Press C-n once to crash.

Can you describe or produce a snapshot of the screen before that C-n
keypress?

Thanks.

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 12:56:14 -0500

[Message part 1 (text/plain, inline)]

On Sat, Apr 28, 2012 at 12:22 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Whatever you do to reproduce this, please keep all your steps
> identical, so that values reported in different messages are
> consistent.  If you need to change the steps for some reason, please
> make sure that the values you reported in previous mails are still the
> same, or if not, show the new values.  TIA.

WIll do.  I tried, but it stopped crashing when pressing 's' to stage.  I'm
still using the original session which crashed during the stage, not the C-n.

...

> What do these commands produce:

>  (gdb) p top

$7 = {
  charpos = 1,
  bytepos = 1
}

>  (gdb) p start

$8 = 445

>  (gdb) p end

$9 = 484

>  (gdb) p top_y

$10 = 155

>  (gdb) p (g-20)->object

$11 = 0

> Can you describe or produce a snapshot of the screen before that C-n
> keypress?

[abort-11367.JPG (image/jpeg, attachment)]

Message #26 received at 11367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>
Cc: 11367 <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 21:52:09 +0300

> From: Michael Kleehammer <michael <at> kleehammer.com>
> Date: Sat, 28 Apr 2012 12:56:14 -0500
> 
> >  (gdb) p (g-20)->object
> 
> $11 = 0

Oops, sorry, I meant

  (gdb) p (g-2)->object

(2, not 20).

> > Can you describe or produce a snapshot of the screen before that C-n
> > keypress?
> 
> [2:image/jpeg Show Save:abort-11367.JPG (56kB)]

Hmm... no "master" anywhere in sight.  Do you still see the same
result from "pgrowx it3.glyph_row", showing the text "master", as you
did before?

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 14:17:42 -0500

[Message part 1 (text/plain, inline)]

> Oops, sorry, I meant
>
>  (gdb) p (g-2)->object
>
> (2, not 20).

$12 = 60228101

>> > Can you describe or produce a snapshot of the screen before that C-n
>> > keypress?
>>
>> [2:image/jpeg Show Save:abort-11367.JPG (56kB)]
>
> Hmm... no "master" anywhere in sight.  Do you still see the same
> result from "pgrowx it3.glyph_row", showing the text "master", as you
> did before?

"master" is the name of the branch and is at the top.  I've attached a
new screenshot without
the split screen:

[abort-11367-2.JPG (image/jpeg, attachment)]

Message #32 received at 11367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>
Cc: 11367 <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 22:24:39 +0300

> From: Michael Kleehammer <michael <at> kleehammer.com>
> Date: Sat, 28 Apr 2012 14:17:42 -0500
> 
> > Oops, sorry, I meant
> >
> >  (gdb) p (g-2)->object
> >
> > (2, not 20).
> 
> $12 = 60228101

I see I will need to install msysgit and debug this locally.  Last
request:

 (gdb) p (g-2)->object
 (gdb) xtype
 (gdb) p it3.object
 (gdb) xtype

> > Hmm... no "master" anywhere in sight.  Do you still see the same
> > result from "pgrowx it3.glyph_row", showing the text "master", as you
> > did before?
> 
> "master" is the name of the branch and is at the top.

I see, thanks.

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Kleehammer <michael <at> kleehammer.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 14:27:00 -0500

> I see I will need to install msysgit and debug this locally.  Last
> request:
>
>  (gdb) p (g-2)->object

$13 = 60228101

>  (gdb) xtype

Lisp_Vectorlike
PVEC_BUFFER

>  (gdb) p it3.object

$14 = 84618657

>  (gdb) xtype

Lisp_String

Message #38 received at 11367 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Kleehammer <michael <at> kleehammer.com>
Cc: 11367 <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sat, 28 Apr 2012 23:44:15 +0300

> From: Michael Kleehammer <michael <at> kleehammer.com>
> Date: Sat, 28 Apr 2012 14:27:00 -0500
> 
> > I see I will need to install msysgit and debug this locally.  Last
> > request:
> >
> >  (gdb) p (g-2)->object
> 
> $13 = 60228101
> 
> >  (gdb) xtype
> 
> Lisp_Vectorlike
> PVEC_BUFFER
> 
> >  (gdb) p it3.object
> 
> $14 = 84618657
> 
> >  (gdb) xtype
> 
> Lisp_String

Thanks.  I've reproduced the problem, and will debug it (probably
tomorrow; gray hair says it's unwise to try fixing redisplay after
11PM ;-).

Message #43 received at 11367-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: michael <at> kleehammer.com
Cc: 11367-done <at> debbugs.gnu.org
Subject: Re: bug#11367: 24.0.95.1 Crash: Windows 7 using egg
Date: Sun, 29 Apr 2012 20:30:31 +0300

> Date: Sat, 28 Apr 2012 23:44:15 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11367 <at> debbugs.gnu.org
> 
> > From: Michael Kleehammer <michael <at> kleehammer.com>
> > Date: Sat, 28 Apr 2012 14:27:00 -0500
> > 
> > > I see I will need to install msysgit and debug this locally.  Last
> > > request:
> > >
> > >  (gdb) p (g-2)->object
> > 
> > $13 = 60228101
> > 
> > >  (gdb) xtype
> > 
> > Lisp_Vectorlike
> > PVEC_BUFFER
> > 
> > >  (gdb) p it3.object
> > 
> > $14 = 84618657
> > 
> > >  (gdb) xtype
> > 
> > Lisp_String
> 
> Thanks.  I've reproduced the problem, and will debug it (probably
> tomorrow; gray hair says it's unwise to try fixing redisplay after
> 11PM ;-).

I think I fixed this (revision 107922 on the emacs-24 branch).  The
diffs are below, in case you want (and are able) to try them now.

Thanks.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-04-24 02:58:26 +0000
+++ src/ChangeLog	2012-04-29 17:19:08 +0000
@@ -1,3 +1,10 @@
+2012-04-29  Eli Zaretskii  <eliz <at> gnu.org>
+
+	* xdisp.c (pos_visible_p): If already at a newline from the
+	display string before the 'while' loop, don't walk back the glyphs
+	from it3.glyph_row.  Solves assertion violation when the display
+	string begins with a newline (egg.el).  (Bug#11367)
+
 2012-04-24  Chong Yidong  <cyd <at> gnu.org>
 
 	* xselect.c (x_convert_selection): Initialize a pointer (Bug#11315).

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-04-23 16:22:23 +0000
+++ src/xdisp.c	2012-04-29 17:19:08 +0000
@@ -1375,6 +1375,7 @@ pos_visible_p (struct window *w, EMACS_I
 		  Lisp_Object startpos, endpos;
 		  EMACS_INT start, end;
 		  struct it it3;
+		  int it3_moved;
 
 		  /* Find the first and the last buffer positions
 		     covered by the display string.  */
@@ -1431,6 +1432,15 @@ pos_visible_p (struct window *w, EMACS_I
 		     begins.  */
 		  start_display (&it3, w, top);
 		  move_it_to (&it3, -1, 0, top_y, -1, MOVE_TO_X | MOVE_TO_Y);
+		  /* If it3_moved stays zero after the 'while' loop
+		     below, that means we already were at a newline
+		     before the loop (e.g., the display string begins
+		     with a newline), so we don't need to (and cannot)
+		     inspect the glyphs of it3.glyph_row, because
+		     PRODUCE_GLYPHS will not produce anything for a
+		     newline, and thus it3.glyph_row stays at its
+		     stale content it got at top of the window.  */
+		  it3_moved = 0;
 		  /* Finally, advance the iterator until we hit the
 		     first display element whose character position is
 		     CHARPOS, or until the first newline from the
@@ -1442,6 +1452,7 @@ pos_visible_p (struct window *w, EMACS_I
 		      if (IT_CHARPOS (it3) == charpos
 			  || ITERATOR_AT_END_OF_LINE_P (&it3))
 			break;
+		      it3_moved = 1;
 		      set_iterator_to_next (&it3, 0);
 		    }
 		  top_x = it3.current_x - it3.pixel_width;
@@ -1452,7 +1463,8 @@ pos_visible_p (struct window *w, EMACS_I
 		     display string, move back over the glyphs
 		     produced from the string, until we find the
 		     rightmost glyph not from the string.  */
-		  if (IT_CHARPOS (it3) != charpos && EQ (it3.object, string))
+		  if (it3_moved
+		      && IT_CHARPOS (it3) != charpos && EQ (it3.object, string))
 		    {
 		      struct glyph *g = it3.glyph_row->glyphs[TEXT_AREA]
 					+ it3.glyph_row->used[TEXT_AREA];

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.