From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs 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 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114405c60a836b052653786a X-Trace: ger.gmane.org 1449514886 2594 80.91.229.3 (7 Dec 2015 19:01:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Dec 2015 19:01:26 +0000 (UTC) Cc: Keith David Bershatsky To: 21104@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 07 20:01:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a612A-0000wB-6T for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Dec 2015 20:01:14 +0100 Original-Received: from localhost ([::1]:56060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6129-0005pX-LR for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Dec 2015 14:01:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6124-0005os-G7 for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2015 14:01:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a611y-0005uj-9Z for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2015 14:01:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a611y-0005uc-6a for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2015 14:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a611x-0001vw-Rj for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2015 14:01:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Dec 2015 19:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21104 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21104-submit@debbugs.gnu.org id=B21104.14495148467404 (code B ref 21104); Mon, 07 Dec 2015 19:01:01 +0000 Original-Received: (at 21104) by debbugs.gnu.org; 7 Dec 2015 19:00:46 +0000 Original-Received: from localhost ([127.0.0.1]:42007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a611g-0001vL-T6 for submit@debbugs.gnu.org; Mon, 07 Dec 2015 14:00:45 -0500 Original-Received: from mail-vk0-f47.google.com ([209.85.213.47]:36837) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a611K-0001ut-Ho for 21104@debbugs.gnu.org; Mon, 07 Dec 2015 14:00:41 -0500 Original-Received: by vkay187 with SMTP id y187so108201172vka.3 for <21104@debbugs.gnu.org>; Mon, 07 Dec 2015 11:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jxH/jo5mjH4Z85tx86uv3ZidTD13lRQXXi7zBA+S6vs=; b=OfmcouCxsdjSPloBxxc/YofdeL83lLpUuJmwvLj8ydvz4iuoXmc3EBIDcxJ9Axp5ut k6OUr5xDZrxBTgZIUvnNKS6HLqe7v9a6iQsQg3C1tGb8xMAUDIUTKK1/uTE9+bNS9h/5 kw2NtwgpX72ycMqbbMTuHuqfvhVjXuoGN93sD1Y/W18UFo5hOqneW7cHT4CZ/lS3Wzq0 2Iu8uniULwiXSguUtUJYsehfFcE7qeouaoE/dV63dv0mTXS84kKegGyWHvZQANzJagGJ xL1zrQSoAwtuEHtS6OakV5QfMcbhe2xcapmx8PMnn4hNW9uix0PpUmeVukSA/AdUBETN 9GTw== X-Received: by 10.31.58.74 with SMTP id h71mr23070356vka.149.1449514821647; Mon, 07 Dec 2015 11:00:21 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Mon, 7 Dec 2015 11:00:21 -0800 (PST) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109725 Archived-At: --001a114405c60a836b052653786a Content-Type: text/plain; charset=UTF-8 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* () 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* () 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* () 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=, count=3) at eval.c:2794 #4 0x0000000100120c9e in eval_sub (form=) at eval.c:2241 #5 0x000000010012353c in Feval (form=4320886083, lexical=) at eval.c:1988 #6 0x000000010011fa43 in internal_condition_case (bfun=0x1000b1d60 , handlers=, hfun=0x1000b4930 ) at eval.c:1309 #7 0x00000001000b2d78 in top_level_1 (ignore=) at keyboard.c:1103 #8 0x000000010011faa7 in internal_catch (tag=, func=0x1000b2d20 , 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 --001a114405c60a836b052653786a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

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

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

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

After annotating the `b= set_directory' function, I see the following:

<= div>
bset_directory:
=C2=A0 buffer=3D*scratch* (/Users/anders= lindgren/build/emacs-25/src/)
=C2=A0 current_buffer=3D*scratch* (= /Users/anderslindgren/build/emacs-25/src/)
=C2=A0 new_directory= =3D/Users/anderslindgren/build/emacs-25/
bset_directory:
=C2=A0 buffer=3D *Minibuf-0* (/Users/anderslindgren/build/emacs-25/src/)<= /div>
=C2=A0 current_buffer=3D*scratch* (/Users/anderslindgren/build/em= acs-25/)
=C2=A0 new_directory=3D/Users/anderslindgren/build/emacs= -25/
bset_directory:
=C2=A0 buffer=3D *Minibuf-0* (/Use= rs/anderslindgren/build/emacs-25/)
=C2=A0 current_buffer=3D*scrat= ch* (/Users/anderslindgren/build/emacs-25/)
=C2=A0 new_directory= =3D/Users/anderslindgren/build/emacs-25/
bset_directory:
=C2=A0 buffer=3D *load* (<NOT STRING>)
=C2=A0 current_buf= fer=3D*scratch* (.)
=C2=A0 new_directory=3D.
bset_direc= tory:
=C2=A0 buffer=3D *load* (.)
=C2=A0 current_buffer= =3D*scratch* (/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Conte= nts/Resources/site-lisp)
=C2=A0 new_directory=3D/Users/anderslind= gren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/site-lisp
bset_directory:
=C2=A0 buffer=3D *load* (<NOT STRING>)
=C2=A0 current_buffer=3D*scratch* (/Users/anderslindgren/build/ema= cs-25/nextstep/Emacs.app/Contents/Resources/lisp)
=C2=A0 new_dire= ctory=3D/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Re= sources/lisp
bset_directory:
=C2=A0 buffer=3D *temp* (&= lt;NOT STRING>)
=C2=A0 current_buffer=3D*scratch* (/Users/ande= rslindgren/build/emacs-25/)
=C2=A0 new_directory=3D/Users/andersl= indgren/build/emacs-25/

Clearly, the directo= ry of *scratch* change from an absolute path to "." between two c= alls to bset_directory. The way I see it that is that the change does not o= riginate from the C parts of Emacs.

After firi= ng up gdb and setting a data break point on "current_buffer->direct= ory_" I see that it triggers as follows:

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

It looks like the call to `set_per_buffer= _value' is causing this. This is the backtrace at this point:

#0 =C2=A00x000000010010d4c9 in set_per_buffer_value [i= nlined] () at /Users/anderslindgren/build/emacs-25/src/buffer.h:1080
<= div>#1 =C2=A00x000000010010d4c9 in store_symval_forwarding (valcontents=3D0= x101898ac8, newval=3D4304500124, buf=3D0x100900a98) at data.c:1080
#2 =C2=A00x00000001001583c6 in exec_byte_code (bytestr=3D4320758472, vect= or=3D140734799802712, maxdepth=3D140734799802488, args_template=3D2, nargs= =3D0, args=3D0x7fff5fbff250) at bytecode.c:842
#3 =C2=A00x0000000= 100122ad9 in apply_lambda (fun=3D4298488197, args=3D<value temporarily u= navailable, due to optimizations>, count=3D3) at eval.c:2794
#= 4 =C2=A00x0000000100120c9e in eval_sub (form=3D<value temporarily unavai= lable, due to optimizations>) at eval.c:2241
#5 =C2=A00x000000= 010012353c in Feval (form=3D4320886083, lexical=3D<value temporarily una= vailable, due to optimizations>) at eval.c:1988
#6 =C2=A00x000= 000010011fa43 in internal_condition_case (bfun=3D0x1000b1d60 <top_level_= 2>, handlers=3D<value temporarily unavailable, due to optimizations&g= t;, hfun=3D0x1000b4930 <cmd_error>) at eval.c:1309
#7 =C2= =A00x00000001000b2d78 in top_level_1 (ignore=3D<value temporarily unavai= lable, due to optimizations>) at keyboard.c:1103
#8 =C2=A00x00= 0000010011faa7 in internal_catch (tag=3D<value temporarily unavailable, = due to optimizations>, func=3D0x1000b2d20 <top_level_1>, arg=3D0) = at eval.c:1074
#9 =C2=A00x00000001000b1c02 in command_loop () at = keyboard.c:1064
#10 0x00000001000b1cde in recursive_edit_1 () at = keyboard.c:671
#11 0x00000001000b4bbf in Frecursive_edit () at ke= yboard.c:742
#12 0x00000001000aa763 in main (argc=3D5, argv=3D0x7= fff5fbff6f0) at emacs.c:1656


= Unfortunately, I can't make head of tails of this, as gdb seems to be t= hrown off track as soon as I try to print anything or walk in the call stac= k.

However, to my untrained eye, it looks like Ema= cs is evaluating elisp code.

What can I do to pinp= oint which elisp code this is? Can I rebuild emacs with other settings, mak= ing it more gdb friendly?

Sincerely,
=C2= =A0 =C2=A0 Anders Lindgren

--001a114405c60a836b052653786a--