From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Sutton Newsgroups: gmane.emacs.bugs Subject: bug#36502: Fwd: bug#36502: 27.0.50; infinite loop in file-name-case-insensitive-p Date: Thu, 4 Jul 2019 22:05:59 -0500 Message-ID: References: <7fa570d6-74a7-56d0-af9e-48ade20551b8@cornell.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005b7f5a058ce66063" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="26462"; mail-complaints-to="usenet@blaine.gmane.org" To: 36502@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 05 15:39:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hjOQj-0006kq-ER for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Jul 2019 15:39:13 +0200 Original-Received: from localhost ([::1]:53268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjOQi-0004qH-GM for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Jul 2019 09:39:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40026) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjOQb-0004q2-Te for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 09:39:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjOQY-0007Yy-C5 for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 09:39:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43703) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hjOQY-0007Wo-1J for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 09:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hjOQX-0001St-Sv for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 09:39:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Sutton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jul 2019 13:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36502 X-GNU-PR-Package: emacs Original-Received: via spool by 36502-submit@debbugs.gnu.org id=B36502.15623338985578 (code B ref 36502); Fri, 05 Jul 2019 13:39:01 +0000 Original-Received: (at 36502) by debbugs.gnu.org; 5 Jul 2019 13:38:18 +0000 Original-Received: from localhost ([127.0.0.1]:52524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjOPq-0001Ru-77 for submit@debbugs.gnu.org; Fri, 05 Jul 2019 09:38:18 -0400 Original-Received: from mail-lj1-f175.google.com ([209.85.208.175]:40042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjEYC-00056b-VZ for 36502@debbugs.gnu.org; Thu, 04 Jul 2019 23:06:18 -0400 Original-Received: by mail-lj1-f175.google.com with SMTP id a21so7781567ljh.7 for <36502@debbugs.gnu.org>; Thu, 04 Jul 2019 20:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpsutton-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BVafVbJ18jZSw5KFUos1wejjzANZuGez0L8mKaZNQZs=; b=vFT7oxzNiCeEazCShQ3zRjg+z6GaGrWk1y83pYTrzUJTkQp59CbVdiQgIYYXXjW2cB F++pFvwQh+B/kRl3qvtzJXOhpLOvKwrIG8ZOADkjEb7gOJyupH9PyBLSZxv2beVzgx/D LC3R0wbmMFRyN2qEv7AsdfjnNuZhtiVoij06YbCe4tpkAFG635A51mWNj1ll8fhRyxzn VQZ4nygjPsJIXwQ7vTcrkJ5kJXG/C/oae/UhThYHQMz6WSGThUhKSGxa3/yuwsOqit3K uEXfRVv7MpwMk8mjVQ5OuxdfPtupmcQ9XRqhxQncIohl7gkqA36zK/YxR0CyP4mP6stp MUEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BVafVbJ18jZSw5KFUos1wejjzANZuGez0L8mKaZNQZs=; b=mk3cf+9mY7e8w8gVC7sQf26CoW7HB+c+iY5jZlMH5Rl7sgsKxhE3Uup8scsiKap0VM eI1A4q3j2QqixHlw/ibqwrFMWY/ar1+nODmD5D63OLjFPVzmh0G9Uh9KrL0sFRsglTGe TOXalb8//yqAuIC4POJ+HJDs1Gp+ye2aMGXbcgImD/dZddmReTUGaX5greoihrZFO5+c OzgOiFcjjadwJS02h4yl+CzypnGF4nmO4Qhw3MoDs8EQjPyFY+iSwMgzSkFmFaOzc+gm plAq217ZxdwJeQlpChZzikH3f51jWf7ln9znJbn69+YCb+HLKFWnGlOZSTK8kip2WGAl jy1Q== X-Gm-Message-State: APjAAAXTp1NlHQAcBFDFr/yRQ8C4os5r/Tlcv865J6pvwsmBsDh94jKQ m2luNIhPwlvOOE3mkmg7LkpIfLqJ2Azs1mBfgxa6bTKqwyE= X-Google-Smtp-Source: APXvYqwOfBODDoFVBSzveRVHD+ZPjPCKo79JozHU2leOJCMnVEDiV+52NvVHMVLJv3pWRyju1E4wINs/YoY/oWkbGDQ= X-Received: by 2002:a2e:989a:: with SMTP id b26mr687453ljj.31.1562295970526; Thu, 04 Jul 2019 20:06:10 -0700 (PDT) In-Reply-To: X-Mailman-Approved-At: Fri, 05 Jul 2019 09:38:16 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:162123 Archived-At: --0000000000005b7f5a058ce66063 Content-Type: text/plain; charset="UTF-8" (repeated email as I omitted the bug email address) Ken I believe I've figured it out and there was an important bit I left out. The test in CIDER was ensuring a buffer was named correctly based on the current project, and it set the current project's directory by setq'ing default-directory. This seems to be a big no-no as the default directory expects a well formed path. The doc string of default-directory being: Name of default directory of current buffer. It should be an absolute directory name; on GNU and Unix systems, these names start with `/' or `~' and end with `/'. To interactively change the default directory, use command `cd'. So the "bug" can be reproduced by the following, which was the important bits of the test: (let ((default-directory "made/up/project/location")) (file-name-case-insensitive-p default-directory)) * note this will freeze your emacs I believe your change caused the behavior here but it seems like a reasonable change and CIDER is definitely not honoring the assumptions in `default-directory`. We had some careless usages of this variable in our tests and it seems like it has finally caught up to us. Unless you consider this an edge case to watch for (and I can't imagine you do) it seems like this should be closed. Sorry for the noise and thanks for your help Dan Sutton On Thu, Jul 4, 2019 at 9:36 PM Daniel Sutton wrote: > First thanks so much for your quick attention, Ken. I really appreciate > it. I threw in some printlning and seeing the following output: > > originally: path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/ > > filename from c: > path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA > > filename from c: > path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA > > filename from c: > path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA > > filename from c: > path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA > > filename from c: > path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA > > from the following: > > if (NILP (Ffile_exists_p (filename))) > { > filename = Ffile_name_directory (filename); > while (NILP (Ffile_exists_p (filename))) > { > Lisp_Object newname = expand_and_dir_to_file (filename); > /* Avoid infinite loop if the root is reported as non-existing > (impossible?). */ > if (!NILP (Fstring_equal (newname, filename))) > break; > filename = newname; > message_with_string("filename from c: %s\n", filename, 1); > } > } > > So it seems to be growing the wrong way. I suppose this is the problem > actually in expand_and_dir_to_file but i can't imagine why. > > On Thu, Jul 4, 2019 at 8:32 PM Ken Brown wrote: > >> Please keep the bug address in the Cc. >> >> On 7/4/2019 3:35 PM, Daniel Sutton wrote: >> > Locally when running `(expand-file-name "path/to/dirA/" nil)` it >> expands >> > to "/home/dan/projects/dev/cider/test/path/to/dirA/" >> > >> > when running under cask it expands to "/path/to/dirA/" >> >> So moving up the file system tree should eventually lead you to "/". I >> don't >> see why you're getting an infinite loop. >> >> Ken >> > --0000000000005b7f5a058ce66063 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(repeated email as I omitted th= e bug email address)

Ken I believe I've figured it out and there was an imp= ortant bit I left out.

The test in CIDE= R was ensuring a buffer was named correctly based on the current project, a= nd it set the current project's directory by setq'ing default-direc= tory. This seems to be a big no-no as the default directory expects a well = formed path. The doc string of default-directory being:

Name of default directory of current buffer.
It should be an absolute d= irectory name; on GNU and Unix systems,
these names start with `/' o= r `~' and end with `/'.
To interactively change the default dire= ctory, use command `cd'.=C2=A0

So the "bug"= ; can be reproduced by the following, which was the important bits of the t= est:

(let ((default-directory "made/up/projec= t/location"))
=C2=A0 (file-name-case-insensitive-p default-director= y))

* note this will freeze your emacs

I believe your change caused the behavior here but it see= ms like a reasonable change and CIDER is definitely not honoring the assump= tions in `default-directory`. We had some careless usages of this variable = in our tests and it seems like it has finally caught up to us. Unless you c= onsider this an edge case to watch for (and I can't imagine you do) it = seems like this should be closed.

Sorry for the no= ise and thanks for your help
Dan Sutton

On Thu, Jul 4, 2019 = at 9:36 PM Daniel Sutton <dan@dpsutton.com> wrote:
First thanks so much for your quic= k attention, Ken. I really appreciate it. I threw in some printlning and se= eing the following output:

originally: path/to/dirA/path= /to/dirA/path/to/dirA/path/to/dirA/

filename from c: path/to/dirA/pa= th/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA

filen= ame from c: path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dir= A/path/to/dirA/path/to/dirA/path/to/dirA

filename from c: path/to/di= rA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to= /dirA/path/to/dirA/path/to/dirA/path/to/dirA

filename from c: path/t= o/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/pat= h/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA<= br>
filename from c: path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA= /path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/d= irA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA

<= /div>
from the following:

if (NILP (Ffile_exis= ts_p (filename)))
=C2=A0 {
=C2=A0 =C2=A0 filename =3D Ffile_name_dire= ctory (filename);
=C2=A0 =C2=A0 while (NILP (Ffile_exists_p (filename)))=
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Lisp_Object newna= me =3D expand_and_dir_to_file (filename);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /*= Avoid infinite loop if the root is reported as non-existing
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(impossible?). =C2=A0*/
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 if (!NILP (Fstring_equal (newname, filename)))
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 filename =3D new= name;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 message_with_string("filename fro= m c: %s\n", filename, 1);
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 }

So it seems to be growing the wrong way. I suppose t= his is the problem actually in expand_and_dir_to_file but i can't imagi= ne why.

On Thu, Jul 4, 2019 at 8:32 PM Ken Brown <kbrown@cornell.edu> wrote:
Please keep the bu= g address in the Cc.

On 7/4/2019 3:35 PM, Daniel Sutton wrote:
> Locally when running `(expand-file-name "path/to/dirA/" nil)= ` it expands
> to=C2=A0"/home/dan/projects/dev/cider/test/path/to/dirA/" >
> when running under cask it expands to "/path/to/dirA/"

So moving up the file system tree should eventually lead you to "/&quo= t;.=C2=A0 I don't
see why you're getting an infinite loop.

Ken
--0000000000005b7f5a058ce66063--