unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
@ 2014-06-13  9:12 Stephen Berman
  2014-06-13  9:41 ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-13  9:12 UTC (permalink / raw)
  To: 17771


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@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)





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13  9:12 bug#17771: 24.3.91; SIGSEGV in cleanup_vector Stephen Berman
@ 2014-06-13  9:41 ` Eli Zaretskii
  2014-06-13  9:50   ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2014-06-13  9:41 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

> From: Stephen Berman <stephen.berman@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?





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13  9:41 ` Eli Zaretskii
@ 2014-06-13  9:50   ` Stephen Berman
  2014-06-13 12:19     ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-13  9:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17771

On Fri, 13 Jun 2014 12:41:56 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13  9:50   ` Stephen Berman
@ 2014-06-13 12:19     ` Eli Zaretskii
  2014-06-13 12:39       ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2014-06-13 12:19 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 17771@debbugs.gnu.org
> Date: Fri, 13 Jun 2014 11:50:59 +0200
> 
> On Fri, 13 Jun 2014 12:41:56 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 12:19     ` Eli Zaretskii
@ 2014-06-13 12:39       ` Stephen Berman
  2014-06-13 13:28         ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-13 12:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17771

On Fri, 13 Jun 2014 15:19:50 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 17771@debbugs.gnu.org
>> Date: Fri, 13 Jun 2014 11:50:59 +0200
>> 
>> On Fri, 13 Jun 2014 12:41:56 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> >> From: Stephen Berman <stephen.berman@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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 12:39       ` Stephen Berman
@ 2014-06-13 13:28         ` Eli Zaretskii
  2014-06-13 13:34           ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2014-06-13 13:28 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 17771@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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 13:28         ` Eli Zaretskii
@ 2014-06-13 13:34           ` Stephen Berman
  2014-06-13 13:44             ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-13 13:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17771

On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 17771@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 13:34           ` Stephen Berman
@ 2014-06-13 13:44             ` Eli Zaretskii
  2014-06-13 13:53               ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2014-06-13 13:44 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 17771@debbugs.gnu.org
> Date: Fri, 13 Jun 2014 15:34:12 +0200
> 
> On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> Cc: 17771@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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 13:44             ` Eli Zaretskii
@ 2014-06-13 13:53               ` Stephen Berman
  2014-06-13 13:58                 ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-13 13:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17771

On Fri, 13 Jun 2014 16:44:39 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 17771@debbugs.gnu.org
>> Date: Fri, 13 Jun 2014 15:34:12 +0200
>> 
>> On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> >> From: Stephen Berman <stephen.berman@gmx.net>
>> >> Cc: 17771@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 13:53               ` Stephen Berman
@ 2014-06-13 13:58                 ` Eli Zaretskii
  2014-06-13 14:13                   ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2014-06-13 13:58 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 17771@debbugs.gnu.org
> Date: Fri, 13 Jun 2014 15:53:35 +0200
> 
> On Fri, 13 Jun 2014 16:44:39 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> Cc: 17771@debbugs.gnu.org
> >> Date: Fri, 13 Jun 2014 15:34:12 +0200
> >> 
> >> On Fri, 13 Jun 2014 16:28:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> >> 
> >> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> >> Cc: 17771@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);
+	}
     }
 }
 






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 13:58                 ` Eli Zaretskii
@ 2014-06-13 14:13                   ` Stephen Berman
  2014-06-13 14:52                     ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-13 14:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17771

On Fri, 13 Jun 2014 16:58:32 +0300 Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 14:13                   ` Stephen Berman
@ 2014-06-13 14:52                     ` Eli Zaretskii
  2014-06-16  8:02                       ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2014-06-13 14:52 UTC (permalink / raw)
  To: Stephen Berman, Dmitry Antipov; +Cc: 17771

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 17771@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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-13 14:52                     ` Eli Zaretskii
@ 2014-06-16  8:02                       ` Dmitry Antipov
  2014-06-16 10:16                         ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-16  8:02 UTC (permalink / raw)
  To: Eli Zaretskii, Stephen Berman; +Cc: 17771

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

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



[-- Attachment #2: bug17771.patch --]
[-- Type: text/x-patch, Size: 617 bytes --]

=== modified file 'src/font.c'
--- src/font.c	2014-06-10 03:32:36 +0000
+++ src/font.c	2014-06-16 07:55:14 +0000
@@ -158,6 +158,7 @@
   Lisp_Object tail, frame;
   struct font_driver_list *fdl;
 
+  eassert (drv);
   for (fdl = font_driver_list; fdl; fdl = fdl->next)
     if (fdl->driver == drv)
       return true;
@@ -219,6 +220,9 @@
     }
   if (size > 0)
     font->props[FONT_SIZE_INDEX] = make_number (pixelsize);
+  /* NULL means that this font is not allocated by any driver yet,
+     and GC may be called before the driver is assigned (#Bug17771).  */
+  font->driver = NULL;
   return font_object;
 }
 


^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16  8:02                       ` Dmitry Antipov
@ 2014-06-16 10:16                         ` Stephen Berman
  2014-06-16 12:37                           ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-16 10:16 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Mon, 16 Jun 2014 12:02:21 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 10:16                         ` Stephen Berman
@ 2014-06-16 12:37                           ` Dmitry Antipov
  2014-06-16 13:07                             ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-16 12:37 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

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


[-- Attachment #2: bug17771_2.patch --]
[-- Type: text/x-patch, Size: 310 bytes --]

=== modified file 'src/font.c'
--- src/font.c	2014-03-03 19:58:20 +0000
+++ src/font.c	2014-06-16 12:32:31 +0000
@@ -207,6 +207,7 @@
     = (struct font *) allocate_pseudovector (size, FONT_OBJECT_MAX, PVEC_FONT);
   int i;
 
+  font->driver = NULL;
   XSETFONT (font_object, font);
 
   if (! NILP (entity))


^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 12:37                           ` Dmitry Antipov
@ 2014-06-16 13:07                             ` Stephen Berman
  2014-06-16 13:19                               ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-16 13:07 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Mon, 16 Jun 2014 16:37:04 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 13:07                             ` Stephen Berman
@ 2014-06-16 13:19                               ` Dmitry Antipov
  2014-06-16 13:32                                 ` Andreas Schwab
  2014-06-16 15:49                                 ` Stephen Berman
  0 siblings, 2 replies; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-16 13:19 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 13:19                               ` Dmitry Antipov
@ 2014-06-16 13:32                                 ` Andreas Schwab
  2014-06-16 15:49                                   ` Stephen Berman
  2014-06-18 12:54                                   ` Wolfgang Jenkner
  2014-06-16 15:49                                 ` Stephen Berman
  1 sibling, 2 replies; 37+ messages in thread
From: Andreas Schwab @ 2014-06-16 13:32 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: Stephen Berman, 17771

Dmitry Antipov <dmantipov@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 13:19                               ` Dmitry Antipov
  2014-06-16 13:32                                 ` Andreas Schwab
@ 2014-06-16 15:49                                 ` Stephen Berman
  2014-06-16 16:03                                   ` Dmitry Antipov
  1 sibling, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-16 15:49 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Mon, 16 Jun 2014 17:19:24 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 13:32                                 ` Andreas Schwab
@ 2014-06-16 15:49                                   ` Stephen Berman
  2014-06-16 16:21                                     ` Dmitry Antipov
  2014-06-18 12:54                                   ` Wolfgang Jenkner
  1 sibling, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-16 15:49 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Dmitry Antipov, 17771

On Mon, 16 Jun 2014 15:32:48 +0200 Andreas Schwab <schwab@suse.de> wrote:

> Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 15:49                                 ` Stephen Berman
@ 2014-06-16 16:03                                   ` Dmitry Antipov
  2014-06-16 21:33                                     ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-16 16:03 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 15:49                                   ` Stephen Berman
@ 2014-06-16 16:21                                     ` Dmitry Antipov
  2014-06-16 21:34                                       ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-16 16:21 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Andreas Schwab, 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 16:03                                   ` Dmitry Antipov
@ 2014-06-16 21:33                                     ` Stephen Berman
  2014-06-17  2:09                                       ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-16 21:33 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

On Mon, 16 Jun 2014 20:03:22 +0400 Dmitry Antipov <dmantipov@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


[-- Attachment #2: perf output --]
[-- Type: application/x-gzip, Size: 25243 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 16:21                                     ` Dmitry Antipov
@ 2014-06-16 21:34                                       ` Stephen Berman
  2014-06-17  2:25                                         ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-16 21:34 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: Andreas Schwab, 17771

On Mon, 16 Jun 2014 20:21:44 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 21:33                                     ` Stephen Berman
@ 2014-06-17  2:09                                       ` Dmitry Antipov
  2014-06-17 13:41                                         ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-17  2:09 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 21:34                                       ` Stephen Berman
@ 2014-06-17  2:25                                         ` Dmitry Antipov
  2014-06-17 13:40                                           ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-17  2:25 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-17  2:25                                         ` Dmitry Antipov
@ 2014-06-17 13:40                                           ` Stephen Berman
  0 siblings, 0 replies; 37+ messages in thread
From: Stephen Berman @ 2014-06-17 13:40 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Tue, 17 Jun 2014 06:25:07 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-17  2:09                                       ` Dmitry Antipov
@ 2014-06-17 13:41                                         ` Stephen Berman
  2014-06-17 18:11                                           ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-17 13:41 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Tue, 17 Jun 2014 06:09:26 +0400 Dmitry Antipov <dmantipov@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@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-17 13:41                                         ` Stephen Berman
@ 2014-06-17 18:11                                           ` Dmitry Antipov
  2014-06-18 13:50                                             ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-17 18:11 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-16 13:32                                 ` Andreas Schwab
  2014-06-16 15:49                                   ` Stephen Berman
@ 2014-06-18 12:54                                   ` Wolfgang Jenkner
  2014-06-18 13:50                                     ` Stephen Berman
  1 sibling, 1 reply; 37+ messages in thread
From: Wolfgang Jenkner @ 2014-06-18 12:54 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Dmitry Antipov, 17771, Stephen Berman

On Mon, Jun 16 2014, Andreas Schwab wrote:

> Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-17 18:11                                           ` Dmitry Antipov
@ 2014-06-18 13:50                                             ` Stephen Berman
  0 siblings, 0 replies; 37+ messages in thread
From: Stephen Berman @ 2014-06-18 13:50 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Tue, 17 Jun 2014 22:11:43 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-18 12:54                                   ` Wolfgang Jenkner
@ 2014-06-18 13:50                                     ` Stephen Berman
  2014-06-18 14:01                                       ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-18 13:50 UTC (permalink / raw)
  To: Wolfgang Jenkner; +Cc: Andreas Schwab, Dmitry Antipov, 17771

On Wed, 18 Jun 2014 14:54:55 +0200 Wolfgang Jenkner <wjenkner@inode.at> wrote:

> On Mon, Jun 16 2014, Andreas Schwab wrote:
>
>> Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-18 13:50                                     ` Stephen Berman
@ 2014-06-18 14:01                                       ` Dmitry Antipov
  2014-06-18 16:00                                         ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-18 14:01 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-18 14:01                                       ` Dmitry Antipov
@ 2014-06-18 16:00                                         ` Stephen Berman
  2014-06-18 16:24                                           ` Dmitry Antipov
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-18 16:00 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Wed, 18 Jun 2014 18:01:12 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-18 16:00                                         ` Stephen Berman
@ 2014-06-18 16:24                                           ` Dmitry Antipov
  2014-06-18 17:00                                             ` Stephen Berman
  0 siblings, 1 reply; 37+ messages in thread
From: Dmitry Antipov @ 2014-06-18 16:24 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 17771

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






^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-18 16:24                                           ` Dmitry Antipov
@ 2014-06-18 17:00                                             ` Stephen Berman
  2014-08-12  3:59                                               ` Glenn Morris
  0 siblings, 1 reply; 37+ messages in thread
From: Stephen Berman @ 2014-06-18 17:00 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17771

On Wed, 18 Jun 2014 20:24:21 +0400 Dmitry Antipov <dmantipov@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





^ permalink raw reply	[flat|nested] 37+ messages in thread

* bug#17771: 24.3.91; SIGSEGV in cleanup_vector
  2014-06-18 17:00                                             ` Stephen Berman
@ 2014-08-12  3:59                                               ` Glenn Morris
  0 siblings, 0 replies; 37+ messages in thread
From: Glenn Morris @ 2014-08-12  3:59 UTC (permalink / raw)
  To: 17771-done

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.





^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2014-08-12  3:59 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-13  9:12 bug#17771: 24.3.91; SIGSEGV in cleanup_vector Stephen Berman
2014-06-13  9:41 ` Eli Zaretskii
2014-06-13  9:50   ` Stephen Berman
2014-06-13 12:19     ` Eli Zaretskii
2014-06-13 12:39       ` Stephen Berman
2014-06-13 13:28         ` Eli Zaretskii
2014-06-13 13:34           ` Stephen Berman
2014-06-13 13:44             ` Eli Zaretskii
2014-06-13 13:53               ` Stephen Berman
2014-06-13 13:58                 ` Eli Zaretskii
2014-06-13 14:13                   ` Stephen Berman
2014-06-13 14:52                     ` Eli Zaretskii
2014-06-16  8:02                       ` Dmitry Antipov
2014-06-16 10:16                         ` Stephen Berman
2014-06-16 12:37                           ` Dmitry Antipov
2014-06-16 13:07                             ` Stephen Berman
2014-06-16 13:19                               ` Dmitry Antipov
2014-06-16 13:32                                 ` Andreas Schwab
2014-06-16 15:49                                   ` Stephen Berman
2014-06-16 16:21                                     ` Dmitry Antipov
2014-06-16 21:34                                       ` Stephen Berman
2014-06-17  2:25                                         ` Dmitry Antipov
2014-06-17 13:40                                           ` Stephen Berman
2014-06-18 12:54                                   ` Wolfgang Jenkner
2014-06-18 13:50                                     ` Stephen Berman
2014-06-18 14:01                                       ` Dmitry Antipov
2014-06-18 16:00                                         ` Stephen Berman
2014-06-18 16:24                                           ` Dmitry Antipov
2014-06-18 17:00                                             ` Stephen Berman
2014-08-12  3:59                                               ` Glenn Morris
2014-06-16 15:49                                 ` Stephen Berman
2014-06-16 16:03                                   ` Dmitry Antipov
2014-06-16 21:33                                     ` Stephen Berman
2014-06-17  2:09                                       ` Dmitry Antipov
2014-06-17 13:41                                         ` Stephen Berman
2014-06-17 18:11                                           ` Dmitry Antipov
2014-06-18 13:50                                             ` Stephen Berman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).