From: Daniel Colascione <dancol@dancol.org>
To: Dmitry Antipov <dmantipov@yandex.ru>, 17168@debbugs.gnu.org
Subject: bug#17168: 24.3.50; Segfault at mark_object
Date: Thu, 03 Apr 2014 00:55:14 -0700 [thread overview]
Message-ID: <533D13E2.3060300@dancol.org> (raw)
In-Reply-To: <533D07EF.1040502@yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 9396 bytes --]
On 04/03/2014 12:04 AM, Dmitry Antipov wrote:
> On 04/03/2014 10:59 AM, Dmitry Antipov wrote:
>
>> 3. Run 'emacs -Q', then M-x byte-force-recompile
>> /path/to/trunk/lis/org
> ^^^^^^^
> Mean /path/to/trunk/lisp/org, i.e. all Org mode.
Nice work. What gave you the idea of using byte-force-recompile to
repro? I'd tried a few other stress cases myself and couldn't find
anything. Your repro works perfectly.
In eval-after-load, we have code that looks like this:
(fset fun (lambda (file)
(when (equal file lfn)
(remove-hook 'after-load-functions fun)
(funcall func))))
This code looks just like the subr.el code that was causing problems for
Richard. I changed eval-after-load locally to something like this and
re-ran:
(fset fun
(suspicious-object (lambda (file)
(when (equal file lfn)
(remove-hook 'after-load-functions fun)
(funcall func)))))
When your assertion hits, the vector we're trying to free mark is dead
and seems to have garbage in the function slot. It's already been freed.
Below is the spot where we're freeing that lambda. If we don't set an
alloc.c breakpoint and let the code continue to assertion failure, then
the stack in suspicious_free_history is exactly what's below.
Breakpoint 4, detect_suspicious_free (ptr=0x1c363f8) at alloc.c:6868
6868 rec =
&suspicious_free_history[suspicious_free_history_index++];
(gdb) wher
#0 detect_suspicious_free (ptr=0x1c363f8) at alloc.c:6868
#1 0x000000000056779e in cleanup_vector (vector=0x1c363f8) at alloc.c:2959
#2 0x0000000000567962 in sweep_vectors () at alloc.c:3017
#3 0x000000000056dd69 in gc_sweep () at alloc.c:6738
#4 0x000000000056b893 in Fgarbage_collect () at alloc.c:5632
#5 0x00000000004e4c95 in maybe_gc () at lisp.h:4520
#6 0x00000000005d96f4 in exec_byte_code (bytestr=13432081,
vector=29098381,
maxdepth=16, args_template=0, nargs=0, args=0x7fffffff9410)
at bytecode.c:753
#7 0x0000000000590e39 in funcall_lambda (fun=29327469, nargs=0,
arg_vector=0x7fffffff9410) at eval.c:2983
#8 0x0000000000590828 in Ffuncall (nargs=1, args=0x7fffffff9408)
at eval.c:2864
#9 0x00000000005d9ecb in exec_byte_code (bytestr=13433121,
vector=29327533,
maxdepth=4, args_template=0, nargs=0, args=0x7fffffff9928)
at bytecode.c:919
#10 0x0000000000590e39 in funcall_lambda (fun=29098549, nargs=0,
arg_vector=0x7fffffff9928) at eval.c:2983
#11 0x0000000000590828 in Ffuncall (nargs=1, args=0x7fffffff9920)
at eval.c:2864
#12 0x000000000058ee87 in eval_sub (form=29022502) at eval.c:2157
#13 0x000000000058cb9a in internal_lisp_condition_case (var=13413026,
bodyform=29022502, handlers=29022406) at eval.c:1323
#14 0x00000000005db0ac in exec_byte_code (bytestr=13431537,
vector=18344837,
maxdepth=64, args_template=1028, nargs=1, args=0x7fffffffa0f8)
at bytecode.c:1169
#15 0x0000000000590e39 in funcall_lambda (fun=18345373, nargs=1,
arg_vector=0x7fffffffa0f0) at eval.c:2983
#16 0x0000000000590828 in Ffuncall (nargs=2, args=0x7fffffffa0e8)
at eval.c:2864
#17 0x00000000005d9ecb in exec_byte_code (bytestr=13425857,
vector=18336269,
maxdepth=68, args_template=2052, nargs=2, args=0x7fffffffa680)
at bytecode.c:919
#18 0x0000000000590e39 in funcall_lambda (fun=18337101, nargs=2,
arg_vector=0x7fffffffa670) at eval.c:2983
#19 0x0000000000590828 in Ffuncall (nargs=3, args=0x7fffffffa668)
at eval.c:2864
#20 0x00000000005d9ecb in exec_byte_code (bytestr=13424785,
vector=17895757,
maxdepth=40, args_template=4100, nargs=3, args=0x7fffffffabd0)
at bytecode.c:919
#21 0x0000000000590e39 in funcall_lambda (fun=17895885, nargs=3,
arg_vector=0x7fffffffabb8) at eval.c:2983
#22 0x0000000000590828 in Ffuncall (nargs=4, args=0x7fffffffabb0)
at eval.c:2864
#23 0x00000000005d9ecb in exec_byte_code (bytestr=13414625,
vector=17008333,
maxdepth=28, args_template=0, nargs=0, args=0x7fffffffb0e0)
at bytecode.c:919
#24 0x0000000000590e39 in funcall_lambda (fun=18006989, nargs=0,
arg_vector=0x7fffffffb0e0) at eval.c:2983
#25 0x0000000000590828 in Ffuncall (nargs=1, args=0x7fffffffb0d8)
at eval.c:2864
#26 0x00000000005d9ecb in exec_byte_code (bytestr=13424001,
vector=18250445,
maxdepth=4, args_template=0, nargs=0, args=0x7fffffffb5f8)
at bytecode.c:919
#27 0x0000000000590e39 in funcall_lambda (fun=18327557, nargs=0,
arg_vector=0x7fffffffb5f8) at eval.c:2983
#28 0x0000000000590828 in Ffuncall (nargs=1, args=0x7fffffffb5f0)
at eval.c:2864
#29 0x000000000058ee87 in eval_sub (form=13218422) at eval.c:2157
#30 0x000000000058cb9a in internal_lisp_condition_case (var=13412402,
bodyform=13218422, handlers=13218310) at eval.c:1323
#31 0x00000000005db0ac in exec_byte_code (bytestr=13414065,
vector=17986453,
maxdepth=104, args_template=3076, nargs=3, args=0x7fffffffbdf0)
at bytecode.c:1169
#32 0x0000000000590e39 in funcall_lambda (fun=17986813, nargs=3,
arg_vector=0x7fffffffbdd8) at eval.c:2983
#33 0x0000000000590828 in Ffuncall (nargs=4, args=0x7fffffffbdd0)
at eval.c:2864
#34 0x00000000005d9ecb in exec_byte_code (bytestr=13413841,
vector=17986061,
maxdepth=20, args_template=1028, nargs=1, args=0x7fffffffc278)
at bytecode.c:919
#35 0x0000000000590e39 in funcall_lambda (fun=17986093, nargs=1,
arg_vector=0x7fffffffc270) at eval.c:2983
#36 0x0000000000590b45 in apply_lambda (fun=17986093, args=17246278)
at eval.c:2924
#37 0x000000000058f191 in eval_sub (form=17246438) at eval.c:2230
#38 0x00000000005c0a79 in readevalloop (readcharfun=17665045, stream=0x0,
sourcename=13097937, printflag=false, unibyte=12966770,
readfun=12966770,
start=12966770, end=12966770) at lread.c:1934
#39 0x00000000005c0d4f in Feval_buffer (buffer=17665045,
printflag=12966770,
filename=16200945, unibyte=12966770, do_allow_print=12966818)
at lread.c:1995
#40 0x0000000000590702 in Ffuncall (nargs=6, args=0x7fffffffc5e8)
at eval.c:2831
#41 0x00000000005d9ecb in exec_byte_code (bytestr=9101593, vector=9101629,
maxdepth=24, args_template=12966770, nargs=0, args=0x0) at
bytecode.c:919
#42 0x0000000000591224 in funcall_lambda (fun=9101469, nargs=4,
arg_vector=0x8ae13d <pure+178429>) at eval.c:3049
#43 0x0000000000590828 in Ffuncall (nargs=5, args=0x7fffffffcb80)
at eval.c:2864
#44 0x00000000005900a9 in call4 (fn=13233138, arg1=16200945, arg2=16200945,
arg3=12966770, arg4=12966818) at eval.c:2663
#45 0x00000000005bf0ce in Fload (file=12968289, noerror=12966770,
nomessage=12966818, nosuffix=12966770, must_suffix=12966770)
at lread.c:1305
#46 0x0000000000590702 in Ffuncall (nargs=4, args=0x7fffffffcf18)
at eval.c:2831
#47 0x00000000005d9ecb in exec_byte_code (bytestr=9509777, vector=9509813,
maxdepth=92, args_template=1028, nargs=1, args=0x7fffffffd468)
at bytecode.c:919
#48 0x0000000000590e39 in funcall_lambda (fun=9509733, nargs=1,
arg_vector=0x7fffffffd460) at eval.c:2983
#49 0x0000000000590828 in Ffuncall (nargs=2, args=0x7fffffffd458)
at eval.c:2864
#50 0x00000000005d9ecb in exec_byte_code (bytestr=9483993, vector=9484029,
maxdepth=68, args_template=0, nargs=0, args=0x7fffffffd9f8)
at bytecode.c:919
#51 0x0000000000590e39 in funcall_lambda (fun=9483949, nargs=0,
arg_vector=0x7fffffffd9f8) at eval.c:2983
#52 0x0000000000590828 in Ffuncall (nargs=1, args=0x7fffffffd9f0)
at eval.c:2864
#53 0x00000000005d9ecb in exec_byte_code (bytestr=9480481, vector=9480517,
maxdepth=48, args_template=0, nargs=0, args=0x7fffffffded0)
at bytecode.c:919
#54 0x0000000000590e39 in funcall_lambda (fun=9480437, nargs=0,
arg_vector=0x7fffffffded0) at eval.c:2983
#55 0x0000000000590b45 in apply_lambda (fun=9480437, args=12966770)
at eval.c:2924
#56 0x000000000058f191 in eval_sub (form=13213110) at eval.c:2230
#57 0x000000000058e66c in Feval (form=13213110, lexical=12966770)
at eval.c:2003
#58 0x00000000004eb0a4 in top_level_2 () at keyboard.c:1183
#59 0x000000000058ccfd in internal_condition_case (
bfun=0x4eb087 <top_level_2>, handlers=13017586, hfun=0x4eab6d
<cmd_error>)
at eval.c:1354
#60 0x00000000004eb0de in top_level_1 (ignore=12966770) at keyboard.c:1191
#61 0x000000000058c181 in internal_catch (tag=13013522,
func=0x4eb0a6 <top_level_1>, arg=12966770) at eval.c:1118
#62 0x00000000004eaffd in command_loop () at keyboard.c:1152
#63 0x00000000004ea678 in recursive_edit_1 () at keyboard.c:777
#64 0x00000000004ea85d in Frecursive_edit () at keyboard.c:845
#65 0x00000000004e8748 in main (argc=5, argv=0x7fffffffe3a8) at emacs.c:1654
Lisp Backtrace:
"Automatic GC" (0xc51790)
0x1bf8068 PVEC_COMPILED
0x1bc0230 PVEC_COMPILED
"funcall" (0xffff9920)
"byte-compile-from-buffer" (0xffffa0f0)
"byte-compile-file" (0xffffa670)
"byte-recompile-file" (0xffffabb8)
0x112c3c8 PVEC_COMPILED
0x117a800 PVEC_COMPILED
"funcall" (0xffffb5f0)
"byte-recompile-directory" (0xffffbdd8)
"byte-force-recompile" (0xffffc270)
"eval-buffer" (0xffffc5f0)
"load-with-code-conversion" (0xffffcb88)
"load" (0xffffcf20)
"command-line-1" (0xffffd460)
"command-line" (0xffffd9f8)
"normal-top-level" (0xffffded0)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2014-04-03 7:55 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 7:44 bug#17168: 24.3.50; Segfault at mark_object Nicolas Richard
2014-04-02 15:53 ` Daniel Colascione
2014-04-02 17:59 ` Nicolas Richard
2014-04-02 16:29 ` Dmitry Antipov
2014-04-02 19:46 ` Daniel Colascione
2014-04-02 20:33 ` Daniel Colascione
2014-04-02 20:57 ` Nicolas Richard
2014-04-02 21:50 ` Daniel Colascione
2014-04-02 23:24 ` Stefan Monnier
2014-04-03 0:28 ` Daniel Colascione
2014-04-02 20:37 ` Eli Zaretskii
2014-04-02 20:40 ` Daniel Colascione
2014-04-02 20:55 ` Eli Zaretskii
2014-04-03 6:59 ` Dmitry Antipov
2014-04-03 7:04 ` Dmitry Antipov
2014-04-03 7:55 ` Daniel Colascione [this message]
2014-04-03 9:08 ` Daniel Colascione
2014-04-03 14:03 ` Dmitry Antipov
2014-04-03 15:42 ` Stefan Monnier
2014-04-03 16:47 ` Daniel Colascione
2014-04-03 17:49 ` Dmitry Antipov
2014-04-03 17:51 ` Daniel Colascione
2014-04-03 19:21 ` Stefan Monnier
2014-04-03 19:22 ` Daniel Colascione
2014-04-05 22:37 ` Daniel Colascione
2014-04-06 5:05 ` Dmitry Antipov
2014-04-06 5:11 ` Daniel Colascione
2014-04-06 18:00 ` Richard Stallman
2014-04-06 18:10 ` Daniel Colascione
2014-04-06 19:06 ` Eli Zaretskii
2014-04-07 7:49 ` martin rudalics
2014-04-07 8:18 ` Dmitry Antipov
2014-04-07 9:20 ` martin rudalics
2014-04-06 12:36 ` Stefan Monnier
2014-04-06 15:06 ` Eli Zaretskii
2014-04-06 15:59 ` Daniel Colascione
2014-04-06 16:19 ` Eli Zaretskii
2014-04-06 16:24 ` Daniel Colascione
2014-04-06 16:29 ` Eli Zaretskii
2014-04-06 16:37 ` Daniel Colascione
2014-04-06 16:59 ` Eli Zaretskii
2014-04-06 17:11 ` Daniel Colascione
2014-04-06 19:44 ` Stefan Monnier
2014-04-06 19:42 ` Stefan Monnier
2014-04-06 15:46 ` Daniel Colascione
2014-04-06 19:58 ` Stefan Monnier
2014-04-06 20:13 ` Daniel Colascione
2014-04-06 20:53 ` Daniel Colascione
2014-04-06 21:08 ` Stefan Monnier
2014-04-06 21:37 ` Daniel Colascione
2014-04-07 16:28 ` Stefan Monnier
2014-04-07 19:06 ` Daniel Colascione
2014-04-07 20:42 ` Stefan Monnier
2014-04-08 7:14 ` martin rudalics
2014-04-08 8:47 ` Daniel Colascione
2014-04-06 18:01 ` Richard Stallman
2014-04-06 19:58 ` Stefan Monnier
2014-04-07 16:56 ` Richard Stallman
2014-04-02 20:49 ` Nicolas Richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533D13E2.3060300@dancol.org \
--to=dancol@dancol.org \
--cc=17168@debbugs.gnu.org \
--cc=dmantipov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.