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