GNU bug report logs - #21104
25.0.50; relative paths are added to load-path without -nsl

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: esq <at> lawlist.com, 21104 <at> debbugs.gnu.org
Subject: Re: bug#21104: 25.0.50;
 relative paths are added to load-path without -nsl (bug#21104)
Date: Mon, 07 Dec 2015 21:33:57 +0200

> Date: Mon, 7 Dec 2015 20:00:21 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> Cc: Keith David Bershatsky <esq <at> lawlist.com>
> 
> It looks like the call to `set_per_buffer_value' is causing this. This is the
> backtrace at this point:
> 
> #0 0x000000010010d4c9 in set_per_buffer_value [inlined] () at
> /Users/anderslindgren/build/emacs-25/src/buffer.h:1080
> #1 0x000000010010d4c9 in store_symval_forwarding (valcontents=0x101898ac8,
> newval=4304500124, buf=0x100900a98) at data.c:1080
> #2 0x00000001001583c6 in exec_byte_code (bytestr=4320758472,
> vector=140734799802712, maxdepth=140734799802488, args_template=2, nargs=0,
> args=0x7fff5fbff250) at bytecode.c:842
> #3 0x0000000100122ad9 in apply_lambda (fun=4298488197, args=<value temporarily
> unavailable, due to optimizations>, count=3) at eval.c:2794
> #4 0x0000000100120c9e in eval_sub (form=<value temporarily unavailable, due to
> optimizations>) at eval.c:2241
> #5 0x000000010012353c in Feval (form=4320886083, lexical=<value temporarily
> unavailable, due to optimizations>) at eval.c:1988
> #6 0x000000010011fa43 in internal_condition_case (bfun=0x1000b1d60
> <top_level_2>, handlers=<value temporarily unavailable, due to optimizations>,
> hfun=0x1000b4930 <cmd_error>) at eval.c:1309
> #7 0x00000001000b2d78 in top_level_1 (ignore=<value temporarily unavailable,
> due to optimizations>) at keyboard.c:1103
> #8 0x000000010011faa7 in internal_catch (tag=<value temporarily unavailable,
> due to optimizations>, func=0x1000b2d20 <top_level_1>, arg=0) at eval.c:1074
> #9 0x00000001000b1c02 in command_loop () at keyboard.c:1064
> #10 0x00000001000b1cde in recursive_edit_1 () at keyboard.c:671
> #11 0x00000001000b4bbf in Frecursive_edit () at keyboard.c:742
> #12 0x00000001000aa763 in main (argc=5, argv=0x7fff5fbff6f0) at emacs.c:1656
> 
> Unfortunately, I can't make head of tails of this, as gdb seems to be thrown
> off track as soon as I try to print anything or walk in the call stack.
> 
> However, to my untrained eye, it looks like Emacs is evaluating elisp code.
> 
> What can I do to pinpoint which elisp code this is? Can I rebuild emacs with
> other settings, making it more gdb friendly?

Are you saying that xbacktrace doesn't work at this point?

Previous Next

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