all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Anders Lindgren <andlind@gmail.com>
To: 21104@debbugs.gnu.org
Cc: Keith David Bershatsky <esq@lawlist.com>
Subject: bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)
Date: Mon, 7 Dec 2015 20:00:21 +0100	[thread overview]
Message-ID: <CABr8eba8JJdqiwNCc6h=F6musGD7obZGmoNgKqK_391g4p8HNw@mail.gmail.com> (raw)
In-Reply-To: <m2d1zl4e32.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4343 bytes --]

Hi,

I decided to take a look at this, as I think it should be solved before
Emacs 25 is released.

Unfortunately, I haven't found the cause of it, bit I would like to share
what I found so far.

First, the call to `get_current_dir_name' in `init_buffer' returns an
absolute path, so this is not the cause.

After annotating the `bset_directory' function, I see the following:

bset_directory:
  buffer=*scratch* (/Users/anderslindgren/build/emacs-25/src/)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/src/)
  new_directory=/Users/anderslindgren/build/emacs-25/
bset_directory:
  buffer= *Minibuf-0* (/Users/anderslindgren/build/emacs-25/src/)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/)
  new_directory=/Users/anderslindgren/build/emacs-25/
bset_directory:
  buffer= *Minibuf-0* (/Users/anderslindgren/build/emacs-25/)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/)
  new_directory=/Users/anderslindgren/build/emacs-25/
bset_directory:
  buffer= *load* (<NOT STRING>)
  current_buffer=*scratch* (.)
  new_directory=.
bset_directory:
  buffer= *load* (.)
  current_buffer=*scratch*
(/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/site-lisp)

new_directory=/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/site-lisp
bset_directory:
  buffer= *load* (<NOT STRING>)
  current_buffer=*scratch*
(/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/lisp)

new_directory=/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/lisp
bset_directory:
  buffer= *temp* (<NOT STRING>)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/)
  new_directory=/Users/anderslindgren/build/emacs-25/

Clearly, the directory of *scratch* change from an absolute path to "."
between two calls to bset_directory. The way I see it that is that the
change does not originate from the C parts of Emacs.

After firing up gdb and setting a data break point on
"current_buffer->directory_" I see that it triggers as follows:

  * bset_directory (setting the directory to an absolute path)
  * set_buffer_internal_1 (twice, setting the directory to an absolute path)
  * set_per_buffer_value (see below)
  * bset_direcory (here, *scratch* already has "." in the directory field)

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?

Sincerely,
    Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 5358 bytes --]

  parent reply	other threads:[~2015-12-07 19:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-21 17:26 bug#21104: 25.0.50; relative paths are added to load-path without -nsl Sam Steingold
2015-07-21 17:41 ` bug#21104: workaround for the bug Sam Steingold
2015-07-22 18:02 ` bug#21104: 25.0.50; relative paths are added to load-path without -nsl Glenn Morris
2015-07-22 18:26   ` Sam Steingold
2015-07-22 18:37     ` Glenn Morris
2015-07-22 19:41       ` Sam Steingold
2015-07-22 21:58         ` Glenn Morris
2015-12-07 19:00 ` Anders Lindgren [this message]
2015-12-07 19:33   ` bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104) Eli Zaretskii
2015-12-07 22:09     ` Anders Lindgren
2015-12-08  1:22       ` Glenn Morris
2015-12-08  1:32         ` Glenn Morris
2015-12-08 16:05         ` Eli Zaretskii
2015-12-08 17:06           ` Andreas Schwab
2015-12-08 17:40             ` Eli Zaretskii
2015-12-08 18:16               ` Andreas Schwab
2015-12-08 17:54           ` Glenn Morris
2015-12-08 18:20             ` Eli Zaretskii
2015-12-08 19:16               ` Anders Lindgren
2015-12-08 19:21                 ` Glenn Morris
2015-12-08 20:03                   ` Anders Lindgren
2015-12-09  8:49                     ` Andreas Schwab
2015-12-08 20:05                   ` Eli Zaretskii
2015-12-08  3:35       ` Eli Zaretskii
2015-12-09 10:33 ` bug#21104: Don't add "." to load-path -- fixed Anders Lindgren

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='CABr8eba8JJdqiwNCc6h=F6musGD7obZGmoNgKqK_391g4p8HNw@mail.gmail.com' \
    --to=andlind@gmail.com \
    --cc=21104@debbugs.gnu.org \
    --cc=esq@lawlist.com \
    /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.