GNU bug report logs - #11416
24.1.50; Abort in Fadd_text_properties on Windows

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 11416 <at> debbugs.gnu.org
Subject: Re: bug#11416: 24.1.50; Abort in Fadd_text_properties on Windows
Date: Sun, 06 May 2012 23:31:35 +0300

> Date: Sun, 06 May 2012 13:53:19 -0600
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: 11416 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>  > Sorry, I should have been more clear.  I meant this:
>  >
>  >  (gdb) p object
>  >  (gdb) xtype
>  >
>  > If "xtype" says it's a symbol, follow immediately by "xsymbol" to see
>  > which symbol it is.  Other Lisp data types have their respective xFOO
>  > commands to do similar things.
> 
> (gdb) p object
> $6 = 283151365
> (gdb) xtype
> Lisp_Vectorlike
> PVEC_BUFFER
> (gdb) xvector
> $7 = (struct Lisp_Vector *) 0x10e08c00
> 0
> (gdb)

So it's a buffer.  "xbuffer" will show more details (but I'm not sure
this is worth pursuing, until we establish where exactly does Emacs
abort and why).

> No, it's a debug nightly build from my Jenkins server. However, last
> night another build got kicked of and some files might haeve been
> updated from bzr. The build failed since the executable was still
> running. Possible that the source does not match the object code.

Could it be that the abort was caused by compiling/linking
incompatible files?

> gdb 7.3.1 is the usual version I use.

I suggest upgrading to the latest v7.4 (available from MinGW).

> If this doesn't lead to anything, I can keep an eye open for another
> occurrence.

Sounds like this is the way to go.  Start Emacs from GDB, while you
are at it, so that "pp" etc. works.

Thanks.

Previous Next

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