GNU bug report logs -
#8334
Segmentation fault in mark_object (in my patched version)
Previous Next
Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>
Date: Thu, 24 Mar 2011 00:08:02 UTC
Severity: normal
Tags: moreinfo, unreproducible, wontfix
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8334 in the body.
You can then email your comments to 8334 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 00:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lennart Borgman <lennart.borgman <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 24 Mar 2011 00:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I just got a segmentation fault in mark_object. This was with my
patched version:
This Emacs was built from sources in bazaar identified as:
Nick 'trunk' info:
revision id: yamaoka <at> jpl.org-20110216231247-r8dr95j65ud08bqz
revno: 103306
date: 2011-02-16 23:12:47 +0000
Nick 'emacsw32' (from 'trunk') info:
revision id: lennart.borgman <at> gmail.com-20110216233741-bbne2i1djpaccnv1
revno: 99348
date: 2011-02-17 00:37:41 +0100
Program received signal SIGSEGV, Segmentation fault.
0x01028778 in mark_object (arg=6637606) at alloc.c:5531
warning: Source file is more recent than executable.
5531 if (EQ (ptr->u.cdr, Qnil))
(gdb) bt
#0 0x01028778 in mark_object (arg=6637606) at alloc.c:5531
#1 0x0102880d in mark_object (arg=301623766) at alloc.c:5542
#2 0x0102853e in mark_object (arg=297533442) at alloc.c:5435
#3 0x0102678d in mark_maybe_pointer (p=0x11bc0000) at alloc.c:4089
#4 0x01026520 in mark_memory (start=0x82cae8, end=0x82ff30, offset=0)
at alloc.c:4139
#5 0x01026da2 in mark_stack () at alloc.c:4385
#6 0x01027a3c in Fgarbage_collect () at alloc.c:4967
#7 0x01020968 in Feval (form=301887150) at eval.c:2143
#8 0x01021081 in Feval (form=270381486) at eval.c:2312
#9 0x0101dcc9 in Fprogn (args=270381710) at eval.c:343
#10 0x01020aff in Feval (form=270381478) at eval.c:2198
#11 0x0101dbf6 in Fif (args=270381470) at eval.c:293
#12 0x01020aff in Feval (form=270381446) at eval.c:2198
#13 0x0101dcc9 in Fprogn (args=301886974) at eval.c:343
#14 0x01020aff in Feval (form=301886998) at eval.c:2198
#15 0x0101dbf6 in Fif (args=301887014) at eval.c:293
#16 0x01020aff in Feval (form=301887022) at eval.c:2198
#17 0x01021081 in Feval (form=270381126) at eval.c:2312
#18 0x0101dcc9 in Fprogn (args=270458606) at eval.c:343
#19 0x0101eeb2 in Flet (args=270381118) at eval.c:1000
#20 0x01020aff in Feval (form=270383022) at eval.c:2198
#21 0x0101dcc9 in Fprogn (args=301889606) at eval.c:343
#22 0x010224d9 in funcall_lambda (fun=301889630, nargs=1, arg_vector=0x82d78c)
at eval.c:3021
#23 0x01022004 in Ffuncall (nargs=2, args=0x82d788) at eval.c:2902
#24 0x0102186a in call1 (fn=301889630, arg1=49847742) at eval.c:2643
#25 0x0103ad9f in mapcar1 (leni=30, vals=0x0, fn=301889630, seq=301774390)
at fns.c:2344
#26 0x0103b145 in Fmapc (function=301889630, sequence=301774390) at fns.c:2433
#27 0x01020dc4 in Feval (form=270382958) at eval.c:2254
#28 0x0101dcc9 in Fprogn (args=301772870) at eval.c:343
#29 0x0101ef8c in Fwhile (args=301772886) at eval.c:1022
#30 0x01020aff in Feval (form=301772894) at eval.c:2198
#31 0x0101dcc9 in Fprogn (args=301772902) at eval.c:343
#32 0x0101eeb2 in Flet (args=301772910) at eval.c:1000
#33 0x01020aff in Feval (form=301772918) at eval.c:2198
#34 0x0101dcc9 in Fprogn (args=301772950) at eval.c:343
#35 0x0101f22a in internal_catch (tag=271267586, func=0x101dca0 <Fprogn>,
arg=301772950) at eval.c:1152
#36 0x0101f195 in Fcatch (args=301772982) at eval.c:1123
#37 0x01020aff in Feval (form=301772990) at eval.c:2198
#38 0x01020d17 in Feval (form=301773006) at eval.c:2236
#39 0x01021081 in Feval (form=301772942) at eval.c:2312
#40 0x01021081 in Feval (form=270382894) at eval.c:2312
#41 0x0101dcc9 in Fprogn (args=301774582) at eval.c:343
#42 0x0101ef8c in Fwhile (args=301774598) at eval.c:1022
#43 0x01020aff in Feval (form=301774606) at eval.c:2198
#44 0x0101dcc9 in Fprogn (args=301774614) at eval.c:343
#45 0x0101eeb2 in Flet (args=301774622) at eval.c:1000
#46 0x01020aff in Feval (form=301774630) at eval.c:2198
#47 0x0101dcc9 in Fprogn (args=301774662) at eval.c:343
#48 0x0101f22a in internal_catch (tag=271267586, func=0x101dca0 <Fprogn>,
arg=301774662) at eval.c:1152
#49 0x0101f195 in Fcatch (args=301774694) at eval.c:1123
#50 0x01020aff in Feval (form=301774702) at eval.c:2198
#51 0x01020d17 in Feval (form=301774718) at eval.c:2236
#52 0x01021081 in Feval (form=301774654) at eval.c:2312
#53 0x01021081 in Feval (form=270382822) at eval.c:2312
#54 0x0101dcc9 in Fprogn (args=270458654) at eval.c:343
#55 0x0101eeb2 in Flet (args=270382758) at eval.c:1000
#56 0x01020aff in Feval (form=270382574) at eval.c:2198
#57 0x0101dcc9 in Fprogn (args=270458662) at eval.c:343
#58 0x01020aff in Feval (form=270382566) at eval.c:2198
#59 0x0101dcc9 in Fprogn (args=270458670) at eval.c:343
#60 0x010224d9 in funcall_lambda (fun=270458678, nargs=1, arg_vector=0x82ef10)
at eval.c:3021
#61 0x010221ef in apply_lambda (fun=270458678, args=270458854, eval_flag=1)
at eval.c:2954
#62 0x010210ab in Feval (form=270458838) at eval.c:2314
#63 0x0101dcc9 in Fprogn (args=270458846) at eval.c:343
#64 0x0101dc16 in Fif (args=270458766) at eval.c:294
#65 0x01020aff in Feval (form=270458758) at eval.c:2198
#66 0x0101dcc9 in Fprogn (args=270456958) at eval.c:343
#67 0x010224d9 in funcall_lambda (fun=270456966, nargs=1, arg_vector=0x82f2e0)
at eval.c:3021
#68 0x010221ef in apply_lambda (fun=270456966, args=270457342, eval_flag=1)
at eval.c:2954
#69 0x010210ab in Feval (form=270457334) at eval.c:2314
#70 0x0101dcc9 in Fprogn (args=270457350) at eval.c:343
#71 0x0101eeb2 in Flet (args=270457262) at eval.c:1000
#72 0x01020aff in Feval (form=270457190) at eval.c:2198
#73 0x0101f62f in internal_lisp_condition_case (var=49818274,
bodyform=270457190, handlers=270457422) at eval.c:1355
#74 0x0101f451 in Fcondition_case (args=270457182) at eval.c:1297
#75 0x01020aff in Feval (form=270457174) at eval.c:2198
#76 0x0101dcc9 in Fprogn (args=270457430) at eval.c:343
#77 0x010224d9 in funcall_lambda (fun=270457438, nargs=0, arg_vector=0x82fa18)
at eval.c:3021
#78 0x01022004 in Ffuncall (nargs=1, args=0x82fa14) at eval.c:2902
#79 0x01021738 in run_hook_with_args (nargs=1, args=0x82fa14,
cond=to_completion) at eval.c:2573
#80 0x010214fb in Frun_hooks (nargs=1, args=0x82facc) at eval.c:2443
#81 0x01021c62 in Ffuncall (nargs=2, args=0x82fac8) at eval.c:2824
#82 0x0102186a in call1 (fn=49400410, arg1=49289770) at eval.c:2643
#83 0x01005c76 in safe_run_hooks_1 () at keyboard.c:1822
#84 0x0101f739 in internal_condition_case (bfun=0x1005c43 <safe_run_hooks_1>,
handlers=49244210, hfun=0x1005c7e <safe_run_hooks_error>) at eval.c:1408
#85 0x01005d16 in safe_run_hooks (hook=49289770) at keyboard.c:1848
#86 0x01004ff2 in command_loop_1 () at keyboard.c:1545
#87 0x0101f739 in internal_condition_case (bfun=0x10048d9 <command_loop_1>,
handlers=49297818, hfun=0x10042ce <cmd_error>) at eval.c:1408
#88 0x0100463e in command_loop_2 (ignore=49244186) at keyboard.c:1129
#89 0x0101f22a in internal_catch (tag=49295914,
func=0x100461b <command_loop_2>, arg=49244186) at eval.c:1152
#90 0x010045f6 in command_loop () at keyboard.c:1108
#91 0x01003eea in recursive_edit_1 () at keyboard.c:731
#92 0x0100404e in Frecursive_edit () at keyboard.c:793
#93 0x01002767 in main (argc=1, argv=0xb23d08) at emacs.c:1684
Lisp Backtrace:
"when" (0x82ce00)
"progn" (0x82cf50)
"if" (0x82d0a0)
"progn" (0x82d1f0)
"if" (0x82d340)
"when" (0x82d450)
"let" (0x82d640)
0x11fe7858 Lisp type 6
"mapc" (0x82d8c0)
"while" (0x82db00)
"let" (0x82dcf0)
"catch" (0x82df00)
"cl-block-wrapper" (0x82e010)
"block" (0x82e120)
"dolist" (0x82e230)
"while" (0x82e3e0)
"let" (0x82e5d0)
"catch" (0x82e7e0)
"cl-block-wrapper" (0x82e8f0)
"block" (0x82ea00)
"dolist" (0x82eb10)
"let" (0x82ed10)
"progn" (0x82ee60)
"menuacc-add-accel-1" (0x82ef10)
"if" (0x82f230)
"menuacc-add-accel" (0x82f2e0)
"let" (0x82f660)
"condition-case" (0x82f860)
"menuacc-add-accel-from-post-command-hook" (0x82fa18)
"run-hooks" (0x82facc)
(gdb)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 00:50:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 8334 <at> debbugs.gnu.org (full text, mbox):
Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> I just got a segmentation fault in mark_object. This was with my
> patched version:
No test case supplied; bug occurs on a tree with unspecified
modifications. Tagging as unreproducible.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 00:53:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 1:49 AM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>
>> I just got a segmentation fault in mark_object. This was with my
>> patched version:
>
> No test case supplied; bug occurs on a tree with unspecified
> modifications. Tagging as unreproducible.
Of course there is no test case for this. I have not idea what caused
it (except from the info in the backtrace). But what is the advantage
and meaning of tagging it as "unreproducible"?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 01:10:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 8334 <at> debbugs.gnu.org (full text, mbox):
Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> Of course there is no test case for this. I have not idea what caused
> it (except from the info in the backtrace). But what is the advantage
> and meaning of tagging it as "unreproducible"?
It is an indicator to Emacs developers that they should work on other
bugs.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 01:22:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 2:09 AM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>
>> Of course there is no test case for this. I have not idea what caused
>> it (except from the info in the backtrace). But what is the advantage
>> and meaning of tagging it as "unreproducible"?
>
> It is an indicator to Emacs developers that they should work on other
> bugs.
It seems like you do not consider it worth looking at. Is not that a
quite strange handling of a crash report? How did you came to your
conclusion?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 01:47:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 8334 <at> debbugs.gnu.org (full text, mbox):
Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> It seems like you do not consider it worth looking at. Is not that a
> quite strange handling of a crash report? How did you came to your
> conclusion?
If a bug is reported from a modified version of Emacs with a
reproducible test case, it is worth investigating, since we can easily
check whether it occurs in our unmodified tree.
The present bug is reported from a modified version of Emacs, but with
no test case, no description of events leading to the crash, and an
uninformative backtrace. For all we know, it is due to your own
unspecified changes. So it is more profitable for Emacs developers to
work on the bugs in our tree that need attention.
If you come across any new information, please let us know. Thanks.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 01:53:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 2:46 AM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>
>> It seems like you do not consider it worth looking at. Is not that a
>> quite strange handling of a crash report? How did you came to your
>> conclusion?
>
> If a bug is reported from a modified version of Emacs with a
> reproducible test case, it is worth investigating, since we can easily
> check whether it occurs in our unmodified tree.
>
> The present bug is reported from a modified version of Emacs, but with
> no test case, no description of events leading to the crash, and an
> uninformative backtrace. For all we know, it is due to your own
> unspecified changes. So it is more profitable for Emacs developers to
> work on the bugs in our tree that need attention.
You make an unwarranted assumption. For all I know it does not depend
on my changes. It is not impossible, but I doubt it. The problem is
that the different threads involved might be badly coordinated in
certain cases. This is a general problem I have pointed to several
times (without much success).
So why do you make this assumption?
> If you come across any new information, please let us know. Thanks.
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 03:09:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 02:52, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
> The problem is
> that the different threads involved might be badly coordinated in
> certain cases.
Why do you think so?
> This is a general problem I have pointed to several
> times (without much success).
Have you tried building with -fno-strict-aliasing? Bug#8217 is about a
crash during garbage collection that apparently disappears with
-fno-strict-aliasing, and I've been also experiencing
garbage-collection crashes in non-optimized gcc 4+ builds that seem to
be "cured" (or most likely, hidden) by that option.
Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 09:33:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 04:07, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> and I've been also experiencing
> garbage-collection crashes in non-optimized gcc 4+ builds that seem to
> be "cured" (or most likely, hidden) by that option.
Disregard that last part, because -fno-strict-aliasing does not (or
should not) have any influence in non-optimized builds. The behavior I
see must necessarily have other causes. But still it worked for
bug#8217, so I suggest you give it a try, if you're building
optimized.
Juanma
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 14:32:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 10:24 AM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Thu, Mar 24, 2011 at 04:07, Juanma Barranquero <lekktu <at> gmail.com> wrote:
>
>> and I've been also experiencing
>> garbage-collection crashes in non-optimized gcc 4+ builds that seem to
>> be "cured" (or most likely, hidden) by that option.
>
> Disregard that last part, because -fno-strict-aliasing does not (or
> should not) have any influence in non-optimized builds. The behavior I
> see must necessarily have other causes. But still it worked for
> bug#8217, so I suggest you give it a try, if you're building
> optimized.
Thanks, but I never build optimized any more since that prevents
debugging on the C level.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 14:34:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 4:07 AM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Thu, Mar 24, 2011 at 02:52, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>
>> The problem is
>> that the different threads involved might be badly coordinated in
>> certain cases.
>
> Why do you think so?
Because I have seen quite a few problems related to menus. (This was
the original reason for making my patched version of Emacs.)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 14:43:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 8334 <at> debbugs.gnu.org (full text, mbox):
> The present bug is reported from a modified version of Emacs, but with
> no test case, no description of events leading to the crash, and an
> uninformative backtrace. For all we know, it is due to your own
> unspecified changes. So it is more profitable for Emacs developers to
> work on the bugs in our tree that need attention.
Actually, this is not the main reason, AFAIC. The problem is that we
simply have no way to debug it. Especially for a bug that causes
a segfault in the GC, i.e. a bug that apparently causes memory
corruption and could hence be anywhere.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 14:49:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 8334 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 24, 2011 at 3:42 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> The present bug is reported from a modified version of Emacs, but with
>> no test case, no description of events leading to the crash, and an
>> uninformative backtrace. For all we know, it is due to your own
>> unspecified changes. So it is more profitable for Emacs developers to
>> work on the bugs in our tree that need attention.
>
> Actually, this is not the main reason, AFAIC. The problem is that we
> simply have no way to debug it. Especially for a bug that causes
> a segfault in the GC, i.e. a bug that apparently causes memory
> corruption and could hence be anywhere.
True. However I am reporting such bugs because I believe there might
be a race condition caused by bad thread coordination behind it. But
of course this is just a guess. However as long as we do not have take
all possible actions to avoid this I think it is a reasonable guess.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Thu, 24 Mar 2011 16:38:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 8334 <at> debbugs.gnu.org (full text, mbox):
Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> Because I have seen quite a few problems related to menus. (This was
> the original reason for making my patched version of Emacs.)
Please go ahead and resubmit the patches for consideration.
Added tag(s) wontfix.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 27 Mar 2012 23:14:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Tue, 27 Mar 2012 23:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Lennart Borgman <lennart.borgman <at> gmail.com>:
bug acknowledged by developer.
(Tue, 27 Mar 2012 23:14:03 GMT)
Full text and
rfc822 format available.
Message #51 received at 8334-done <at> debbugs.gnu.org (full text, mbox):
tags 8334 wontfix
stop
Chong Yidong wrote:
> No test case supplied; bug occurs on a tree with unspecified
> modifications. Tagging as unreproducible.
Nothing changed in the past year; closing since nothing can be done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#8334; Package
emacs.
(Tue, 27 Mar 2012 23:21:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 8334 <at> debbugs.gnu.org (full text, mbox):
Ok, I have not seen it since.
On Wed, Mar 28, 2012 at 01:14, GNU bug Tracking System
<help-debbugs <at> gnu.org> wrote:
> Your bug report
>
> #8334: Segmentation fault in mark_object (in my patched version)
>
> which was filed against the emacs package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 8334 <at> debbugs.gnu.org.
>
> --
> 8334: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8334
> GNU Bug Tracking System
> Contact help-debbugs <at> gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: Glenn Morris <rgm <at> gnu.org>
> To: 8334-done <at> debbugs.gnu.org
> Cc:
> Date: Tue, 27 Mar 2012 18:42:00 -0400
> Subject: Re: bug#8334: Segmentation fault in mark_object (in my patched version)
> tags 8334 wontfix
> stop
>
> Chong Yidong wrote:
>
>> No test case supplied; bug occurs on a tree with unspecified
>> modifications. Tagging as unreproducible.
>
> Nothing changed in the past year; closing since nothing can be done.
>
>
>
> ---------- Forwarded message ----------
> From: Lennart Borgman <lennart.borgman <at> gmail.com>
> To: Emacs Bugs <bug-gnu-emacs <at> gnu.org>
> Cc:
> Date: Thu, 24 Mar 2011 01:07:19 +0100
> Subject: Segmentation fault in mark_object (in my patched version)
> I just got a segmentation fault in mark_object. This was with my
> patched version:
>
> This Emacs was built from sources in bazaar identified as:
>
> Nick 'trunk' info:
> revision id: yamaoka <at> jpl.org-20110216231247-r8dr95j65ud08bqz
> revno: 103306
> date: 2011-02-16 23:12:47 +0000
>
> Nick 'emacsw32' (from 'trunk') info:
> revision id: lennart.borgman <at> gmail.com-20110216233741-bbne2i1djpaccnv1
> revno: 99348
> date: 2011-02-17 00:37:41 +0100
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x01028778 in mark_object (arg=6637606) at alloc.c:5531
> warning: Source file is more recent than executable.
> 5531 if (EQ (ptr->u.cdr, Qnil))
> (gdb) bt
> #0 0x01028778 in mark_object (arg=6637606) at alloc.c:5531
> #1 0x0102880d in mark_object (arg=301623766) at alloc.c:5542
> #2 0x0102853e in mark_object (arg=297533442) at alloc.c:5435
> #3 0x0102678d in mark_maybe_pointer (p=0x11bc0000) at alloc.c:4089
> #4 0x01026520 in mark_memory (start=0x82cae8, end=0x82ff30, offset=0)
> at alloc.c:4139
> #5 0x01026da2 in mark_stack () at alloc.c:4385
> #6 0x01027a3c in Fgarbage_collect () at alloc.c:4967
> #7 0x01020968 in Feval (form=301887150) at eval.c:2143
> #8 0x01021081 in Feval (form=270381486) at eval.c:2312
> #9 0x0101dcc9 in Fprogn (args=270381710) at eval.c:343
> #10 0x01020aff in Feval (form=270381478) at eval.c:2198
> #11 0x0101dbf6 in Fif (args=270381470) at eval.c:293
> #12 0x01020aff in Feval (form=270381446) at eval.c:2198
> #13 0x0101dcc9 in Fprogn (args=301886974) at eval.c:343
> #14 0x01020aff in Feval (form=301886998) at eval.c:2198
> #15 0x0101dbf6 in Fif (args=301887014) at eval.c:293
> #16 0x01020aff in Feval (form=301887022) at eval.c:2198
> #17 0x01021081 in Feval (form=270381126) at eval.c:2312
> #18 0x0101dcc9 in Fprogn (args=270458606) at eval.c:343
> #19 0x0101eeb2 in Flet (args=270381118) at eval.c:1000
> #20 0x01020aff in Feval (form=270383022) at eval.c:2198
> #21 0x0101dcc9 in Fprogn (args=301889606) at eval.c:343
> #22 0x010224d9 in funcall_lambda (fun=301889630, nargs=1, arg_vector=0x82d78c)
> at eval.c:3021
> #23 0x01022004 in Ffuncall (nargs=2, args=0x82d788) at eval.c:2902
> #24 0x0102186a in call1 (fn=301889630, arg1=49847742) at eval.c:2643
> #25 0x0103ad9f in mapcar1 (leni=30, vals=0x0, fn=301889630, seq=301774390)
> at fns.c:2344
> #26 0x0103b145 in Fmapc (function=301889630, sequence=301774390) at fns.c:2433
> #27 0x01020dc4 in Feval (form=270382958) at eval.c:2254
> #28 0x0101dcc9 in Fprogn (args=301772870) at eval.c:343
> #29 0x0101ef8c in Fwhile (args=301772886) at eval.c:1022
> #30 0x01020aff in Feval (form=301772894) at eval.c:2198
> #31 0x0101dcc9 in Fprogn (args=301772902) at eval.c:343
> #32 0x0101eeb2 in Flet (args=301772910) at eval.c:1000
> #33 0x01020aff in Feval (form=301772918) at eval.c:2198
> #34 0x0101dcc9 in Fprogn (args=301772950) at eval.c:343
> #35 0x0101f22a in internal_catch (tag=271267586, func=0x101dca0 <Fprogn>,
> arg=301772950) at eval.c:1152
> #36 0x0101f195 in Fcatch (args=301772982) at eval.c:1123
> #37 0x01020aff in Feval (form=301772990) at eval.c:2198
> #38 0x01020d17 in Feval (form=301773006) at eval.c:2236
> #39 0x01021081 in Feval (form=301772942) at eval.c:2312
> #40 0x01021081 in Feval (form=270382894) at eval.c:2312
> #41 0x0101dcc9 in Fprogn (args=301774582) at eval.c:343
> #42 0x0101ef8c in Fwhile (args=301774598) at eval.c:1022
> #43 0x01020aff in Feval (form=301774606) at eval.c:2198
> #44 0x0101dcc9 in Fprogn (args=301774614) at eval.c:343
> #45 0x0101eeb2 in Flet (args=301774622) at eval.c:1000
> #46 0x01020aff in Feval (form=301774630) at eval.c:2198
> #47 0x0101dcc9 in Fprogn (args=301774662) at eval.c:343
> #48 0x0101f22a in internal_catch (tag=271267586, func=0x101dca0 <Fprogn>,
> arg=301774662) at eval.c:1152
> #49 0x0101f195 in Fcatch (args=301774694) at eval.c:1123
> #50 0x01020aff in Feval (form=301774702) at eval.c:2198
> #51 0x01020d17 in Feval (form=301774718) at eval.c:2236
> #52 0x01021081 in Feval (form=301774654) at eval.c:2312
> #53 0x01021081 in Feval (form=270382822) at eval.c:2312
> #54 0x0101dcc9 in Fprogn (args=270458654) at eval.c:343
> #55 0x0101eeb2 in Flet (args=270382758) at eval.c:1000
> #56 0x01020aff in Feval (form=270382574) at eval.c:2198
> #57 0x0101dcc9 in Fprogn (args=270458662) at eval.c:343
> #58 0x01020aff in Feval (form=270382566) at eval.c:2198
> #59 0x0101dcc9 in Fprogn (args=270458670) at eval.c:343
> #60 0x010224d9 in funcall_lambda (fun=270458678, nargs=1, arg_vector=0x82ef10)
> at eval.c:3021
> #61 0x010221ef in apply_lambda (fun=270458678, args=270458854, eval_flag=1)
> at eval.c:2954
> #62 0x010210ab in Feval (form=270458838) at eval.c:2314
> #63 0x0101dcc9 in Fprogn (args=270458846) at eval.c:343
> #64 0x0101dc16 in Fif (args=270458766) at eval.c:294
> #65 0x01020aff in Feval (form=270458758) at eval.c:2198
> #66 0x0101dcc9 in Fprogn (args=270456958) at eval.c:343
> #67 0x010224d9 in funcall_lambda (fun=270456966, nargs=1, arg_vector=0x82f2e0)
> at eval.c:3021
> #68 0x010221ef in apply_lambda (fun=270456966, args=270457342, eval_flag=1)
> at eval.c:2954
> #69 0x010210ab in Feval (form=270457334) at eval.c:2314
> #70 0x0101dcc9 in Fprogn (args=270457350) at eval.c:343
> #71 0x0101eeb2 in Flet (args=270457262) at eval.c:1000
> #72 0x01020aff in Feval (form=270457190) at eval.c:2198
> #73 0x0101f62f in internal_lisp_condition_case (var=49818274,
> bodyform=270457190, handlers=270457422) at eval.c:1355
> #74 0x0101f451 in Fcondition_case (args=270457182) at eval.c:1297
> #75 0x01020aff in Feval (form=270457174) at eval.c:2198
> #76 0x0101dcc9 in Fprogn (args=270457430) at eval.c:343
> #77 0x010224d9 in funcall_lambda (fun=270457438, nargs=0, arg_vector=0x82fa18)
> at eval.c:3021
> #78 0x01022004 in Ffuncall (nargs=1, args=0x82fa14) at eval.c:2902
> #79 0x01021738 in run_hook_with_args (nargs=1, args=0x82fa14,
> cond=to_completion) at eval.c:2573
> #80 0x010214fb in Frun_hooks (nargs=1, args=0x82facc) at eval.c:2443
> #81 0x01021c62 in Ffuncall (nargs=2, args=0x82fac8) at eval.c:2824
> #82 0x0102186a in call1 (fn=49400410, arg1=49289770) at eval.c:2643
> #83 0x01005c76 in safe_run_hooks_1 () at keyboard.c:1822
> #84 0x0101f739 in internal_condition_case (bfun=0x1005c43 <safe_run_hooks_1>,
> handlers=49244210, hfun=0x1005c7e <safe_run_hooks_error>) at eval.c:1408
> #85 0x01005d16 in safe_run_hooks (hook=49289770) at keyboard.c:1848
> #86 0x01004ff2 in command_loop_1 () at keyboard.c:1545
> #87 0x0101f739 in internal_condition_case (bfun=0x10048d9 <command_loop_1>,
> handlers=49297818, hfun=0x10042ce <cmd_error>) at eval.c:1408
> #88 0x0100463e in command_loop_2 (ignore=49244186) at keyboard.c:1129
> #89 0x0101f22a in internal_catch (tag=49295914,
> func=0x100461b <command_loop_2>, arg=49244186) at eval.c:1152
> #90 0x010045f6 in command_loop () at keyboard.c:1108
> #91 0x01003eea in recursive_edit_1 () at keyboard.c:731
> #92 0x0100404e in Frecursive_edit () at keyboard.c:793
> #93 0x01002767 in main (argc=1, argv=0xb23d08) at emacs.c:1684
>
> Lisp Backtrace:
> "when" (0x82ce00)
> "progn" (0x82cf50)
> "if" (0x82d0a0)
> "progn" (0x82d1f0)
> "if" (0x82d340)
> "when" (0x82d450)
> "let" (0x82d640)
> 0x11fe7858 Lisp type 6
> "mapc" (0x82d8c0)
> "while" (0x82db00)
> "let" (0x82dcf0)
> "catch" (0x82df00)
> "cl-block-wrapper" (0x82e010)
> "block" (0x82e120)
> "dolist" (0x82e230)
> "while" (0x82e3e0)
> "let" (0x82e5d0)
> "catch" (0x82e7e0)
> "cl-block-wrapper" (0x82e8f0)
> "block" (0x82ea00)
> "dolist" (0x82eb10)
> "let" (0x82ed10)
> "progn" (0x82ee60)
> "menuacc-add-accel-1" (0x82ef10)
> "if" (0x82f230)
> "menuacc-add-accel" (0x82f2e0)
> "let" (0x82f660)
> "condition-case" (0x82f860)
> "menuacc-add-accel-from-post-command-hook" (0x82fa18)
> "run-hooks" (0x82facc)
> (gdb)
>
>
>
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 25 Apr 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 118 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.