bug#8334: Segmentation fault in mark_object (in my patched version)

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

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@jpl.org-20110216231247-r8dr95j65ud08bqz
        revno: 103306
         date: 2011-02-16 23:12:47 +0000

  Nick 'emacsw32' (from 'trunk') info:
  revision id: lennart.borgman@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#8334: Segmentation fault in mark_object (in my patched version)

[Chong Yidong]

Lennart Borgman <lennart.borgman@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.

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

On Thu, Mar 24, 2011 at 1:49 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@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"?

bug#8334: Segmentation fault in mark_object (in my patched version)

[Chong Yidong]

Lennart Borgman <lennart.borgman@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.

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

On Thu, Mar 24, 2011 at 2:09 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@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?

bug#8334: Segmentation fault in mark_object (in my patched version)

[Chong Yidong]

Lennart Borgman <lennart.borgman@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.

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

On Thu, Mar 24, 2011 at 2:46 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@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.
>

bug#8334: Segmentation fault in mark_object (in my patched version)

[Juanma Barranquero]

On Thu, Mar 24, 2011 at 02:52, Lennart Borgman
<lennart.borgman@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

bug#8334: Segmentation fault in mark_object (in my patched version)

[Juanma Barranquero]

On Thu, Mar 24, 2011 at 04:07, Juanma Barranquero <lekktu@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

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

On Thu, Mar 24, 2011 at 10:24 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 04:07, Juanma Barranquero <lekktu@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.

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

On Thu, Mar 24, 2011 at 4:07 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 02:52, Lennart Borgman
> <lennart.borgman@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.)

bug#8334: Segmentation fault in mark_object (in my patched version)

[Stefan Monnier]

> 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

bug#8334: Segmentation fault in mark_object (in my patched version)

[Lennart Borgman]

On Thu, Mar 24, 2011 at 3:42 PM, Stefan Monnier
<monnier@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.

bug#8334: Segmentation fault in mark_object (in my patched version)

[Chong Yidong]

Lennart Borgman <lennart.borgman@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.

bug#8334: Segmentation fault in mark_object (in my patched version)

[Glenn Morris]

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.

bug#8334: closed (Re: bug#8334: Segmentation fault in mark_object (in my patched version))

[Lennart Borgman]

Ok, I have not seen it since.


On Wed, Mar 28, 2012 at 01:14, GNU bug Tracking System
<help-debbugs@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@debbugs.gnu.org.
>
> --
> 8334: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8334
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: Glenn Morris <rgm@gnu.org>
> To: 8334-done@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@gmail.com>
> To: Emacs Bugs <bug-gnu-emacs@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@jpl.org-20110216231247-r8dr95j65ud08bqz
>        revno: 103306
>         date: 2011-02-16 23:12:47 +0000
>
>  Nick 'emacsw32' (from 'trunk') info:
>  revision id: lennart.borgman@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)
>
>
>