Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Alexis <flexibeast@gmail.com>]

Peder O. Klingenberg writes:

> On Thu, Jul 10 2014 at 09:41, Alexis wrote:
>
>> Peder O. Klingenberg writes:
>>
>>> Try attaching gdb to the emacs process before starting the
>>> emacsclient, and see if you catch a signal as you exit emacsclient?
>>
>> When i enter C-x 5 0 in emacsclient, gdb reports:
>>
>>     Program received signal SIGSEGV, Segmentation fault.
>>     PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
>>     2436          return PSEUDOVECTOR_TYPEP (h, code);
>
> So your emacs dies with a segfault, same as mine did.  But not on the
> same line (or perhaps there's been code changes in that area since
> march, I haven't checked).  WRT the Subject of this thread, I'd say
> definitely a bug.

Well, getting a backtrace produced:

#0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
#1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607

It looks like the `font_clear_cache` function was last modified by
Dmitry on 3 March, git commit b0c9db81.

i tried `next`ing through that function for a while[1], and at one point
started getting values for the `entity' variable such as -16777216 and
16777215, which look suspiciously like a 24-bit-related issue to this
untrained eye .... The last value of the `entity` variable i got before
the segfault was 536871013.

Does anyone have any advice as to how i can proceed further?


Alexis.

[1] Not fully, because i didn't know the value of `ASIZE (elt)`, since
according to GDB it had been optimized out, despite me `make`ing the
binary with `-O0 -g3`, as per etc/DEBUG (i'm running gcc 4.7.2).