GNU bug report logs -
#17771
24.3.91; SIGSEGV in cleanup_vector
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Fri, 13 Jun 2014 09:14:02 UTC
Severity: normal
Tags: moreinfo
Merged with 16140,
16414,
17071,
17602
Found in versions 24.3.50, 24.3.91, 24.4.50
Fixed in version 24.3.93
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17771 in the body.
You can then email your comments to 17771 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 09:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 13 Jun 2014 09:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
0. emacs -Q
1. C-h h (on my machine, it takes ~30 seconds for the Hello file to
appear; during that time, do the following:)
2. Type C-g repeatedly (I did it rapidly, for ~15 seconds).
3. Emacs crashes, full backtrace below. (This is reliably reproducible.)
In GNU Emacs 24.3.91.9 (x86_64-suse-linux-gnu, GTK+ Version 3.10.4)
of 2014-06-13 on rosalinde
Repository revision: 117234 eggert <at> cs.ucla.edu-20140611200346-2x9bn68tus2nlf37
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description: openSUSE 13.1 (Bottle) (x86_64)
Configured using:
`configure --without-toolkit-scroll-bars CFLAGS=-g3'
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Program received signal SIGSEGV, Segmentation fault.
0x00000000005aa564 in cleanup_vector (vector=0x43b4ea8)
at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
2929 ((struct font *) vector)->driver->close ((struct font *) vector);
(gdb) bt full
#0 0x00000000005aa564 in cleanup_vector (vector=0x43b4ea8)
at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
No locals.
#1 0x00000000005aa677 in sweep_vectors ()
at ../../../../bzr/emacs/emacs-24/src/alloc.c:2967
total_bytes = 120
free_this_block = false
nbytes = 120
block = 0x43b4020
bprev = 0x43b6418
lv = 0x628297 <balance_intervals+31>
lvprev = 0xbf2070
vector = 0x43b4ea8
next = 0x43b4ea8
#2 0x00000000005b0132 in gc_sweep () at ../../../../bzr/emacs/emacs-24/src/alloc.c:6714
No locals.
#3 0x00000000005ae19d in Fgarbage_collect ()
at ../../../../bzr/emacs/emacs-24/src/alloc.c:5643
nextb = 0x0
stack_top_variable = 0 '\000'
i = 1619
message_p = true
count = 3
start = {
tv_sec = 1402649898,
tv_nsec = 231551682
}
retval = 12738738
tot_before = 0
#4 0x00000000005374b1 in maybe_gc () at ../../../../bzr/emacs/emacs-24/src/lisp.h:4564
No locals.
#5 0x00000000005cd9f4 in Ffuncall (nargs=4, args=0x7fffffffd970)
at ../../../../bzr/emacs/emacs-24/src/eval.c:2766
fun = 5936534
original_fun = 140737488345376
funcar = 12765552
numargs = 3
---Type <return> to continue, or q <return> to quit---
lisp_numargs = 9258817
val = 140737488345424
internal_args = 0xc260b2
i = 9258817
#6 0x00000000005cd6e6 in call3 (fn=12786194, arg1=25124486, arg2=9258817, arg3=12738738)
at ../../../../bzr/emacs/emacs-24/src/eval.c:2645
ret_ungc_val = 140737488345600
gcpro1 = {
next = 0x7fffffffd9b0,
var = 0x53738f <build_string+42>,
nvars = 4
}
args = {12786194, 25124486, 9258817, 12738738}
#7 0x000000000053ccef in cmd_error_internal (data=25124486, context=0x7fffffffda00 "")
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1085
No locals.
#8 0x000000000053cc13 in cmd_error (data=25124486)
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1054
old_level = 12738738
old_length = 12738738
macroerror = "\000`\302\000\000\000\000\000F\304|\001\000\000\000\000\002\000\000\000\000\000\000\000\262`\302\000\000\000\000\000\000\000\000\000\002", '\000' <repeats 11 times>, <incomplete sequence \332>
#9 0x00000000005cab95 in internal_condition_case (bfun=0x53d1ab <command_loop_1>,
handlers=12790306, hfun=0x53cabd <cmd_error>)
at ../../../../bzr/emacs/emacs-24/src/eval.c:1351
val = 25124486
val = 5492514
c = 0x13d5830
#10 0x000000000053cf05 in command_loop_2 (ignore=12738738)
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1177
val = 0
#11 0x00000000005ca3af in internal_catch (tag=12786242, func=0x53cedf <command_loop_2>,
arg=12738738) at ../../../../bzr/emacs/emacs-24/src/eval.c:1118
val = 12738738
c = 0x13d5630
#12 0x000000000053ceb3 in command_loop ()
---Type <return> to continue, or q <return> to quit---
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1156
No locals.
#13 0x000000000053c6b8 in recursive_edit_1 ()
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:777
count = 1
val = 12738738
#14 0x000000000053c825 in Frecursive_edit ()
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:848
count = 0
buffer = 12738738
#15 0x000000000053a857 in main (argc=2, argv=0x7fffffffdd98)
at ../../../../bzr/emacs/emacs-24/src/emacs.c:1646
dummy = 140737354130592
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7ffff7ffe148 ""
original_pwd = 0x0
Lisp Backtrace:
"Automatic GC" (0xc0bbe8)
"command-error-default-function" (0xffffd978)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 09:43:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 17771 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Fri, 13 Jun 2014 11:12:44 +0200
>
>
> 0. emacs -Q
> 1. C-h h (on my machine, it takes ~30 seconds for the Hello file to
> appear; during that time, do the following:)
> 2. Type C-g repeatedly (I did it rapidly, for ~15 seconds).
> 3. Emacs crashes, full backtrace below. (This is reliably reproducible.)
Not here, but this is Windows, where input is treated very
differently.
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005aa564 in cleanup_vector (vector=0x43b4ea8)
> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
So which one is the bad pointer, vector, vector->driver, or
vector->driver->close?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 09:52:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Fri, 13 Jun 2014 12:41:56 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Fri, 13 Jun 2014 11:12:44 +0200
>>
>>
>> 0. emacs -Q
>> 1. C-h h (on my machine, it takes ~30 seconds for the Hello file to
>> appear; during that time, do the following:)
>> 2. Type C-g repeatedly (I did it rapidly, for ~15 seconds).
>> 3. Emacs crashes, full backtrace below. (This is reliably reproducible.)
>
> Not here, but this is Windows, where input is treated very
> differently.
>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000000005aa564 in cleanup_vector (vector=0x43b4ea8)
>> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
>> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
>
> So which one is the bad pointer, vector, vector->driver, or
> vector->driver->close?
If you're asking me, can you tell me what to type in gdb to find out?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 12:21:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 17771 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 17771 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2014 11:50:59 +0200
>
> On Fri, 13 Jun 2014 12:41:56 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> Date: Fri, 13 Jun 2014 11:12:44 +0200
> >>
> >>
> >> 0. emacs -Q
> >> 1. C-h h (on my machine, it takes ~30 seconds for the Hello file to
> >> appear; during that time, do the following:)
> >> 2. Type C-g repeatedly (I did it rapidly, for ~15 seconds).
> >> 3. Emacs crashes, full backtrace below. (This is reliably reproducible.)
> >
> > Not here, but this is Windows, where input is treated very
> > differently.
> >
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x00000000005aa564 in cleanup_vector (vector=0x43b4ea8)
> >> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
> >> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
> >
> > So which one is the bad pointer, vector, vector->driver, or
> > vector->driver->close?
>
> If you're asking me, can you tell me what to type in gdb to find out?
(gdb) p vector
(gdb) p vector->driver
(gdb) p vector->driver->close
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 12:41:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Fri, 13 Jun 2014 15:19:50 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 17771 <at> debbugs.gnu.org
>> Date: Fri, 13 Jun 2014 11:50:59 +0200
>>
>> On Fri, 13 Jun 2014 12:41:56 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> >> From: Stephen Berman <stephen.berman <at> gmx.net>
>> >> Date: Fri, 13 Jun 2014 11:12:44 +0200
>> >>
>> >>
>> >> 0. emacs -Q
>> >> 1. C-h h (on my machine, it takes ~30 seconds for the Hello file to
>> >> appear; during that time, do the following:)
>> >> 2. Type C-g repeatedly (I did it rapidly, for ~15 seconds).
>> >> 3. Emacs crashes, full backtrace below. (This is reliably reproducible.)
>> >
>> > Not here, but this is Windows, where input is treated very
>> > differently.
>> >
>> >> Program received signal SIGSEGV, Segmentation fault.
>> >> 0x00000000005aa564 in cleanup_vector (vector=0x43b4ea8)
>> >> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
>> >> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
>> >
>> > So which one is the bad pointer, vector, vector->driver, or
>> > vector->driver->close?
>>
>> If you're asking me, can you tell me what to type in gdb to find out?
>
> (gdb) p vector
> (gdb) p vector->driver
> (gdb) p vector->driver->close
>
> Thanks.
Program received signal SIGSEGV, Segmentation fault.
0x00000000005aa564 in cleanup_vector (vector=0x413c318)
at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
2929 ((struct font *) vector)->driver->close ((struct font *) vector);
(gdb) p vector
$1 = (struct Lisp_Vector *) 0x413c318
(gdb) p vector->driver
There is no member named driver.
(gdb) p vector->driver->close
There is no member named driver.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 13:30:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 17771 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 17771 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2014 14:39:42 +0200
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005aa564 in cleanup_vector (vector=0x413c318)
> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
> (gdb) p vector
> $1 = (struct Lisp_Vector *) 0x413c318
> (gdb) p vector->driver
> There is no member named driver.
> (gdb) p vector->driver->close
> There is no member named driver.
(gdb) p ((struct font *) vector)->driver
(gdb) p ((struct font *) vector)->driver->close
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 13:35:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 17771 <at> debbugs.gnu.org
>> Date: Fri, 13 Jun 2014 14:39:42 +0200
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000000005aa564 in cleanup_vector (vector=0x413c318)
>> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
>> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
>> (gdb) p vector
>> $1 = (struct Lisp_Vector *) 0x413c318
>> (gdb) p vector->driver
>> There is no member named driver.
>> (gdb) p vector->driver->close
>> There is no member named driver.
>
> (gdb) p ((struct font *) vector)->driver
> (gdb) p ((struct font *) vector)->driver->close
(gdb) p ((struct font *) vector)->driver
$4 = (struct font_driver *) 0x0
(gdb) p ((struct font *) vector)->driver->close
Cannot access memory at address 0x40
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 13:46:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 17771 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 17771 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2014 15:34:12 +0200
>
> On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> Cc: 17771 <at> debbugs.gnu.org
> >> Date: Fri, 13 Jun 2014 14:39:42 +0200
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x00000000005aa564 in cleanup_vector (vector=0x413c318)
> >> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
> >> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
> >> (gdb) p vector
> >> $1 = (struct Lisp_Vector *) 0x413c318
> >> (gdb) p vector->driver
> >> There is no member named driver.
> >> (gdb) p vector->driver->close
> >> There is no member named driver.
> >
> > (gdb) p ((struct font *) vector)->driver
> > (gdb) p ((struct font *) vector)->driver->close
>
> (gdb) p ((struct font *) vector)->driver
> $4 = (struct font_driver *) 0x0
> (gdb) p ((struct font *) vector)->driver->close
> Cannot access memory at address 0x40
IOW, the font driver is NULL.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 13:55:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Fri, 13 Jun 2014 16:44:39 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 17771 <at> debbugs.gnu.org
>> Date: Fri, 13 Jun 2014 15:34:12 +0200
>>
>> On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> >> From: Stephen Berman <stephen.berman <at> gmx.net>
>> >> Cc: 17771 <at> debbugs.gnu.org
>> >> Date: Fri, 13 Jun 2014 14:39:42 +0200
>> >>
>> >> Program received signal SIGSEGV, Segmentation fault.
>> >> 0x00000000005aa564 in cleanup_vector (vector=0x413c318)
>> >> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
>> >> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
>> >> (gdb) p vector
>> >> $1 = (struct Lisp_Vector *) 0x413c318
>> >> (gdb) p vector->driver
>> >> There is no member named driver.
>> >> (gdb) p vector->driver->close
>> >> There is no member named driver.
>> >
>> > (gdb) p ((struct font *) vector)->driver
>> > (gdb) p ((struct font *) vector)->driver->close
>>
>> (gdb) p ((struct font *) vector)->driver
>> $4 = (struct font_driver *) 0x0
>> (gdb) p ((struct font *) vector)->driver->close
>> Cannot access memory at address 0x40
>
> IOW, the font driver is NULL.
Could that be due to my typing `C-g'? If I don't do that, the file does
get displayed. But `C-g' shouldn't make Emacs crash. Do you see what
the problem is, or can I provide further information?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 13:59:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 17771 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 17771 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2014 15:53:35 +0200
>
> On Fri, 13 Jun 2014 16:44:39 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> Cc: 17771 <at> debbugs.gnu.org
> >> Date: Fri, 13 Jun 2014 15:34:12 +0200
> >>
> >> On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>
> >> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> >> Cc: 17771 <at> debbugs.gnu.org
> >> >> Date: Fri, 13 Jun 2014 14:39:42 +0200
> >> >>
> >> >> Program received signal SIGSEGV, Segmentation fault.
> >> >> 0x00000000005aa564 in cleanup_vector (vector=0x413c318)
> >> >> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2929
> >> >> 2929 ((struct font *) vector)->driver->close ((struct font *) vector);
> >> >> (gdb) p vector
> >> >> $1 = (struct Lisp_Vector *) 0x413c318
> >> >> (gdb) p vector->driver
> >> >> There is no member named driver.
> >> >> (gdb) p vector->driver->close
> >> >> There is no member named driver.
> >> >
> >> > (gdb) p ((struct font *) vector)->driver
> >> > (gdb) p ((struct font *) vector)->driver->close
> >>
> >> (gdb) p ((struct font *) vector)->driver
> >> $4 = (struct font_driver *) 0x0
> >> (gdb) p ((struct font *) vector)->driver->close
> >> Cannot access memory at address 0x40
> >
> > IOW, the font driver is NULL.
>
> Could that be due to my typing `C-g'?
It evidently is. My current theory is that the font driver was not
fully set up, before Emacs got interrupted by C-g.
> If I don't do that, the file does get displayed. But `C-g'
> shouldn't make Emacs crash. Do you see what the problem is, or can
> I provide further information?
The immediate problem is clearly that we dereference a NULL pointer.
I installed a trivial workaround for that in r117235 on the emacs-24
branch. The diffs are below. Can you try this and see if the problem
is solved? It's possible that the real problem is somewhere else, in
which case you will probably see it when you apply the patch.
Thanks.
=== modified file 'src/alloc.c'
--- src/alloc.c 2014-05-30 20:19:29 +0000
+++ src/alloc.c 2014-06-13 13:53:24 +0000
@@ -2924,9 +2924,16 @@ cleanup_vector (struct Lisp_Vector *vect
&& ((vector->header.size & PSEUDOVECTOR_SIZE_MASK)
== FONT_OBJECT_MAX))
{
- /* Attempt to catch subtle bugs like Bug#16140. */
- eassert (valid_font_driver (((struct font *) vector)->driver));
- ((struct font *) vector)->driver->close ((struct font *) vector);
+ struct font_driver *drv = ((struct font *) vector)->driver;
+
+ /* The font driver might sometimes be NULL, e.g. if Emacs was
+ interrupted before it had time to set it up. */
+ if (drv)
+ {
+ /* Attempt to catch subtle bugs like Bug#16140. */
+ eassert (valid_font_driver (drv));
+ drv->close ((struct font *) vector);
+ }
}
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 14:15:04 GMT)
Full text and
rfc822 format available.
Message #35 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Fri, 13 Jun 2014 16:58:32 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> > IOW, the font driver is NULL.
>>
>> Could that be due to my typing `C-g'?
>
> It evidently is. My current theory is that the font driver was not
> fully set up, before Emacs got interrupted by C-g.
>
>> If I don't do that, the file does get displayed. But `C-g'
>> shouldn't make Emacs crash. Do you see what the problem is, or can
>> I provide further information?
>
> The immediate problem is clearly that we dereference a NULL pointer.
>
> I installed a trivial workaround for that in r117235 on the emacs-24
> branch. The diffs are below. Can you try this and see if the problem
> is solved? It's possible that the real problem is somewhere else, in
> which case you will probably see it when you apply the patch.
With the patch, Emacs still crashes with the same recipe, but the first
frame of backtrace is different (looks like not in Emacs):
Program received signal SIGSEGV, Segmentation fault.
0x0000000000c260b2 in ?? ()
(gdb) bt full
#0 0x0000000000c260b2 in ?? ()
No symbol table info available.
#1 0x00000000005aa580 in cleanup_vector (vector=0x3dd52c8)
at ../../../../bzr/emacs/emacs-24/src/alloc.c:2935
drv = 0x3dd5130
#2 0x00000000005aa686 in sweep_vectors ()
at ../../../../bzr/emacs/emacs-24/src/alloc.c:2974
total_bytes = 140737488344592
free_this_block = false
nbytes = 1048
block = 0x3dd4680
bprev = 0xbf1060
lv = 0x6282a3 <balance_intervals+31>
lvprev = 0xbf2070
vector = 0x3dd52c8
next = 0x3dd52c8
#3 0x00000000005b0141 in gc_sweep () at ../../../../bzr/emacs/emacs-24/src/alloc.c:6721
No locals.
#4 0x00000000005ae1ac in Fgarbage_collect ()
at ../../../../bzr/emacs/emacs-24/src/alloc.c:5650
nextb = 0x0
stack_top_variable = 0 '\000'
i = 1619
message_p = true
count = 3
start = {tv_sec = 1402668198, tv_nsec = 144021215}
retval = 12738738
tot_before = 0
#5 0x00000000005374b1 in maybe_gc () at ../../../../bzr/emacs/emacs-24/src/lisp.h:4564
No locals.
#6 0x00000000005cda00 in Ffuncall (nargs=4, args=0x7fffffffd970)
at ../../../../bzr/emacs/emacs-24/src/eval.c:2766
fun = 5936534
original_fun = 140737488345376
funcar = 12765552
numargs = 3
lisp_numargs = 9258817
---Type <return> to continue, or q <return> to quit---
val = 140737488345424
internal_args = 0xc260b2
i = 9258817
#7 0x00000000005cd6f2 in call3 (fn=12786194, arg1=20004262, arg2=9258817, arg3=12738738)
at ../../../../bzr/emacs/emacs-24/src/eval.c:2645
ret_ungc_val = 140737488345600
gcpro1 = {next = 0x7fffffffd9b0, var = 0x53738f <build_string+42>, nvars = 4}
args = {12786194, 20004262, 9258817, 12738738}
#8 0x000000000053ccef in cmd_error_internal (data=20004262, context=0x7fffffffda00 "")
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1085
No locals.
#9 0x000000000053cc13 in cmd_error (data=20004262)
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1054
old_level = 12738738
old_length = 12738738
macroerror = "\000`\302\000\000\000\000\000F_|\001\000\000\000\000\002\000\000\000\000\000\000\000\262`\302\000\000\000\000\000\000\000\000\000\002", '\000' <repeats 11 times>, <incomplete sequence \332>
#10 0x00000000005caba1 in internal_condition_case (bfun=0x53d1ab <command_loop_1>,
handlers=12790306, hfun=0x53cabd <cmd_error>)
at ../../../../bzr/emacs/emacs-24/src/eval.c:1351
val = 20004262
val = 5492514
c = 0x13d5810
#11 0x000000000053cf05 in command_loop_2 (ignore=12738738)
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1177
val = 0
#12 0x00000000005ca3bb in internal_catch (tag=12786242, func=0x53cedf <command_loop_2>,
arg=12738738) at ../../../../bzr/emacs/emacs-24/src/eval.c:1118
val = 12738738
c = 0x13d5630
#13 0x000000000053ceb3 in command_loop ()
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:1156
No locals.
#14 0x000000000053c6b8 in recursive_edit_1 ()
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:777
count = 1
---Type <return> to continue, or q <return> to quit---
val = 12738738
#15 0x000000000053c825 in Frecursive_edit ()
at ../../../../bzr/emacs/emacs-24/src/keyboard.c:848
count = 0
buffer = 12738738
#16 0x000000000053a857 in main (argc=2, argv=0x7fffffffdd98)
at ../../../../bzr/emacs/emacs-24/src/emacs.c:1646
dummy = 140737354130592
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7ffff7ffe148 ""
original_pwd = 0x0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Fri, 13 Jun 2014 14:53:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 17771 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 17771 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2014 16:13:42 +0200
>
> > I installed a trivial workaround for that in r117235 on the emacs-24
> > branch. The diffs are below. Can you try this and see if the problem
> > is solved? It's possible that the real problem is somewhere else, in
> > which case you will probably see it when you apply the patch.
>
> With the patch, Emacs still crashes with the same recipe, but the first
> frame of backtrace is different (looks like not in Emacs):
I think it's just a bogus pointer to the font driver, and somehow
valid_font_driver doesn't catch it in time.
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000c260b2 in ?? ()
> (gdb) bt full
> #0 0x0000000000c260b2 in ?? ()
> No symbol table info available.
> #1 0x00000000005aa580 in cleanup_vector (vector=0x3dd52c8)
> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2935
> drv = 0x3dd5130
> #2 0x00000000005aa686 in sweep_vectors ()
> at ../../../../bzr/emacs/emacs-24/src/alloc.c:2974
> total_bytes = 140737488344592
> free_this_block = false
> nbytes = 1048
> block = 0x3dd4680
> bprev = 0xbf1060
> lv = 0x6282a3 <balance_intervals+31>
> lvprev = 0xbf2070
> vector = 0x3dd52c8
> next = 0x3dd52c8
> #3 0x00000000005b0141 in gc_sweep () at ../../../../bzr/emacs/emacs-24/src/alloc.c:6721
So Dmitry, I think Stephen here just found you a perfect recipe to
reproduce bug #16140, something that I failed to do. Could you please
look into this?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 08:03:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 17771 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/13/2014 06:52 PM, Eli Zaretskii wrote:
> So Dmitry, I think Stephen here just found you a perfect recipe to
> reproduce bug #16140, something that I failed to do. Could you please
> look into this?
Reproduced. My machine looks much faster so I'm not sure it's always
possible to hit C-g in time; anyway, this simple fix just works for me.
Dmitry
[bug17771.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 10:18:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Mon, 16 Jun 2014 12:02:21 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/13/2014 06:52 PM, Eli Zaretskii wrote:
>
>> So Dmitry, I think Stephen here just found you a perfect recipe to
>> reproduce bug #16140, something that I failed to do. Could you please
>> look into this?
>
> Reproduced. My machine looks much faster so I'm not sure it's always
> possible to hit C-g in time;
How long does it take for HELLO to be displayed on your machine? Do you
have time to type `C-g' numerous times? For me to get the crash, it's
not sufficient to type it just once or twice or maybe even three times
(I think the latter worked once in testing, but just now it didn't;
maybe I started too late or too soon.)
> anyway, this simple fix just works for me.
Unfortunately, I still get the same crash. Does it matter that I the
emacs-24 source I applied your patch to includes Eli's patch to alloc.c?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 12:38:04 GMT)
Full text and
rfc822 format available.
Message #47 received at 17771 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/16/2014 02:16 PM, Stephen Berman wrote:
> How long does it take for HELLO to be displayed on your machine?
No more than 1s, I think.
> Do you have time to type `C-g' numerous times?
Hopefully yes.
> Unfortunately, I still get the same crash. Does it matter that I the
> emacs-24 source I applied your patch to includes Eli's patch to alloc.c?
Yes.
Perhaps font->driver must be set to NULL earlier, immediately after
allocation? Try this.
Dmitry
[bug17771_2.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 13:09:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Mon, 16 Jun 2014 16:37:04 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
>> Unfortunately, I still get the same crash. Does it matter that I the
>> emacs-24 source I applied your patch to includes Eli's patch to alloc.c?
>
> Yes.
I take it you mean it *doesn't* matter; anyway, I left Eli's patch in
again, and...
> Perhaps font->driver must be set to NULL earlier, immediately after
> allocation? Try this.
With this I can no longer make Emacs crash with my recipe. In fact,
`C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
how many times I type `C-g'. Is this what you expect?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 13:20:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/16/2014 05:07 PM, Stephen Berman wrote:
> With this I can no longer make Emacs crash with my recipe. In fact,
> `C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
> how many times I type `C-g'. Is this what you expect?
No, 30+s is just unbelievable. What is your hardware? While you're waiting
for HELLO to be displayed, what's Emacs CPU consumption is?
If it's more than, say, 10%, could you profile? Compile with -g or -g3 and run with:
perf record -e cycles,stalled-cycles-frontend,idle-cycles-frontend -F 1000 ./src/emacs -Q
then C-h h, then exit immediately after HELLO is displayed, and finally
perf report --stdio
If CPU consumption is just slightly above zero, try to run with 'strace -ttt'
and check whether you're sleeping or blocked inside a system call.
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 13:34:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 17771 <at> debbugs.gnu.org (full text, mbox):
Dmitry Antipov <dmantipov <at> yandex.ru> writes:
> On 06/16/2014 05:07 PM, Stephen Berman wrote:
>
>> With this I can no longer make Emacs crash with my recipe. In fact,
>> `C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
>> how many times I type `C-g'. Is this what you expect?
>
> No, 30+s is just unbelievable.
If you have many fonts installed it can take a lot of time to find out
that a character cannot be displayed.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 15:51:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Mon, 16 Jun 2014 17:19:24 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/16/2014 05:07 PM, Stephen Berman wrote:
>
>> With this I can no longer make Emacs crash with my recipe. In fact,
>> `C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
>> how many times I type `C-g'. Is this what you expect?
>
> No, 30+s is just unbelievable. What is your hardware?
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 95
model name : AMD Sempron(tm) Processor 3400+
stepping : 2
cpu MHz : 1000.000
cache size : 256 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm extapic cr8_legacy
bogomips : 2010.01
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
and 4 GiB RAM
> While you're waiting
> for HELLO to be displayed, what's Emacs CPU consumption is?
Mostly ~97%
> If it's more than, say, 10%, could you profile?
I don't have perf installed, but in the mean time, I tried the Emacs
profiler:
+ command-execute 529 47%
+ redisplay_internal (C function) 290 26%
+ ... 284 25%
+ timer-event-handler 8 0%
Expanded:
- command-execute 529 47%
- call-interactively 529 47%
- view-hello-file 312 28%
- view-file 307 27%
- find-file-noselect 300 27%
- find-file-noselect-1 296 26%
- after-find-file 195 17%
- run-hooks 186 16%
- vc-find-file-hook 186 16%
- vc-backend 98 8%
- vc-registered 98 8%
- byte-code 98 8%
- mapc 98 8%
- #<compiled 0x2a0211> 98 8%
- vc-call-backend 98 8%
- apply 98 8%
- vc-bzr-registered 96 8%
- if 96 8%
- progn 96 8%
- vc-bzr-registered 87 7%
- vc-bzr-state-heuristic 87 7%
- funcall 86 7%
- #<compiled 0x478c37> 86 7%
+ vc-bzr-sha1 2 0%
+ vc-bzr-root 1 0%
+ load 2 0%
+ vc-cvs-registered 1 0%
+ vc-sccs-registered 1 0%
+ vc-mode-line 88 7%
+ normal-mode 9 0%
- funcall 101 9%
#<compiled 0x47b487> 101 9%
+ find-buffer-visiting 2 0%
abbreviate-file-name 1 0%
+ create-file-buffer 1 0%
+ file-truename 2 0%
+ view-buffer 2 0%
+ defvar 1 0%
- byte-code 127 11%
- read-extended-command 127 11%
- completing-read 127 11%
- completing-read-default 127 11%
- read-from-minibuffer 95 8%
+ minibuffer-inactive-mode 2 0%
+ redisplay_internal (C function) 2 0%
+ timer-event-handler 1 0%
+ execute-extended-command 45 4%
+ minibuffer-complete 45 4%
- redisplay_internal (C function) 290 26%
- auto-compose-chars 280 25%
- thai-composition-function 184 16%
- require 161 14%
- defvar 160 14%
- byte-code 154 13%
+ set-nested-alist 16 1%
+ file-truename 1 0%
+ byte-code 3 0%
- lao-composition-function 75 6%
- byte-code 70 6%
- put-char-code-property 70 6%
- unicode-property-table-internal 65 5%
- load-with-code-conversion 65 5%
+ insert-file-contents 2 0%
+ eval-buffer 2 0%
do-after-load-evaluation 1 0%
+ #<compiled 0xc8343b> 3 0%
+ defconst 3 0%
+ file-truename 1 0%
+ and 5 0%
+ tool-bar-make-keymap 3 0%
#<compiled 0x423ffb> 1 0%
- ... 284 25%
Automatic GC 284 25%
+ timer-event-handler 8 0%
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 15:51:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Mon, 16 Jun 2014 15:32:48 +0200 Andreas Schwab <schwab <at> suse.de> wrote:
> Dmitry Antipov <dmantipov <at> yandex.ru> writes:
>
>> On 06/16/2014 05:07 PM, Stephen Berman wrote:
>>
>>> With this I can no longer make Emacs crash with my recipe. In fact,
>>> `C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
>>> how many times I type `C-g'. Is this what you expect?
>>
>> No, 30+s is just unbelievable.
>
> If you have many fonts installed it can take a lot of time to find out
> that a character cannot be displayed.
$ xlsfonts | wc -l
6254
Is that all fonts, or if not, how do I get a total count (this is
openSUSE 13.1)? Does this number (or the actual number) seem likely to
account for the time, given my hardware (see my followup to Dmitry)?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 16:04:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/16/2014 07:49 PM, Stephen Berman wrote:
> cpu MHz : 1000.000
> and 4 GiB RAM
This should be pretty enough.
> Mostly ~97%
Then you should profile with perf.
> I don't have perf installed
Just ask your package management tool to install 'perf'. Any
reasonably configured tool should install perf version matching
your currently running kernel by default.
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 16:22:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/16/2014 07:49 PM, Stephen Berman wrote:
> $ xlsfonts | wc -l
> 6254
Hm... my system has just 3830.
> Is that all fonts, or if not, how do I get a total count (this is
> openSUSE 13.1)?
Good question. IIUC, xlsfonts shows only server-side fonts; you also
have to run fc-list to see fonts managed by fontconfig and so available
for client-side libXft-based rendering.
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 21:35:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 17771 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 16 Jun 2014 20:03:22 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/16/2014 07:49 PM, Stephen Berman wrote:
>
>> cpu MHz : 1000.000
>> and 4 GiB RAM
>
> This should be pretty enough.
>
>> Mostly ~97%
>
> Then you should profile with perf.
I've now done that. Here are the top five entries; the whole gzipped
output is attached.
# Samples: 26K of event 'cycles'
# Event count (approx.): 47032351373
#
# Overhead Command Shared Object Symbol
# ........ ....... ............................. ..............................
#
36.00% emacs libfontconfig.so.1.8.0 [.] 0x000000000001f643
31.34% emacs libc-2.18.so [.] __strchr_sse2
6.78% emacs [kernel.kallsyms] [k] 0xffffffff8103aef6
4.12% emacs libz.so.1.2.8 [.] 0x0000000000007cc6
1.15% emacs libfontconfig.so.1.8.0 [.] FcCharSetSubtractCount
I don't know if it's significant, but when I ran perf, it gave the
following warnings:
[kernel.kallsyms] with build id d1a714bf3876cc6850d48a51a4f68be7e418e864 not found, continuing without symbols
Warning:
Kernel address maps (/proc/{kallsyms,modules}) were restricted.
Check /proc/sys/kernel/kptr_restrict before running 'perf record'.
As no suitable kallsyms nor vmlinux was found, kernel samples
can't be resolved.
Samples in kernel modules can't be resolved as well.
Steve Berman
[perf.out.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Mon, 16 Jun 2014 21:35:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Mon, 16 Jun 2014 20:21:44 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/16/2014 07:49 PM, Stephen Berman wrote:
>
>> $ xlsfonts | wc -l
>> 6254
>
> Hm... my system has just 3830.
>
>> Is that all fonts, or if not, how do I get a total count (this is
>> openSUSE 13.1)?
>
> Good question. IIUC, xlsfonts shows only server-side fonts; you also
> have to run fc-list to see fonts managed by fontconfig and so available
> for client-side libXft-based rendering.
$ fc-list | wc -l
2889
It looks like there's considerable overlap between the xlsfonts and
fc-list outputs, e.g. xlsfonts lists
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1
and fc-list has
/usr/share/fonts/75dpi/courO10-ISO8859-1.pcf.gz: Adobe Courier:style=Oblique
Are they the same font? (If not, maybe I picked the wrong pair, there
are lots of similar pairs.)
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Tue, 17 Jun 2014 02:10:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/17/2014 01:33 AM, Stephen Berman wrote:
> 36.00% emacs libfontconfig.so.1.8.0 [.] 0x000000000001f643
> 31.34% emacs libc-2.18.so [.] __strchr_sse2
> 6.78% emacs [kernel.kallsyms] [k] 0xffffffff8103aef6
> 4.12% emacs libz.so.1.2.8 [.] 0x0000000000007cc6
> 1.15% emacs libfontconfig.so.1.8.0 [.] FcCharSetSubtractCount
Please also install fontconfig-debuginfo package to get all libfontconfig.so
samples resolved to function names.
Just for the record, I'm seeing the following:
6.68% emacs libc-2.18.so [.] _IO_getc
3.90% emacs emacs [.] mark_object
2.73% emacs emacs [.] decode_coding_iso_2022
2.46% emacs emacs [.] exec_byte_code
1.76% emacs libgobject-2.0.so.0.3800.2 [.] g_type_check_instance_is_a
1.65% emacs ld-2.18.so [.] do_lookup_x
1.31% emacs libglib-2.0.so.0.3800.2 [.] g_private_get_impl
1.29% emacs libc-2.18.so [.] __strchr_sse2
1.29% emacs libfontconfig.so.1.8.0 [.] FcCompareFamily
1.22% emacs libc-2.18.so [.] _int_malloc
1.20% emacs libX11.so.6.3.0 [.] parsestringfile
1.19% emacs emacs [.] mark_char_table
1.18% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext.part.3
1.17% emacs libfontconfig.so.1.8.0 [.] __popcountdi2
1.12% emacs libglib-2.0.so.0.3800.2 [.] g_mutex_get_impl
1.02% emacs libc-2.18.so [.] malloc
Probably there is a bottleneck in fontconfig which can't scale from hundreds to
thousands of fonts well enough.
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Tue, 17 Jun 2014 02:26:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/17/2014 01:34 AM, Stephen Berman wrote:
> $ fc-list | wc -l
> 2889
Oops, really a lot of them. I have just 247.
> It looks like there's considerable overlap between the xlsfonts and
> fc-list outputs, e.g. xlsfonts lists
>
> -adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1
>
> and fc-list has
>
> /usr/share/fonts/75dpi/courO10-ISO8859-1.pcf.gz: Adobe Courier:style=Oblique
>
> Are they the same font?
Hm...not sure.
How many fonts are shown by Emacs? This may be obtained by
(length (x-list-fonts "*"))
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Tue, 17 Jun 2014 13:42:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Tue, 17 Jun 2014 06:25:07 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/17/2014 01:34 AM, Stephen Berman wrote:
>
>> $ fc-list | wc -l
>> 2889
>
> Oops, really a lot of them. I have just 247.
FWIW, 1785 of those listed by fc-list are texlive fonts.
>> It looks like there's considerable overlap between the xlsfonts and
>> fc-list outputs, e.g. xlsfonts lists
>>
>> -adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1
>>
>> and fc-list has
>>
>> /usr/share/fonts/75dpi/courO10-ISO8859-1.pcf.gz: Adobe Courier:style=Oblique
>>
>> Are they the same font?
>
> Hm...not sure.
>
> How many fonts are shown by Emacs? This may be obtained by
>
> (length (x-list-fonts "*"))
Same as fc-list, 2889.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Tue, 17 Jun 2014 13:43:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Tue, 17 Jun 2014 06:09:26 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/17/2014 01:33 AM, Stephen Berman wrote:
>
>> 36.00% emacs libfontconfig.so.1.8.0 [.] 0x000000000001f643
>> 31.34% emacs libc-2.18.so [.] __strchr_sse2
>> 6.78% emacs [kernel.kallsyms] [k] 0xffffffff8103aef6
>> 4.12% emacs libz.so.1.2.8 [.] 0x0000000000007cc6
>> 1.15% emacs libfontconfig.so.1.8.0 [.] FcCharSetSubtractCount
>
> Please also install fontconfig-debuginfo package to get all libfontconfig.so
> samples resolved to function names.
>
> Just for the record, I'm seeing the following:
>
> 6.68% emacs libc-2.18.so [.] _IO_getc
> 3.90% emacs emacs [.] mark_object
> 2.73% emacs emacs [.] decode_coding_iso_2022
> 2.46% emacs emacs [.] exec_byte_code
> 1.76% emacs libgobject-2.0.so.0.3800.2 [.] g_type_check_instance_is_a
> 1.65% emacs ld-2.18.so [.] do_lookup_x
> 1.31% emacs libglib-2.0.so.0.3800.2 [.] g_private_get_impl
> 1.29% emacs libc-2.18.so [.] __strchr_sse2
> 1.29% emacs libfontconfig.so.1.8.0 [.] FcCompareFamily
> 1.22% emacs libc-2.18.so [.] _int_malloc
> 1.20% emacs libX11.so.6.3.0 [.] parsestringfile
> 1.19% emacs emacs [.] mark_char_table
> 1.18% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext.part.3
> 1.17% emacs libfontconfig.so.1.8.0 [.] __popcountdi2
> 1.12% emacs libglib-2.0.so.0.3800.2 [.] g_mutex_get_impl
> 1.02% emacs libc-2.18.so [.] malloc
>
> Probably there is a bottleneck in fontconfig which can't scale from hundreds to
> thousands of fonts well enough.
With fontconfig-debuginfo installed I get this:
33.61% emacs libc-2.18.so [.] __strchr_sse2
15.77% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext.part.3
4.75% emacs [kernel.kallsyms] [k] 0xffffffff8103aef6
4.21% emacs libz.so.1.2.8 [.] 0x0000000000007b2d
4.18% emacs libfontconfig.so.1.8.0 [.] FcPatternObjectPosition
2.91% emacs libfontconfig.so.1.8.0 [.] __popcountdi2
2.47% emacs libfontconfig.so.1.8.0 [.] FcStrCmpIgnoreCaseAndDelim
1.95% emacs libfontconfig.so.1.8.0 [.] FcConfigPromote.isra.0
1.79% emacs libfontconfig.so.1.8.0 [.] FcListPatternMatchAny
1.63% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext
1.05% emacs libfontconfig.so.1.8.0 [.] FcCharSetSubtractCount
1.00% emacs libfontconfig.so.1.8.0 [.] FcConfigCompareValue
0.87% emacs libfontconfig.so.1.8.0 [.] FcValueCanonicalize
0.85% emacs libc-2.18.so [.] memset
0.83% emacs libfontconfig.so.1.8.0 [.] FcCompareValueList
0.76% emacs libfontconfig.so.1.8.0 [.] strchr <at> plt
0.73% emacs libfreetype.so.6.10.2 [.] 0x000000000005f039
0.66% emacs libfreetype.so.6.10.2 [.] FT_Stream_ReadFields
0.63% emacs emacs [.] hash_string
0.58% emacs emacs [.] mark_object
0.58% emacs libz.so.1.2.8 [.] inflate
0.52% emacs emacs [.] sxhash_combine
0.51% emacs libfontconfig.so.1.8.0 [.] FcPatternObjectFindElt
0.50% emacs libfontconfig.so.1.8.0 [.] FcFontSetList
0.48% emacs emacs [.] ftfont_get_fc_charset
0.46% emacs libc-2.18.so [.] __memcpy_sse2_unaligned
0.43% emacs libfontconfig.so.1.8.0 [.] FcCompareFamily
0.42% emacs libfontconfig.so.1.8.0 [.] FcCharSetFindLeafForwar
0.41% emacs libc-2.18.so [.] _int_malloc
Let me know if you want the whole output.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Tue, 17 Jun 2014 18:12:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/17/2014 05:41 PM, Stephen Berman wrote:
> With fontconfig-debuginfo installed I get this:
>
> 33.61% emacs libc-2.18.so [.] __strchr_sse2
> 15.77% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext.part.3
OK. Next steps probably are:
1) Compile with '--with-x-toolkit=lucid --without-xft'
and check how fast HELLO is displayed.
2) Identify all font packages installed. I don't know about SuSE,
but on my Fedora system all font packages are under 'User Interface/X'
group, so "rpm -q -g 'User Interface/X'" shows all font packages
(plus other X stuff, which may be filtered out by grepping for "noarch"
packages). On my system, the following command:
rpm -q -g 'User Interface/X' | grep noarch | grep font | wc -l
shows 84 font packages.
3) Save list of packages obtained at step 2) and try to uninstall the most
of font packages (but do not touch X core fonts - xorg-x11-fonts-* packages
on my system). Next try to run "regular" (with Xft support enabled) Emacs
and check whether font removal helps to speedup C-h h.
4) Reinstall all required fonts.
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 12:56:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jun 16 2014, Andreas Schwab wrote:
> Dmitry Antipov <dmantipov <at> yandex.ru> writes:
>
>> On 06/16/2014 05:07 PM, Stephen Berman wrote:
>>
>>> With this I can no longer make Emacs crash with my recipe. In fact,
>>> `C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
>>> how many times I type `C-g'. Is this what you expect?
>>
>> No, 30+s is just unbelievable.
>
> If you have many fonts installed it can take a lot of time to find out
> that a character cannot be displayed.
So, expanding on Andreas' remark, perhaps just bisect HELLO to find out
if there is some particular script that causes trouble?
You could then try to use `set-fontset-font' to specify a particular
font for the problematic script or character range.
Wolfgang
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 13:51:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Tue, 17 Jun 2014 22:11:43 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/17/2014 05:41 PM, Stephen Berman wrote:
>
>> With fontconfig-debuginfo installed I get this:
>>
>> 33.61% emacs libc-2.18.so [.] __strchr_sse2
>> 15.77% emacs libfontconfig.so.1.8.0 [.] FcStrCaseWalkerNext.part.3
>
> OK. Next steps probably are:
>
> 1) Compile with '--with-x-toolkit=lucid --without-xft'
> and check how fast HELLO is displayed.
This failed to compile:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: image.o: undefined reference to symbol 'png_set_longjmp_fn@@PNG16_0'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: note: 'png_set_longjmp_fn@@PNG16_0' is defined in DSO /usr/lib64/libpng16.so.16 so try adding it to the linker command line
/usr/lib64/libpng16.so.16: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/data/steve/lib/emacs/emacs-24.4-lucid/src'
make: *** [src] Error 2
I have both libpng16 and libpng12 installed, since each is required by
different programs I use. Emacs built with Gtk+ links with libpng16
(which gtk3 requires), but with Lucid it apparently links with libpng12
if installed. It would be a PITA to uninstall libpng12 just to test
this. However, when I add `--without-png' to the configure line, then
Emacs with Lucid and without xft successfully builds. And with this
build it takes only about 3 seconds for HELLO to be displayed (with the
characters for which no suitable font could be found displayed as boxes
containing the hex codepoint).
Then I built with gtk3 and without xft, and here, too, it takes only
about 3 seconds for HELLO to be displayed.
> 2) Identify all font packages installed. I don't know about SuSE,
> but on my Fedora system all font packages are under 'User Interface/X'
> group, so "rpm -q -g 'User Interface/X'" shows all font packages
> (plus other X stuff, which may be filtered out by grepping for "noarch"
> packages). On my system, the following command:
>
> rpm -q -g 'User Interface/X' | grep noarch | grep font | wc -l
>
> shows 84 font packages.
>
> 3) Save list of packages obtained at step 2) and try to uninstall the most
> of font packages (but do not touch X core fonts - xorg-x11-fonts-* packages
> on my system). Next try to run "regular" (with Xft support enabled) Emacs
> and check whether font removal helps to speedup C-h h.
>
> 4) Reinstall all required fonts.
I took the opposite route, which was easier for me: I installed font
packages for all the languages that were displayed as hex codepoint
boxes (mainly South Asia and South East Asia). And lo and behold, now
with my normal build (including Xft support), it also takes only about 3
seconds for HELLO to be displayed (and there are no more hex codepoint
boxes)!
Prior to this, I had installed font packages for all languages in HELLO,
but still some characters in Tibetan were only displayed as hex
codepoint boxes. And it still took 30+ seconds for HELLO to be
displayed. But I found another font package for Tibetan which contained
the missing characters, and that made the difference. So probably the
lag was just due the searching through all fonts, as Andreas said.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 13:52:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Wed, 18 Jun 2014 14:54:55 +0200 Wolfgang Jenkner <wjenkner <at> inode.at> wrote:
> On Mon, Jun 16 2014, Andreas Schwab wrote:
>
>> Dmitry Antipov <dmantipov <at> yandex.ru> writes:
>>
>>> On 06/16/2014 05:07 PM, Stephen Berman wrote:
>>>
>>>> With this I can no longer make Emacs crash with my recipe. In fact,
>>>> `C-g' has no effect: HELLO is displayed (after 30+ seconds), no matter
>>>> how many times I type `C-g'. Is this what you expect?
>>>
>>> No, 30+s is just unbelievable.
>>
>> If you have many fonts installed it can take a lot of time to find out
>> that a character cannot be displayed.
>
> So, expanding on Andreas' remark, perhaps just bisect HELLO to find out
> if there is some particular script that causes trouble?
I understood Andreas to be saying that looking for something that's not
there can take longer than finding something that is there, and this
indeed seems to be the case, as my latest followup to Dmitry suggests:
when all characters can be displayed, HELLO display quite quickly.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 14:02:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/18/2014 05:50 PM, Stephen Berman wrote:
> I understood Andreas to be saying that looking for something that's not
> there can take longer than finding something that is there, and this
> indeed seems to be the case, as my latest followup to Dmitry suggests:
> when all characters can be displayed, HELLO display quite quickly.
Good news.
So what about crash in cleanup_vector? Could you confirm that the patch
from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17771#47 is helpful?
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 16:01:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Wed, 18 Jun 2014 18:01:12 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/18/2014 05:50 PM, Stephen Berman wrote:
>
>> I understood Andreas to be saying that looking for something that's not
>> there can take longer than finding something that is there, and this
>> indeed seems to be the case, as my latest followup to Dmitry suggests:
>> when all characters can be displayed, HELLO display quite quickly.
>
> Good news.
>
> So what about crash in cleanup_vector? Could you confirm that the patch
> from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17771#47 is helpful?
As I said in my followup to your patch, it did indeed prevent Emacs from
crashing, but with it C-g could not interrupt HELLO being displayed.
Now, with your patch and all the fonts needed to correctly display
HELLO, I still cannot reproduce the crash, though if I type `C-h h' and
then repeatedly and rapidly type `C-g', this slows downs the display of
HELLO from ~3 to ~9 seconds. But without your patch, I still get the
crash.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 16:25:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On 06/18/2014 08:00 PM, Stephen Berman wrote:
> As I said in my followup to your patch, it did indeed prevent Emacs from
> crashing, but with it C-g could not interrupt HELLO being displayed.
This can be explained. To process C-g, C code should call QUIT. If we
compare it with OS, this is something like "check for pending interrupts
and process them if needed". That's why, for example, (make-list 10000000 0)
can be interrupted with C-g. Emacs do QUIT in its own C code, but it's
impossible to arrange QUIT in external library. So, if there is a
very busy loop somewhere in fontconfig, you can't interrupt it with C-g.
Dmitry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17771; Package
emacs.
(Wed, 18 Jun 2014 17:02:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 17771 <at> debbugs.gnu.org (full text, mbox):
On Wed, 18 Jun 2014 20:24:21 +0400 Dmitry Antipov <dmantipov <at> yandex.ru> wrote:
> On 06/18/2014 08:00 PM, Stephen Berman wrote:
>
>> As I said in my followup to your patch, it did indeed prevent Emacs from
>> crashing, but with it C-g could not interrupt HELLO being displayed.
>
> This can be explained. To process C-g, C code should call QUIT. If we
> compare it with OS, this is something like "check for pending interrupts
> and process them if needed". That's why, for example, (make-list 10000000 0)
> can be interrupted with C-g. Emacs do QUIT in its own C code, but it's
> impossible to arrange QUIT in external library. So, if there is a
> very busy loop somewhere in fontconfig, you can't interrupt it with C-g.
I see. Well, having Emacs crash is certainly worse than not being able
to interrupt fontconfig, so I think you should commit the patch, and
then as far as I'm concerned, this bug can be closed.
Steve Berman
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Tue, 12 Aug 2014 04:00:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stephen Berman <stephen.berman <at> gmx.net>:
bug acknowledged by developer.
(Tue, 12 Aug 2014 04:00:05 GMT)
Full text and
rfc822 format available.
Message #117 received at 17771-done <at> debbugs.gnu.org (full text, mbox):
Version: 24.3.93
Stephen Berman wrote:
> I see. Well, having Emacs crash is certainly worse than not being able
> to interrupt fontconfig, so I think you should commit the patch, and
> then as far as I'm concerned, this bug can be closed.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Tue, 12 Aug 2014 04:00:06 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eli Zaretskii <eliz <at> gnu.org>:
bug acknowledged by developer.
(Tue, 12 Aug 2014 04:00:07 GMT)
Full text and
rfc822 format available.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Tue, 12 Aug 2014 04:00:08 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Tue, 12 Aug 2014 04:00:08 GMT)
Full text and
rfc822 format available.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Tue, 12 Aug 2014 04:00:09 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Tue, 12 Aug 2014 04:00:09 GMT)
Full text and
rfc822 format available.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Tue, 12 Aug 2014 04:00:10 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Tue, 12 Aug 2014 04:00:10 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 09 Sep 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 254 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.