GNU bug report logs - #17168
24.3.50; Segfault at mark_object

Previous Next

Package: emacs;

Reported by: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Date: Wed, 2 Apr 2014 07:45:05 UTC

Severity: important

Tags: moreinfo

Merged with 15583, 15688, 15719, 15972, 16278, 16521, 17167, 17184

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 17168 <at> debbugs.gnu.org
Subject: bug#17168: 24.3.50; Segfault at mark_object
Date: Wed, 02 Apr 2014 14:50:25 -0700
[Message part 1 (text/plain, inline)]
On 04/02/2014 01:57 PM, Nicolas Richard wrote:
> Daniel Colascione <dancol <at> dancol.org> writes:
>> Also, Nicolas, can you call mem_find on 194710965, 188747058, and
>> 194710960?
> 
> I must warn you that I'm a total ignorant of many things, including C
> and gdb. Here's my attempt :
> 
> (gdb) mem_find(194710965)
> Undefined command: "mem_find".  Try "help".
> (gdb) p mem_find(194710965)
> $1 = (struct mem_node *) 0xb9b1d50
> (gdb) p mem_find(188747058)
> $2 = (struct mem_node *) 0xb709250
> (gdb) p mem_find(194710960)
> $3 = (struct mem_node *) 0xb9b1d50
> 
> I guess that this information is of little value by itself, but I don't
> want to mess up things while trying to get more information.

Thanks. I looked at the dump and checked that what we already know is
correct.

The vector we're trying to mark is in mem_node 0xb9b1d50:

(gdb) set $m = (struct mem_node *) 0xb9b1d50
(gdb) print *$m
$116 = {
  left = 0x84b6c20 <mem_z>,
  right = 0x84b6c20 <mem_z>,
  parent = 0x93b2f08,
  start = 0xb9b0d50,
  end = 0xb9b1d48,
  color = MEM_RED,
  type = MEM_TYPE_VECTOR_BLOCK

The contents of the block begin here:

(gdb) set $block = (struct vector_block*) ($m->start)
(gdb) print $block
$122 = (struct vector_block *) 0xb9b0d50
(gdb) set $vector = (struct Lisp_Vector*) $block->data
(gdb) print *$block
$123 = {
  data =
"\023\000\000\200\342\210M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\b\201\331p\nJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\bJ\334M\b\006\000\000\314\302\207M\b\201\272\271\fmɏ\v$\000\000\200&\243\060\f\302\207M\b\"_m\b\000\020\000Ax\366\267\f\b\200\000\311]S@\f͞\234\f\325\330M\b\302\207M\b\302\207M\b͞\234\f\302\207M\b\025\016\233\v\302\000\000\000+",
'\000' <repeats 11 times>, "\302\000\000\000+", '\000' <repeats 11
times>, "\061\064:0\002\000\000\200%\016\233\v\245\016\233\vven "...,
  next = 0xb9cc2a8

The vector we're trying to mark is 96 bytes inside this block:

(gdb) print (char*)ptr - (char*)$vector
$135 = 96

The first vector in the block is a regular vector with 0x13 elements:

(gdb) print/x $vector->header.size
$156 = 0x80000013

It's 80 bytes long:

(gdb) print header_size + (($vector->header.size &~ ARRAY_MARK_FLAG) *
word_size)
$148 = 80

The next vector in the block is a PVEC_COMPILED:

(gdb) print/x $vector->header.size
$159 = 0xcc000006

It's 32 bytes long, which means that we're trying to mark a pointer into
the middle of the vector.

The clear-transient-map symbol itself, of course, is live. It's
perfectly normal and its value slot is set to Qunbound.

[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 11 years and 47 days ago.

Previous Next


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