GNU bug report logs - #1448
23.0.60; update to cvs emacs crash report

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 1448 in the body.
You can then email your comments to 1448 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Feng li <fengli <at> blackmagic-design.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 16:15:49 +1100

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Start emacs with "-q". Press "C-h b" to bring up the keybinding
help. Switch to the keybinding help window and press "PgDn" a few times
will cause emacs to crash.

I have rebuilt a new emacs binary with debug info and attached the back
trace of the crash location at below.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/etc/DEBUG for instructions.

Current directory is c:/emacs/bin/
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) set args "-q"
(gdb) r
Starting program: c:\emacs\bin/emacs.exe "-q"
Loaded symbols for C:\WINDOWS\system32\ntdll.dll
Loaded symbols for C:\WINDOWS\system32\kernel32.dll
Loaded symbols for C:\WINDOWS\system32\advapi32.dll
Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
Loaded symbols for C:\WINDOWS\system32\secur32.dll
Loaded symbols for C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
Loaded symbols for C:\WINDOWS\system32\msvcrt.dll
Loaded symbols for C:\WINDOWS\system32\gdi32.dll
Loaded symbols for C:\WINDOWS\system32\user32.dll
Loaded symbols for C:\WINDOWS\system32\shlwapi.dll
Loaded symbols for C:\WINDOWS\system32\comdlg32.dll
Loaded symbols for C:\WINDOWS\system32\shell32.dll
Loaded symbols for C:\WINDOWS\system32\mpr.dll
Loaded symbols for C:\WINDOWS\system32\ole32.dll
Loaded symbols for C:\WINDOWS\system32\usp10.dll
Loaded symbols for C:\WINDOWS\system32\winmm.dll
Loaded symbols for C:\WINDOWS\system32\winspool.drv

Program received signal SIGSEGV, Segmentation fault.
0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740
(gdb) bt full
#0  0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740
	glyph = (struct glyph *) 0x334f120
	last = (struct glyph *) 0x334f3c0
	voffset = 0
	glyph_not_available_p = 0
#1  0x01040a0c in draw_glyphs (w=0x3439800, x=72, row=0x3345260, area=TEXT_AREA, start=0, end=30, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20332
	base_face = (struct face *) 0xf00021
	char2b = <value optimized out>
	cmp = <value optimized out>
	first_s = (struct glyph_string *) 0x100000
	n = <value optimized out>
	first_glyph = <value optimized out>
	head = (struct glyph_string *) 0x82eb40
	tail = (struct glyph_string *) 0x82ea20
	s = (struct glyph_string *) 0x0
	clip_head = <value optimized out>
	clip_tail = <value optimized out>
	i = 8
	j = <value optimized out>
	x_reached = <value optimized out>
	last_x = 648
	area_left = 8
	f = (struct frame *) 0x2d26600
	hdc = (HDC) 0x500110bc
#2  0x01044f61 in x_write_glyphs (start=0x334f000, len=30) at xdisp.c:21896
	x = <value optimized out>
#3  0x010ed18d in update_window_line (w=0x3439800, vpos=4, mouse_face_overwritten_p=0x82f008) at dispnew.c:4603
	current_row = (struct glyph_row *) 0x3397260
	desired_row = (struct glyph_row *) 0x3345260
	rif = (struct redisplay_interface *) 0x12bd710
	changed_p = 0
#4  0x010ee614 in update_window (w=0x3439800, force_p=0) at dispnew.c:4310
	tm = {
  tv_sec = 1227849103, 
  tv_usec = 187000
}
	vpos = 0
	i = <value optimized out>
	end = (struct glyph_row *) 0x3346398
	header_line_row = (struct glyph_row *) 0x0
	changed_p = 1
	mouse_face_overwritten_p = 0
	row = (struct glyph_row *) 0x3345260
	yb = 304
	desired_matrix = (struct glyph_matrix *) 0x333e400
	paused_p = 8580796
	rif = (struct redisplay_interface *) 0x12bd710
#5  0x010f0714 in update_window_tree (w=0x3439800, force_p=0) at dispnew.c:4003
	paused_p = <value optimized out>
#6  0x010f06fe in update_window_tree (w=0x3439400, force_p=0) at dispnew.c:4001
	paused_p = <value optimized out>
#7  0x010f0cf3 in update_frame (f=0x2d26600, force_p=0, inhibit_hairy_id_p=0) at dispnew.c:3930
	tm = {
  tv_sec = 1227849103, 
  tv_usec = 187000
}
	p = -nan(0x8000000000000)
	sec = 51984384
	usec = <value optimized out>
	paused_p = <value optimized out>
	root_window = (struct window *) 0x3439400
#8  0x010378b4 in redisplay_internal (preserve_echo_area=<value optimized out>) at xdisp.c:11891
	mini_window = <value optimized out>
	mini_frame = <value optimized out>
	w = (struct window *) 0x3439800
	pause = <value optimized out>
	must_finish = 1
	tlbufpos = {
  charpos = 0, 
  bytepos = 0
}
	number_of_visible_frames = 1
	polling_stopped_here = 0
	old_frame = 47343108
	consider_all_windows_p = 0
#9  0x0106b456 in read_char (commandflag=1, nmaps=3, maps=0x82fbb0, prev_event=45590529, used_mouse_menu=0x82fc44, end_time=0x0) at keyboard.c:2649
	keys = 45590529
	key_count = <value optimized out>
	key_count_reset = 45590529
	saved_ok_to_echo = (struct kboard *) 0x82faa0
	saved_echo_string = 51982336
	c = 45590529
	local_getcjmp =   {524,
  525,
  8583944,
  18038426,
  2,
  1,
  51982340,
  45842961,
  51982340,
  4208,
  8584024,
  17924685,
  51982336,
  49875565,
  8584000,
  0}
	save_jump =   {0,
  -1,
  0,
  8583936,
  8583937,
  45624064,
  8583912,
  17296387,
  54484181,
  54484205,
  8584012,
  11000,
  3667,
  54484189,
  19635,
  51773440}
	key_already_recorded = 0
	tem = 51982336
	save = <value optimized out>
	previous_echo_area_message = 45590529
	also_record = 45590529
	reread = 0
	polling_stopped_here = <value optimized out>
	orig_kboard = (struct kboard *) 0x3000d80
#10 0x0106e08f in read_key_sequence (keybuf=0x82fce4, bufsize=30, prompt=45590529, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9344
	interrupted_kboard = (KBOARD *) 0x3000d80
	key = 54993268
	used_mouse_menu = 0
	echo_local_start = 0
	last_real_key_start = 0
	keys_local_start = 0
	local_first_binding = 0
	from_string = 45590529
	count = 2
	t = 0
	echo_start = 0
	keys_start = 0
	nmaps = 3
	nmaps_allocated = 3
	defs = (Lisp_Object * volatile) 0x82fb90
	submaps = (Lisp_Object * volatile) 0x82fbb0
	orig_local_map = 49879613
	orig_keymap = 45590529
	localized_local_map = 0
	first_binding = 0
	first_unbound = 31
	mock_input = 0
	fkey = {
  parent = 46299045, 
  map = 46299045, 
  start = 0, 
  end = 0
}
	keytran = {
  parent = 45580157, 
  map = 45580157, 
  start = 0, 
  end = 0
}
	indec = {
  parent = 46299221, 
  map = 46299221, 
  start = 0, 
  end = 0
}
	shift_translated = 0
	delayed_switch_frame = 45590529
	original_uppercase = 8584332
	original_uppercase_position = -1
	starting_buffer = (struct buffer *) 0x3193000
	fake_prefixed_keys = 45590529
#11 0x0106ff38 in command_loop_1 () at keyboard.c:1621
	cmd = <value optimized out>
	lose = 4356
	nonundocount = 0
	keybuf =   {45968033,
  888,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  84,
  0,
  234881024,
  84,
  33689241,
  0,
  13,
  33689241,
  0,
  -402653185,
  0,
  8584520,
  8584368,
  0,
  33685504,
  45590529,
  46654801,
  46227456,
  46227472,
  46227456,
  8584552}
	i = 4356
	prev_modiff = 4356
	prev_buffer = (struct buffer *) 0x3193000
	already_adjusted = 0
#12 0x01013b58 in internal_condition_case (bfun=0x106fd94 <command_loop_1>, handlers=45654281, hfun=0x106a3ac <cmd_error>) at eval.c:1511
	val = <value optimized out>
	c = {
  tag = 45590529, 
  val = 45590529, 
  next = 0x82fe2c, 
  gcpro = 0x0, 
  jmp =     {8584696,
    46227456,
    46227456,
    46227472,
    8584556,
    16857872,
    8585184,
    0,
    8584632,
    16873592,
    0,
    10,
    0,
    16884063,
    1520,
    0}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 0, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	h = {
  handler = 45654281, 
  var = 45590529, 
  chosen_clause = 2, 
  tag = 0x82fd78, 
  next = 0x0
}
#13 0x01069976 in command_loop_2 () at keyboard.c:1338
	val = 0
#14 0x01013bf3 in internal_catch (tag=45650353, func=0x1069953 <command_loop_2>, arg=45590529) at eval.c:1247
	c = {
  tag = 45650353, 
  val = 45590529, 
  next = 0x0, 
  gcpro = 0x0, 
  jmp =     {8584856,
    46227456,
    46227456,
    46227472,
    8584732,
    16858086,
    8585184,
    0,
    16812203,
    45871369,
    45870490,
    45590529,
    45629440,
    8726632,
    2009473784,
    45590553}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 0, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
#15 0x0106a21b in command_loop () at keyboard.c:1317
No locals.
#16 0x0106a537 in recursive_edit_1 () at keyboard.c:942
	val = <value optimized out>
#17 0x0106a653 in Frecursive_edit () at keyboard.c:1004
	buffer = 45590529
#18 0x01002d37 in main (argc=2, argv=0xa44e68) at emacs.c:1777
	old_log_max = <value optimized out>
	symbol = <value optimized out>
	tail = <value optimized out>
	inhibit_unibyte = <value optimized out>
	dummy = 2009288258
	stack_bottom_variable = 1 '\001'
	do_initial_setlocale = <value optimized out>
	skip_args = 0
	no_loadup = 0
	junk = 0x0
	dname_arg = 0x0
(gdb) xbacktrace
(gdb) 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-11-28 on SCUMBAG
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.2) --cflags -I../../emacs_libs/inc'

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: Debugger

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  cua-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f <C-S-left> <C-S-left> <C-S-left> <C-S-left> 
d e v <tab> <C-S-left> e m a c s / b i n <tab> <return> 
<C-end> M-x g d b <return> <return> s e t SPC a r g 
s SPC " " <left> - q <return> r <return> b t SPC f 
u l l <return> x b a c k t r a c e <return> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <prior> <prior> <prior> <prior> 
<prior> <prior> <prior> <C-end> <C-end> <C-home> <next> 
<C-end> C-x h <C-insert> <down-mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
Loading c:/Documents and Settings/fengli/.recentf...done
Ido mode enabled
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Truncate long lines enabled
Loading semanticdb-file...done
Loading vc-cvs...done
Mark set [23 times]
cua-scroll-down: Beginning of buffer [5 times]
Mark set [6 times]

-- 
# Feng Li

# Blackmagic Design
# fengli <at> blackmagic-design.com
# www.blackmagic-design.com

Message #10 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Feng li" <fengli <at> blackmagic-design.com>
Cc: 1448 <at> debbugs.gnu.org
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 10:25:09 +0100

merge 872 1446 1447 1448
quit

On Fri, Nov 28, 2008 at 06:15, Feng li <fengli <at> blackmagic-design.com> wrote:

> Start emacs with "-q". Press "C-h b" to bring up the keybinding
> help. Switch to the keybinding help window and press "PgDn" a few times
> will cause emacs to crash.
>
> I have rebuilt a new emacs binary with debug info and attached the back
> trace of the crash location at below.

What you're seeing is bug#872 (also #1179).

I originally thought it depended on
`display-unibyte-via-language-environment', but it is not so; I've
seen it (and suffered it) through several different incarnations.

What they all have in common:

 - Using a "recent" MinGW GCC (4.2.1, 4.3.0-alpha, etc.)
 - Compiling with optimization
 - Trying to display unibyte (or, perhaps, some composed characters,
I'm not sure)
 - It *always* happens when draw_glyphs is running
 - It mostly happens in fill_glyph_string

I can reproduce it at will in a lot of ways, for example:

  M-x ucs-insert AEGEAN CHECK MARK <RET>

or

  (let ((my-map (make-keymap)))
    (suppress-keymap my-map)
    (substitute-command-keys "\\{my-map}"))

or having `display-unibyte-via-language-environment' set to t and
`debug' being called for whatever reason, etc. etc.

I've been trying to debug it, without success (it doesn't help that I
know very little about the glyph handling code). I'm not even sure
whether it is a compiler bug, or a bug in Emacs (it happens in code
that was undergoing changes quite recently).

  Juanma

Message #19 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>, 1448 <at> debbugs.gnu.org
Cc: fengli <at> blackmagic-design.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 12:56:05 +0200

> Date: Fri, 28 Nov 2008 10:25:09 +0100
> From: "Juanma Barranquero" <lekktu <at> gmail.com>
> Cc: 1448 <at> emacsbugs.donarmstrong.com
> 
> What you're seeing is bug#872 (also #1179).
> 
> I originally thought it depended on
> `display-unibyte-via-language-environment', but it is not so; I've
> seen it (and suffered it) through several different incarnations.
> 
> What they all have in common:
> 
>  - Using a "recent" MinGW GCC (4.2.1, 4.3.0-alpha, etc.)
>  - Compiling with optimization

Now I understand why I cannot reproduce this: I never bothered to
upgrade to GCC 4.x.

>  - Trying to display unibyte (or, perhaps, some composed characters,
> I'm not sure)

How does "C-h b" get to display unibyte or composed characters?

> I've been trying to debug it, without success (it doesn't help that I
> know very little about the glyph handling code). I'm not even sure
> whether it is a compiler bug, or a bug in Emacs (it happens in code
> that was undergoing changes quite recently).

Is it a Heisenbug? i.e., does it disappear if you add printf's around
the code that crashes or in its callers?

If the bug stays put when code around it is modified, you could try
debugging it by adding "if (something) abort ();" lines testing
various conditions that are suspect of causing the crash.

Some observations based on the traceback posted by Feng Li:

> Program received signal SIGSEGV, Segmentation fault.
> 0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at xdisp.c:19740

Line 19740 in xdisp.c is this:

  s->ybase += voffset;

And "bt full" says this about `s':

> 	s = (struct glyph_string *) 0x0

However, `s' is dereferenced many times in `fill_glyph_string' before
it gets to line 19740, so I think GDB lies about the place where it
crashed (because GCC optimizes code to the degree that any relation
between the code and the source lines is lost).

Therefore, the first thing to do is disassembly the vicinity of the
crash locus (0x0101fdd5) and see which code, exactly, crashes, and
why.  Disassembly should establish (1) the source line that crashes,
and (2) which C-level variable causes the crash.

Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
which is called by BUILD_GLYPH_STRINGS, which in turn is called by
`draw_glyphs' at line 20332 in frame #1:

> #1  0x01040a0c in draw_glyphs (w=0x3439800, x=72, row=0x3345260, area=TEXT_AREA, start=0, end=30, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20332

The original source line 20332 in xdisp.c looks like this:

  BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);

Message #29 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 1448 <at> debbugs.gnu.org, "Feng li" <fengli <at> blackmagic-design.com>
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 12:23:33 +0100

On Fri, Nov 28, 2008 at 11:56, Eli Zaretskii <eliz <at> gnu.org> wrote:

> How does "C-h b" get to display unibyte or composed characters?

In a keymap case I found, Emacs crashed while trying to display \200.
But I could be wrong (again) about what exactly triggers the crash.

> Is it a Heisenbug? i.e., does it disappear if you add printf's around
> the code that crashes or in its callers?

Not exactly a heisenbug, because it does not disappear. It moves.
That's why I've said that it always fails with draw_glyphs in the
stack, but not always in fill_glyph_string.

> If the bug stays put when code around it is modified, you could try
> debugging it by adding "if (something) abort ();" lines testing
> various conditions that are suspect of causing the crash.

I've tried that (well, I added xassert() and/or eassert) at likely
places; they didn't get triggered.

> However, `s' is dereferenced many times in `fill_glyph_string' before
> it gets to line 19740, so I think GDB lies about the place where it
> crashed (because GCC optimizes code to the degree that any relation
> between the code and the source lines is lost).

Yes, I agree that GDB lies. If only the bug happened with non-optimized code...

> Therefore, the first thing to do is disassembly the vicinity of the
> crash locus (0x0101fdd5) and see which code, exactly, crashes, and
> why.  Disassembly should establish (1) the source line that crashes,
> and (2) which C-level variable causes the crash.

I'll try to do that.

> Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
> which is called by BUILD_GLYPH_STRINGS, which in turn is called by
> `draw_glyphs' at line 20332 in frame #1:

Sorry, I fail to understand what you are trying to say. I've suspected
that alloca'd memory is related to the crash, but I don't see how.

  Juanma

Message #34 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 1448 <at> debbugs.gnu.org, fengli <at> blackmagic-design.com
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 14:06:10 +0200

> Date: Fri, 28 Nov 2008 12:23:33 +0100
> From: "Juanma Barranquero" <lekktu <at> gmail.com>
> Cc: 1448 <at> emacsbugs.donarmstrong.com, "Feng li" <fengli <at> blackmagic-design.com>
> 
> > Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
> > which is called by BUILD_GLYPH_STRINGS, which in turn is called by
> > `draw_glyphs' at line 20332 in frame #1:
> 
> Sorry, I fail to understand what you are trying to say.

I was just trying to add more info about where `s' comes from.  Since
it comes from a call to `alloca', which is a compiler built-in with
GCC, it could be a compiler bug

> I've suspected that alloca'd memory is related to the crash, but I
> don't see how.

Neither do I.

Message #39 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 1448 <at> debbugs.gnu.org, fengli <at> blackmagic-design.com
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 13:08:22 +0100

On Fri, Nov 28, 2008 at 13:06, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Since
> it comes from a call to `alloca', which is a compiler built-in with
> GCC, it could be a compiler bug

Ah, of course! Thanks.

   Juanma

Message #44 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Feng Li <fengli <at> blackmagic-design.com>
To: "Juanma Barranquero" <lekktu <at> gmail.com>
Cc: 1448 <at> debbugs.gnu.org
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Mon, 01 Dec 2008 09:11:12 +1100

"Juanma Barranquero" <lekktu <at> gmail.com> writes:

> I've been trying to debug it, without success (it doesn't help that I
> know very little about the glyph handling code). I'm not even sure
> whether it is a compiler bug, or a bug in Emacs (it happens in code
> that was undergoing changes quite recently).
>

I doubt this is a compiler bug because it did not happen in my previous
Emacs build which is compiled with the same compiler in October.

-- 
# Feng Li

Message #49 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Feng Li" <fengli <at> blackmagic-design.com>
Cc: 1448 <at> debbugs.gnu.org
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Mon, 1 Dec 2008 00:03:04 +0100

On Sun, Nov 30, 2008 at 23:11, Feng Li <fengli <at> blackmagic-design.com> wrote:

> I doubt this is a compiler bug because it did not happen in my previous
> Emacs build which is compiled with the same compiler in October.

It also started suddenly for me, after some big changes related (I
think) to character composition.

But that does not mean that it could not be a compiler bug: perhaps
the new code triggers the bug, and the old code didn't.

That said, my gut feeling is that is not a compiler bug because I'm
getting it with two compilers, 4.2.1 and 4.3.0, but it is not
impossible that such a bug, if it is specific to the MinGW port, could
go undetected between releases.

  Juanma

Message #54 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Feng Li <fengli <at> blackmagic-design.com>
To: "Juanma Barranquero" <lekktu <at> gmail.com>
Cc: 1448 <at> debbugs.gnu.org
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Thu, 04 Dec 2008 13:47:33 +1100

"Juanma Barranquero" <lekktu <at> gmail.com> writes:

> On Sun, Nov 30, 2008 at 23:11, Feng Li <fengli <at> blackmagic-design.com> wrote:
>
>> I doubt this is a compiler bug because it did not happen in my previous
>> Emacs build which is compiled with the same compiler in October.
>
> It also started suddenly for me, after some big changes related (I
> think) to character composition.
>
> But that does not mean that it could not be a compiler bug: perhaps
> the new code triggers the bug, and the old code didn't.
>
> That said, my gut feeling is that is not a compiler bug because I'm
> getting it with two compilers, 4.2.1 and 4.3.0, but it is not
> impossible that such a bug, if it is specific to the MinGW port, could
> go undetected between releases.
>
>   Juanma
>

I can confirm this bug happens for msvc2003 builds too.

And just like the mingw build, "C-h b" then scroll down will crash emacs
100% of the time.

-- 
# Feng Li

# Blackmagic Design
# fengli <at> blackmagic-design.com
# www.blackmagic-design.com

Message #59 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Feng Li" <fengli <at> blackmagic-design.com>
Cc: 1448 <at> debbugs.gnu.org
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Thu, 4 Dec 2008 09:44:01 +0100

On Thu, Dec 4, 2008 at 03:47, Feng Li <fengli <at> blackmagic-design.com> wrote:

> I can confirm this bug happens for msvc2003 builds too.

That's good news, of a sort. We can discard the GCC bug hypothesis.

Now, it would be great to know why does it happen only on Windows.

    Juanma

Message #64 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 1448 <at> debbugs.gnu.org, "Feng Li" <fengli <at> blackmagic-design.com>
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Thu, 04 Dec 2008 08:31:24 -0500

>> I can confirm this bug happens for msvc2003 builds too.
> That's good news, of a sort. We can discard the GCC bug hypothesis.
> Now, it would be great to know why does it happen only on Windows.

The description of the bug makes me think it may have to do with the
font code.  E.g. when you scroll C-h b you may end up displaying
something like the character #x3fff7f.


        Stefan

Message #69 received at 1448 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: 1448 <at> debbugs.gnu.org, "Feng Li" <fengli <at> blackmagic-design.com>
Subject: Re: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Thu, 4 Dec 2008 15:51:41 +0100

On Thu, Dec 4, 2008 at 14:31, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> The description of the bug makes me think it may have to do with the
> font code.

Crash is always in the call stack after draw_glyphs, so yes.

Whatever the reason, it appeared on or before 2008-08-05.

    Juanma

Previous Next

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