* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
@ 2014-10-27 13:33 Vincent Lefevre
2014-10-28 21:34 ` Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-27 13:33 UTC (permalink / raw)
To: 18851
Emacs cannot be started if the current directory has been removed:
$ mkdir foo && cd foo && rmdir ../foo && emacs -Q
emacs: `get_current_dir_name' failed: No such file or directory
zsh: exit 1
My old bug report in the Debian BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687171
In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.3)
of 2014-10-25 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11601000
System Description: Debian GNU/Linux unstable (sid)
Configured using:
`configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
--with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-z,relro'
Important settings:
value of $LC_COLLATE: POSIX
value of $LC_CTYPE: en_US.UTF-8
value of $LC_TIME: en_DK
value of $LANG: POSIX
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
display-time-mode: t
show-paren-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<escape> x r e p o r t - <tab> <return>
Recent messages:
Loading cjk-enc...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/50rnc-mode.el (source)...done
Loading /etc/emacs/site-start.d/50w3m-el.el (source)...done
Loading /home/vinc17/share/emacs/site-lisp/mutteditor.el (source)...done
Loading time...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
/usr/share/emacs24/site-lisp/css-mode/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode
/usr/share/emacs/24.4/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/site-lisp/autoconf/autotest-mode hides /usr/share/emacs/site-lisp/autotest-mode
/usr/share/emacs24/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs24/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/24.4/lisp/tempo
/usr/share/emacs24/site-lisp/flim/hex-util hides /usr/share/emacs/24.4/lisp/hex-util
/usr/share/emacs24/site-lisp/flim/md4 hides /usr/share/emacs/24.4/lisp/md4
/usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/24.4/lisp/textmodes/flyspell
/usr/share/emacs24/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/24.4/lisp/textmodes/ispell
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/24.4/lisp/textmodes/rst
/usr/share/emacs24/site-lisp/css-mode/css-mode hides /usr/share/emacs/24.4/lisp/textmodes/css-mode
/usr/share/emacs24/site-lisp/flim/hmac-md5 hides /usr/share/emacs/24.4/lisp/net/hmac-md5
/usr/share/emacs24/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/24.4/lisp/net/sasl-ntlm
/usr/share/emacs24/site-lisp/flim/sasl-cram hides /usr/share/emacs/24.4/lisp/net/sasl-cram
/usr/share/emacs24/site-lisp/flim/ntlm hides /usr/share/emacs/24.4/lisp/net/ntlm
/usr/share/emacs24/site-lisp/flim/sasl hides /usr/share/emacs/24.4/lisp/net/sasl
/usr/share/emacs24/site-lisp/flim/hmac-def hides /usr/share/emacs/24.4/lisp/net/hmac-def
/usr/share/emacs24/site-lisp/flim/sasl-digest hides /usr/share/emacs/24.4/lisp/net/sasl-digest
/usr/share/emacs24/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/24.4/lisp/language/thai-word
/usr/share/emacs24/site-lisp/html-helper-mode/html-helper-mode hides /usr/share/emacs/site-lisp/html-helper-mode/html-helper-mode
/usr/share/emacs24/site-lisp/html-helper-mode/hhm-config hides /usr/share/emacs/site-lisp/html-helper-mode/hhm-config
/usr/share/emacs24/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/site-lisp/html-helper-mode/tempo
/usr/share/emacs24/site-lisp/html-helper-mode/visual-basic-mode hides /usr/share/emacs/site-lisp/html-helper-mode/visual-basic-mode
Features:
(shadow sort gnus-util mail-extr warnings emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time cus-start
cus-load paren cc-styles cc-align cc-engine cc-vars cc-defs w3m-load
jabber-autoloads time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 16 91766 8297)
(symbols 48 20147 0)
(miscs 40 97 93)
(strings 32 15277 5245)
(string-bytes 1 446889)
(vectors 16 9914)
(vector-slots 8 393404 6798)
(floats 8 69 91)
(intervals 56 232 14)
(buffers 960 12)
(heap 1024 28626 975))
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-27 13:33 bug#18851: 24.4; emacs cannot be started if the current directory has been removed Vincent Lefevre
@ 2014-10-28 21:34 ` Glenn Morris
2014-10-29 1:28 ` Vincent Lefevre
2014-10-29 3:40 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Glenn Morris @ 2014-10-28 21:34 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
Vincent Lefevre wrote:
> Emacs cannot be started if the current directory has been removed:
It's easy to change that so that it switches to HOME instead (let's not
worry about the case of HOME being missing too!); see patch at end.
But then you run into the problem that `emacs -Q some-file' starts
editing ~/some-file instead of /some/deleted/dir/some-file. So it
probably still needs to throw an error and abort processing of any
command-line option that involves a non-absolute file name (eg `emacs -l
some-file' would also presumably do the wrong thing).
So is it worth it?
> My old bug report in the Debian BTS:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687171
IMO there's really no point reporting Emacs problems that aren't
specific to Debian (and this issues obviously isn't) to the Debian bug
tracker. They just sit there for some lengthy period of time, and only
if they get forwarded here does something happen. (Although I do look at
the Debian Emacs bug reports and had looked at that one.)
*** src/buffer.c 2014-10-04 08:20:24 +0000
--- src/buffer.c 2014-10-04 18:59:30 +0000
***************
*** 5299,5305 ****
pwd = get_current_dir_name ();
if (!pwd)
! fatal ("`get_current_dir_name' failed: %s\n", strerror (errno));
/* Maybe this should really use some standard subroutine
whose definition is filename syntax dependent. */
--- 5299,5315 ----
pwd = get_current_dir_name ();
if (!pwd)
! {
! fprintf (stderr, "Warning: `get_current_dir_name' failed: %s\n\
! Trying to change to home directory...\n", strerror (errno));
! if (getenv ("HOME"))
! {
! chdir (getenv ("HOME"));
! pwd = get_current_dir_name ();
! }
! if (!pwd)
! fatal ("`get_current_dir_name' failed: %s\n", strerror (errno));
! }
/* Maybe this should really use some standard subroutine
whose definition is filename syntax dependent. */
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-28 21:34 ` Glenn Morris
@ 2014-10-29 1:28 ` Vincent Lefevre
2014-10-29 3:50 ` Eli Zaretskii
2014-10-29 3:40 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 1:28 UTC (permalink / raw)
To: Glenn Morris; +Cc: 18851
On 2014-10-28 17:34:59 -0400, Glenn Morris wrote:
> Vincent Lefevre wrote:
>
> > Emacs cannot be started if the current directory has been removed:
>
> It's easy to change that so that it switches to HOME instead (let's not
> worry about the case of HOME being missing too!); see patch at end.
Is there any reason to switch to another directory? Why doesn't
Emacs just ignore that the current directory has been removed
(and report errors only when an access to it is really needed)?
Note that the current directory can also be removed after Emacs
is started, so I expect that Emacs already supports cases like
that.
In the init_buffer() function, it seems that pwd is used only for:
bset_directory (current_buffer, make_unibyte_string (pwd, len));
If the current directory has been removed, couldn't Qnil be used
(or, if not possible, ".")?
Note: this is the first time (well, almost) I look at the Emacs
C source.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-28 21:34 ` Glenn Morris
2014-10-29 1:28 ` Vincent Lefevre
@ 2014-10-29 3:40 ` Eli Zaretskii
1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 3:40 UTC (permalink / raw)
To: Glenn Morris; +Cc: vincent, 18851
> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 28 Oct 2014 17:34:59 -0400
> Cc: 18851@debbugs.gnu.org
>
> So is it worth it?
No, not IMO. I don't really see the practical use case behind this
bug.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 1:28 ` Vincent Lefevre
@ 2014-10-29 3:50 ` Eli Zaretskii
2014-10-29 8:09 ` Vincent Lefevre
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 3:50 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
> Date: Wed, 29 Oct 2014 02:28:02 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 18851@debbugs.gnu.org
>
> On 2014-10-28 17:34:59 -0400, Glenn Morris wrote:
> > Vincent Lefevre wrote:
> >
> > > Emacs cannot be started if the current directory has been removed:
> >
> > It's easy to change that so that it switches to HOME instead (let's not
> > worry about the case of HOME being missing too!); see patch at end.
>
> Is there any reason to switch to another directory? Why doesn't
> Emacs just ignore that the current directory has been removed
> (and report errors only when an access to it is really needed)?
Because Emacs needs to pretend to the user that it runs _in_ that
directory, so that relative file names work as you'd expect.
In this regard, Emacs is like the shell.
> Note that the current directory can also be removed after Emacs
> is started, so I expect that Emacs already supports cases like
> that.
No, it does not. Either the OS leaves the directory in existence
until Emacs exits, or the OS prevents you from removing it.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 3:50 ` Eli Zaretskii
@ 2014-10-29 8:09 ` Vincent Lefevre
2014-10-29 12:57 ` Stefan Monnier
2014-10-29 14:23 ` Eli Zaretskii
0 siblings, 2 replies; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 8:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 18851
On 2014-10-29 05:50:12 +0200, Eli Zaretskii wrote:
> > Date: Wed, 29 Oct 2014 02:28:02 +0100
> > From: Vincent Lefevre <vincent@vinc17.net>
> > Cc: 18851@debbugs.gnu.org
> >
> > On 2014-10-28 17:34:59 -0400, Glenn Morris wrote:
> > > Vincent Lefevre wrote:
> > >
> > > > Emacs cannot be started if the current directory has been removed:
> > >
> > > It's easy to change that so that it switches to HOME instead (let's not
> > > worry about the case of HOME being missing too!); see patch at end.
> >
> > Is there any reason to switch to another directory? Why doesn't
> > Emacs just ignore that the current directory has been removed
> > (and report errors only when an access to it is really needed)?
>
> Because Emacs needs to pretend to the user that it runs _in_ that
> directory, so that relative file names work as you'd expect.
I don't expect anything about reative file names. But if I type
"emacs foo", opening file "foo" from $HOME would be bad.
> In this regard, Emacs is like the shell.
The shell has no problems when the current directory has been
removed. It can still run without needing to switch to $HOME.
> > Note that the current directory can also be removed after Emacs
> > is started, so I expect that Emacs already supports cases like
> > that.
>
> No, it does not. Either the OS leaves the directory in existence
> until Emacs exits, or the OS prevents you from removing it.
Linux does neither.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 8:09 ` Vincent Lefevre
@ 2014-10-29 12:57 ` Stefan Monnier
2014-10-29 14:27 ` Eli Zaretskii
2014-10-29 14:23 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2014-10-29 12:57 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
> The shell has no problems when the current directory has been
> removed. It can still run without needing to switch to $HOME.
The problem is that the `emacs' process only access files using absolute
file names (it basically doesn't use the process's current working
directory, because every buffer has its own "current working
directory"), so when the Emacs user thinks he's using a relative file
name, Emacs really concatenates this relative file name to the value of
`default-directory' and passes *that* to the OS.
So the current Emacs C code really has no way to access a directory/file
which is not accessible from the root directory.
Stefan
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 8:09 ` Vincent Lefevre
2014-10-29 12:57 ` Stefan Monnier
@ 2014-10-29 14:23 ` Eli Zaretskii
2014-10-29 15:39 ` Andreas Schwab
2014-10-29 16:05 ` Vincent Lefevre
1 sibling, 2 replies; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 14:23 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
> Date: Wed, 29 Oct 2014 09:09:39 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: rgm@gnu.org, 18851@debbugs.gnu.org
>
> > Because Emacs needs to pretend to the user that it runs _in_ that
> > directory, so that relative file names work as you'd expect.
>
> I don't expect anything about reative file names. But if I type
> "emacs foo", opening file "foo" from $HOME would be bad.
>
> > In this regard, Emacs is like the shell.
>
> The shell has no problems when the current directory has been
> removed. It can still run without needing to switch to $HOME.
We are in violent agreement here. I wasn't advocating to change to
HOME instead; quite the contrary: Glenn asked whether doing so is
worth the trouble, and I replied that I didn't think so.
> > > Note that the current directory can also be removed after Emacs
> > > is started, so I expect that Emacs already supports cases like
> > > that.
> >
> > No, it does not. Either the OS leaves the directory in existence
> > until Emacs exits, or the OS prevents you from removing it.
>
> Linux does neither.
AFAIK, GNU/Linux does the former. The directory is not physically
removed until the last process that has an open file descriptor for it
closes that descriptor. Any attempts to reference that directory for
obtaining a new descriptor will get ENOENT, i.e. the OS pretends that
the directory doesn't exist. But existing descriptors are valid, and
can be used as usual.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 12:57 ` Stefan Monnier
@ 2014-10-29 14:27 ` Eli Zaretskii
2014-10-29 15:39 ` Vincent Lefevre
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 14:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: vincent, 18851
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, 18851@debbugs.gnu.org
> Date: Wed, 29 Oct 2014 08:57:16 -0400
>
> > The shell has no problems when the current directory has been
> > removed. It can still run without needing to switch to $HOME.
>
> The problem is that the `emacs' process only access files using absolute
> file names (it basically doesn't use the process's current working
> directory, because every buffer has its own "current working
> directory"), so when the Emacs user thinks he's using a relative file
> name, Emacs really concatenates this relative file name to the value of
> `default-directory' and passes *that* to the OS.
>
> So the current Emacs C code really has no way to access a directory/file
> which is not accessible from the root directory.
That's true, but my reading of the code is that the value of the
directory where Emacs was started is used for the following:
. the default-directory of *scratch*
. invocation-name and invocation-directory, if Emacs was invoked via
a relative file name, like "../foo/bar/emacs".
In the first case, we could try using nil instead, maybe not all hell
will break lose. The second case is rare even without the removal
(and makes no sense to me).
But I'd still like to hear the real-life use case behind this report.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 14:23 ` Eli Zaretskii
@ 2014-10-29 15:39 ` Andreas Schwab
2014-10-29 16:00 ` Eli Zaretskii
2014-10-29 16:05 ` Vincent Lefevre
1 sibling, 1 reply; 30+ messages in thread
From: Andreas Schwab @ 2014-10-29 15:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Vincent Lefevre, 18851
Eli Zaretskii <eliz@gnu.org> writes:
>> > > Note that the current directory can also be removed after Emacs
>> > > is started, so I expect that Emacs already supports cases like
>> > > that.
>> >
>> > No, it does not. Either the OS leaves the directory in existence
>> > until Emacs exits, or the OS prevents you from removing it.
>>
>> Linux does neither.
>
> AFAIK, GNU/Linux does the former. The directory is not physically
> removed until the last process that has an open file descriptor for it
> closes that descriptor. Any attempts to reference that directory for
> obtaining a new descriptor will get ENOENT, i.e. the OS pretends that
> the directory doesn't exist. But existing descriptors are valid, and
> can be used as usual.
"As usual" is an exaggeration. Basically the only valid operations on
it are fstat and fchdir. Any attempt at adding an entry to it (via
openat) will be rejected.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 14:27 ` Eli Zaretskii
@ 2014-10-29 15:39 ` Vincent Lefevre
2014-10-29 16:07 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 15:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 18851
On 2014-10-29 16:27:13 +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 18851@debbugs.gnu.org
> > Date: Wed, 29 Oct 2014 08:57:16 -0400
[...]
> > So the current Emacs C code really has no way to access a directory/file
> > which is not accessible from the root directory.
The problem is precisely when Emacs is called on a absolute pathname.
Currently Emacs quits instead of working on this file.
I repeat that I'm NOT asking that Emacs should work with a pathname
relative to a removed directory.
> That's true, but my reading of the code is that the value of the
> directory where Emacs was started is used for the following:
>
> . the default-directory of *scratch*
IMHO, if the current directory no longer exists, the default-directory
of *scratch* can be nil.
> . invocation-name and invocation-directory, if Emacs was invoked via
> a relative file name, like "../foo/bar/emacs".
>
> In the first case, we could try using nil instead, maybe not all hell
> will break lose. The second case is rare even without the removal
> (and makes no sense to me).
emacs --eval '(setq default-directory nil) (find-file "~/out")'
fails, but I wonder why.
> But I'd still like to hear the real-life use case behind this report.
Well, it happens that the current directory is removed for some
reasons, either on purpose or because of some FS error (in particular
if the FS is remote). Now, I may have already an application running
with this current directory, for instance, a MUA. If I want to write
a mail, the MUA will start an editor on an absolute pathname, Emacs
in my case, with the same current directory. But Emacs cannot be
started, just because the current directory no longer exists, meaning
that I can't write my mail without restarting the whole application.
Note: in some cases, one can still use a wrapper to change the current
directory to an existing one, but this can be a bit dangerous in
general, because if there are relative pathnames, one can end up
with loading/writing an incorrect file instead of getting an error.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 15:39 ` Andreas Schwab
@ 2014-10-29 16:00 ` Eli Zaretskii
0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 16:00 UTC (permalink / raw)
To: Andreas Schwab; +Cc: vincent, 18851
> From: Andreas Schwab <schwab@suse.de>
> Cc: Vincent Lefevre <vincent@vinc17.net>, 18851@debbugs.gnu.org
> Date: Wed, 29 Oct 2014 16:39:22 +0100
>
> > AFAIK, GNU/Linux does the former. The directory is not physically
> > removed until the last process that has an open file descriptor for it
> > closes that descriptor. Any attempts to reference that directory for
> > obtaining a new descriptor will get ENOENT, i.e. the OS pretends that
> > the directory doesn't exist. But existing descriptors are valid, and
> > can be used as usual.
>
> "As usual" is an exaggeration. Basically the only valid operations on
> it are fstat and fchdir. Any attempt at adding an entry to it (via
> openat) will be rejected.
Yes, any attempt to add descriptors will fail. By "as usual" I meant
using the descriptor to extract information, like fstat, readdir, etc.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 14:23 ` Eli Zaretskii
2014-10-29 15:39 ` Andreas Schwab
@ 2014-10-29 16:05 ` Vincent Lefevre
2014-10-29 16:21 ` Eli Zaretskii
1 sibling, 1 reply; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 16:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 18851
On 2014-10-29 16:23:24 +0200, Eli Zaretskii wrote:
> > > > Note that the current directory can also be removed after Emacs
> > > > is started, so I expect that Emacs already supports cases like
> > > > that.
> > >
> > > No, it does not. Either the OS leaves the directory in existence
> > > until Emacs exits, or the OS prevents you from removing it.
> >
> > Linux does neither.
>
> AFAIK, GNU/Linux does the former.
Not really...
> The directory is not physically removed until the last process that
> has an open file descriptor for it closes that descriptor.
OK, but if the only reference is the current working directory,
it isn't usable at all. Nevertheless, Emacs won't quit because
of that.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 15:39 ` Vincent Lefevre
@ 2014-10-29 16:07 ` Eli Zaretskii
2014-10-29 16:44 ` Vincent Lefevre
2014-10-29 16:15 ` Andreas Schwab
2014-10-30 0:39 ` Stefan Monnier
2 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 16:07 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
> Date: Wed, 29 Oct 2014 16:39:59 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 18851@debbugs.gnu.org
>
> > . the default-directory of *scratch*
>
> IMHO, if the current directory no longer exists, the default-directory
> of *scratch* can be nil.
>
> > . invocation-name and invocation-directory, if Emacs was invoked via
> > a relative file name, like "../foo/bar/emacs".
> >
> > In the first case, we could try using nil instead, maybe not all hell
> > will break lose. The second case is rare even without the removal
> > (and makes no sense to me).
>
> emacs --eval '(setq default-directory nil) (find-file "~/out")'
>
> fails, but I wonder why.
You can assume without testing that there will be problems, because
Emacs expects to find a meaningful default-directory in *scratch*.
The only question is are those problems easy to solve, or are they
extremely complex to solve.
There's one more subtlety here which you might not be aware of: when
Emacs comes up initially, its first steps through the startup process
are made before it figures out the user locale and sets up the
coding-systems required by that. Until that point, Emacs uses
undecoded file names, i.e. essentially byte streams that it can barely
interpret (unless they are pure-ASCII). So the code which gives you
trouble, that is run very early during startup, is already complicated
to support building and starting Emacs in a non-ASCII directory.
> Well, it happens that the current directory is removed for some
> reasons, either on purpose or because of some FS error (in particular
> if the FS is remote). Now, I may have already an application running
> with this current directory, for instance, a MUA. If I want to write
> a mail, the MUA will start an editor on an absolute pathname, Emacs
> in my case, with the same current directory. But Emacs cannot be
> started, just because the current directory no longer exists, meaning
> that I can't write my mail without restarting the whole application.
Can't you use the --chdir command-line argument to make Emacs start in
a safe place? Or does that not work in this situation?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 15:39 ` Vincent Lefevre
2014-10-29 16:07 ` Eli Zaretskii
@ 2014-10-29 16:15 ` Andreas Schwab
2014-10-29 16:51 ` Vincent Lefevre
2014-10-30 0:39 ` Stefan Monnier
2 siblings, 1 reply; 30+ messages in thread
From: Andreas Schwab @ 2014-10-29 16:15 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
Vincent Lefevre <vincent@vinc17.net> writes:
> emacs --eval '(setq default-directory nil) (find-file "~/out")'
>
> fails, but I wonder why.
Try this:
emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))'
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 16:05 ` Vincent Lefevre
@ 2014-10-29 16:21 ` Eli Zaretskii
0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2014-10-29 16:21 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
> Date: Wed, 29 Oct 2014 17:05:00 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: rgm@gnu.org, 18851@debbugs.gnu.org
>
> > The directory is not physically removed until the last process that
> > has an open file descriptor for it closes that descriptor.
>
> OK, but if the only reference is the current working directory,
> it isn't usable at all.
It is usable for a limited set of operations, as was mentioned in
previous messages.
> Nevertheless, Emacs won't quit because of that.
Right.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 16:07 ` Eli Zaretskii
@ 2014-10-29 16:44 ` Vincent Lefevre
0 siblings, 0 replies; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 16:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 18851
On 2014-10-29 18:07:33 +0200, Eli Zaretskii wrote:
> You can assume without testing that there will be problems, because
> Emacs expects to find a meaningful default-directory in *scratch*.
What will it do with this default-directory?
> > Well, it happens that the current directory is removed for some
> > reasons, either on purpose or because of some FS error (in particular
> > if the FS is remote). Now, I may have already an application running
> > with this current directory, for instance, a MUA. If I want to write
> > a mail, the MUA will start an editor on an absolute pathname, Emacs
> > in my case, with the same current directory. But Emacs cannot be
> > started, just because the current directory no longer exists, meaning
> > that I can't write my mail without restarting the whole application.
>
> Can't you use the --chdir command-line argument to make Emacs start in
> a safe place? Or does that not work in this situation?
It will work in some cases. But this means that it's not usable for
$EDITOR, because there are cases where the editor may be executed
with a relative pathname argument. In such a case, this argument
should be handled normally if the directory still exists. Otherwise
one should get either an error or the specified file (under Linux,
one can still open relative pathnames starting with ../ even though
the current working directory has been deleted), but getting another
file is not acceptable. With a --chdir to $HOME, there is a high risk
to get this wrong; to "/", the risk is lower, but still exists.
Unfortunately, it isn't even possible to --chdir to the old path
(obtained via /proc/$$/cwd under Linux), as the directory typically
no longer exists when I need to do that, and Emacs cannot chdir to
it, obviously. An option to set the default default-directory value
and accept non-existing directories[*] would be more useful.
[*] I suppose that this is not a problem since an existing directory
can be removed after Emacs is started, so that the default-directory
variable could point to a non-existing directory, and the current
Emacs version is fine with that (things still work, and errors are
reported gracefully).
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 16:15 ` Andreas Schwab
@ 2014-10-29 16:51 ` Vincent Lefevre
2014-10-29 17:31 ` Andreas Schwab
0 siblings, 1 reply; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 16:51 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 18851
On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote:
> Try this:
>
> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))'
Thanks. Now my question is: after starting Emacs like that, will there
be any serious problem due to the fact that default-directory value is
nil (except for the ~/out buffer)?
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 16:51 ` Vincent Lefevre
@ 2014-10-29 17:31 ` Andreas Schwab
2014-10-29 17:45 ` Vincent Lefevre
0 siblings, 1 reply; 30+ messages in thread
From: Andreas Schwab @ 2014-10-29 17:31 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
Vincent Lefevre <vincent@vinc17.net> writes:
> On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote:
>> Try this:
>>
>> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))'
>
> Thanks. Now my question is: after starting Emacs like that, will there
> be any serious problem due to the fact that default-directory value is
> nil (except for the ~/out buffer)?
The global value of default-directory isn't actually used that much, new
buffers inherit its value from the current buffer.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 17:31 ` Andreas Schwab
@ 2014-10-29 17:45 ` Vincent Lefevre
2014-10-29 18:23 ` Ivan Shmakov
0 siblings, 1 reply; 30+ messages in thread
From: Vincent Lefevre @ 2014-10-29 17:45 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 18851
On 2014-10-29 18:31:13 +0100, Andreas Schwab wrote:
> Vincent Lefevre <vincent@vinc17.net> writes:
>
> > On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote:
> >> Try this:
> >>
> >> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))'
> >
> > Thanks. Now my question is: after starting Emacs like that, will there
> > be any serious problem due to the fact that default-directory value is
> > nil (except for the ~/out buffer)?
>
> The global value of default-directory isn't actually used that much, new
> buffers inherit its value from the current buffer.
And what about the *scratch* buffer? Is this a problem like Eli said?
If any, what problems?
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 17:45 ` Vincent Lefevre
@ 2014-10-29 18:23 ` Ivan Shmakov
2014-10-29 21:11 ` Andreas Schwab
0 siblings, 1 reply; 30+ messages in thread
From: Ivan Shmakov @ 2014-10-29 18:23 UTC (permalink / raw)
To: 18851
>>>>> Vincent Lefevre <vincent@vinc17.net> writes:
>>>>> On 2014-10-29 18:31:13 +0100, Andreas Schwab wrote:
>>>>> Vincent Lefevre <vincent@vinc17.net> writes:
>>>>> On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote:
>>>> Try this:
>>>> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))'
>>> Thanks. Now my question is: after starting Emacs like that, will
>>> there be any serious problem due to the fact that default-directory
>>> value is nil (except for the ~/out buffer)?
>> The global value of default-directory isn't actually used that much,
>> new buffers inherit its value from the current buffer.
> And what about the *scratch* buffer? Is this a problem like Eli said?
> If any, what problems?
Should there be any issues with that, I guess an explicit
M-x cd RET in that same *scratch* buffer will make them go away
instantly.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 18:23 ` Ivan Shmakov
@ 2014-10-29 21:11 ` Andreas Schwab
0 siblings, 0 replies; 30+ messages in thread
From: Andreas Schwab @ 2014-10-29 21:11 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 18851
Ivan Shmakov <ivan@siamics.net> writes:
> Should there be any issues with that, I guess an explicit
> M-x cd RET in that same *scratch* buffer will make them go away
> instantly.
=> error: Wrong type argument: stringp, nil
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-29 15:39 ` Vincent Lefevre
2014-10-29 16:07 ` Eli Zaretskii
2014-10-29 16:15 ` Andreas Schwab
@ 2014-10-30 0:39 ` Stefan Monnier
2015-06-12 0:39 ` Glenn Morris
2 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2014-10-30 0:39 UTC (permalink / raw)
To: Vincent Lefevre; +Cc: 18851
> IMHO, if the current directory no longer exists, the default-directory
> of *scratch* can be nil.
Yes, that seems to be the right fix for this problem.
Of course a default-directory set to nil can cause problems down the
road, but these are either unavoidable or should likely be fixable.
Stefan
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2014-10-30 0:39 ` Stefan Monnier
@ 2015-06-12 0:39 ` Glenn Morris
2015-06-12 7:53 ` Eli Zaretskii
0 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2015-06-12 0:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Vincent Lefevre, 18851
Stefan Monnier wrote:
>> IMHO, if the current directory no longer exists, the default-directory
>> of *scratch* can be nil.
>
> Yes, that seems to be the right fix for this problem.
> Of course a default-directory set to nil can cause problems down the
> road, but these are either unavoidable or should likely be fixable.
I installed something along these lines. Now:
mkdir /tmp/foo
cd /tmp/foo
rmdir /tmp/foo
emacs -Q
works for me ~ 10% of the time. The rest of the time it segfaults.
Does someone see what's missing?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2015-06-12 0:39 ` Glenn Morris
@ 2015-06-12 7:53 ` Eli Zaretskii
2015-06-12 15:45 ` Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2015-06-12 7:53 UTC (permalink / raw)
To: Glenn Morris; +Cc: vincent, 18851
> From: Glenn Morris <rgm@gnu.org>
> Cc: Vincent Lefevre <vincent@vinc17.net>, 18851@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 11 Jun 2015 20:39:04 -0400
>
> Stefan Monnier wrote:
>
> >> IMHO, if the current directory no longer exists, the default-directory
> >> of *scratch* can be nil.
> >
> > Yes, that seems to be the right fix for this problem.
> > Of course a default-directory set to nil can cause problems down the
> > road, but these are either unavoidable or should likely be fixable.
>
> I installed something along these lines. Now:
>
> mkdir /tmp/foo
> cd /tmp/foo
> rmdir /tmp/foo
> emacs -Q
>
> works for me ~ 10% of the time. The rest of the time it segfaults.
It doesn't segfault for me. Can you show a backtrace?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2015-06-12 7:53 ` Eli Zaretskii
@ 2015-06-12 15:45 ` Glenn Morris
2015-06-12 19:31 ` Eli Zaretskii
0 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2015-06-12 15:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: vincent, 18851
Eli Zaretskii wrote:
> It doesn't segfault for me. Can you show a backtrace?
Here you go (maybe it's more like 50% than 10%):
bt:
#0 0x00007ffff12e2c45 in __memcpy_ssse3_back () from /lib64/libc.so.6
#1 0x00007ffff69df80d in SmcSetProperties () from /lib64/libSM.so.6
#2 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xeae5b0,
clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0)
at xsmfns.c:262
#3 0x00007ffff69e1c5d in _SmcProcessMessage () from /lib64/libSM.so.6
#4 0x00007ffff67d1b97 in IceProcessMessages () from /lib64/libICE.so.6
#5 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0)
at xsmfns.c:110
#6 0x00000000006374ab in wait_reading_process_output (time_limit=0, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0,
just_wait_proc=0) at process.c:5087
#7 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2fe8,
used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:3927
#8 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3500, used_mouse_menu=0x7fffffff394f)
at keyboard.c:2200
#9 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3500, prev_event=...,
used_mouse_menu=0x7fffffff394f) at keyboard.c:2265
#10 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=...,
used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:2875
#11 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b20,
bufsize=30, prompt=..., dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9159
#12 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407
#13 0x00000000005e229a in internal_condition_case (
bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>)
at eval.c:1348
#14 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139
#15 0x00000000005e1a2d in internal_catch (tag=...,
func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108
#16 0x000000000054859a in command_loop () at keyboard.c:1118
#17 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728
#18 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799
#19 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3fe8) at emacs.c:1626
bt full:
#0 0x00007ffff12e2c45 in __memcpy_ssse3_back () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007ffff69df80d in SmcSetProperties () from /lib64/libSM.so.6
No symbol table info available.
#2 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xeae5b0,
clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0)
at xsmfns.c:262
props = {0x7fffffff2830,
0x7fffffff2850,
0x7fffffff2870,
0x7fffffff2890,
0xeaf100}
prop_ptr = {{
name = 0x14d52c0 "CloneCommand",
type = 0xd69190 "LISTofARRAY8",
num_vals = 1,
vals = 0x7fffffff26f0
},
{
name = 0xe6ca50 "Program",
type = 0x11c4820 "ARRAY8",
num_vals = 1,
vals = 0x7fffffff2700
},
{
name = 0xd537a0 "UserID",
type = 0xe6cf10 "ARRAY8",
num_vals = 1,
vals = 0x7fffffff2710
},
{
name = 0xd55160 "RestartCommand",
type = 0xdb2390 "LISTofARRAY8",
num_vals = 5,
vals = 0xe7e640
},
{
name = 0x7fffffff28c0 "\020$|\366\377\177",
type = 0x4860ff6efdd1c200 <Address 0x4860ff6efdd1c200 out of bounds>,
num_vals = -159636464,
vals = 0x7ffff7fc6000
}}
values = {{
length = 45,
value = 0xeaed30
},
{
length = 5,
value = 0xe647c0
},
{
length = 7,
value = 0xe61940
},
{
length = 15820013,
value = 0x1
},
{
length = 500000000,
value = 0x7ffff7de44c9 <check_match.9344+89>
},
{
length = 0,
value = 0x7ffff67c16a8
},
{
length = 10,
value = 0x5b
},
{
length = -456570963,
value = 0x7ffff7de4ccb <do_lookup_x+1803>
},
{
length = 499658979,
value = 0x7fffffff27b0
},
{
length = -159640236,
value = 0x7ffff67c2410
},
{
length = -55104,
value = 0x7fffffff28b0
},
{
length = 45,
value = 0x5341d
},
{
length = 0,
value = 0x0
},
{
length = -134455296,
value = 0x406e31
},
{
length = -159634424,
value = 0x403e10
},
{
length = 0,
value = 0x10000008f
},
{
length = 20813427,
value = 0x7fffffff2978
},
{
length = -54960,
value = 0x1
},
{
length = 16,
value = 0x7fffffff2910
},
{
length = -55248,
value = 0x4860ff6efdd1c200
}}
vp = 0xe7e640
val_idx = 3
vp_idx = 4
props_idx = 4
i = 2
smid_opt = 0xe0e010 "--smid=2d8bff4ea-7fc2-496f-bf2b-dd182557f83d"
chdir_opt = 0x0
user_login_name = {
i = 18641748
}
cwd = 0x0
#3 0x00007ffff69e1c5d in _SmcProcessMessage () from /lib64/libSM.so.6
No symbol table info available.
#4 0x00007ffff67d1b97 in IceProcessMessages () from /lib64/libICE.so.6
No symbol table info available.
#5 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0)
at xsmfns.c:110
ret = 11
#6 0x00000000006374ab in wait_reading_process_output (time_limit=0, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0,
just_wait_proc=0) at process.c:5087
d = 0xc5cde8 <fd_callback_info+264>
timeout_reduced_for_timers = true
channel = 11
nfds = 2
Available = {
fds_bits = {3072,
0 <repeats 15 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = true
check_delay = 0
no_avail = false
xerrno = 11
proc = {
i = 0
}
timeout = {
tv_sec = 0,
tv_nsec = 0
}
end_time = {
tv_sec = 0,
tv_nsec = 0
}
got_some_input = -1
count = 2
#7 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2fe8,
used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:3927
do_display = true
obj = {
i = 0
}
#8 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3500, used_mouse_menu=0x7fffffff394f)
at keyboard.c:2200
c = {
i = 0
}
save_jump = {{
__jmpbuf = {0,
0,
0,
0,
0,
0,
0,
0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
kb = 0x1dcd6500
#9 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3500, prev_event=...,
used_mouse_menu=0x7fffffff394f) at keyboard.c:2265
nextevt = {
i = 13589501
}
frame = 0x7fffffff3260
terminal = 0xcf5bfd
events = {{
i = 13076624
},
{
i = 0
},
{
i = 0
},
{
i = 140737488302560
},
{
i = 5506081
},
{
i = 499992607
},
{
i = 140737488302624
},
{
i = 5560959
},
{
i = 13076624
},
{
i = 4294967296
},
{
i = 0
},
{
i = 140737488302624
},
{
i = 5506081
},
{
i = 0
},
{
i = 140737488302672
},
{
i = 5587002
}}
n = 0
#10 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=...,
used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:2875
c = {
i = 0
}
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {0,
-601185235832345470,
19028509,
43008,
0,
0,
-601185235687641982,
601184789779639426},
__mask_was_saved = 0,
__saved_mask = {
__val = {140737488303456,
5506081,
0,
140737488303744,
5643396,
0,
0,
43008,
0,
0,
0,
0,
0,
0,
0,
0}
}
}}
save_jump = {{
__jmpbuf = {17083104,
18474576,
0,
13627136,
20957107,
17083104,
13076624,
0},
__mask_was_saved = 5397952,
__saved_mask = {
__val = {140737488303248,
13076624,
0,
140737488303456,
140737488303280,
5506081,
0,
140737488303456,
6187899,
0,
2,
0,
6601013,
0,
5506321,
5397952}
}
}}
tem = {
i = 774368
}
save = {
i = 0
}
previous_echo_area_message = {
i = 0
}
also_record = {
i = 0
}
reread = false
gcpro1 = {
next = 0xcfef45,
var = 0x7020,
nvars = 140737488303248
}
gcpro2 = {
next = 0xc78890 <lispsym>,
var = 0xcfef40,
nvars = 140737488303072
}
polling_stopped_here = true
orig_kboard = 0xea8ae0
#11 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b20,
bufsize=30, prompt=..., dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9159
interrupted_kboard = 0xea8ae0
interrupted_frame = 0x12d7830
key = {
i = 140737488304528
}
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = {
i = 1
}
count = 2
t = 0
echo_start = 0
keys_start = 0
current_binding = {
i = 17376275
}
first_event = {
i = 0
}
first_unbound = 31
mock_input = 0
fkey = {
parent = {
i = 17494291
},
map = {
i = 17494291
},
start = 0,
end = 0
}
keytran = {
parent = {
i = 13581891
},
map = {
i = 13581891
},
start = 0,
end = 0
}
indec = {
parent = {
i = 17494307
},
map = {
i = 17494307
},
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = {
i = 0
}
original_uppercase = {
i = 140737488304704
}
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0xcfef40
fake_prefixed_keys = {
i = 0
}
gcpro1 = {
next = 0xc78890 <lispsym>,
var = 0x0,
nvars = 13674661
}
#12 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407
cmd = {
i = 140737488305248
}
keybuf = {{
i = 0
},
{
i = 4274848
},
{
i = 13076624
},
{
i = 0
},
{
i = 0
},
{
i = 140737488304992
},
{
i = 5506081
},
{
i = 0
},
{
i = 140737488305168
},
{
i = 6187899
},
{
i = 16935731
},
{
i = 2
},
{
i = 0
},
{
i = 12914144
},
{
i = 8350928
},
{
i = 0
},
{
i = 16935731
},
{
i = 13104320
},
{
i = 10674453
},
{
i = 21807312
},
{
i = 140737488305168
},
{
i = 6186898
},
{
i = 3
},
{
i = 140737488305136
},
{
i = 27696
},
{
i = 27696
},
{
i = 0
},
{
i = 13104320
},
{
i = 4274848
},
{
i = 0
}}
i = 0
prev_modiff = 0
prev_buffer = 0x0
already_adjusted = false
#13 0x00000000005e229a in internal_condition_case (
bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>)
at eval.c:1348
val = {
i = 16935731
}
c = 0xe6b410
#14 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139
val = {
i = 15119072
}
#15 0x00000000005e1a2d in internal_catch (tag=...,
func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108
val = {
i = 0
}
c = 0xe6b2e0
#16 0x000000000054859a in command_loop () at keyboard.c:1118
No locals.
#17 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728
count = 1
val = {
i = 140737488305600
}
#18 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799
count = 0
buffer = {
i = 0
}
#19 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3fe8) at emacs.c:1626
dummy = {
i = 80
}
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {
rlim_cur = 33554432,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
A debugging session is active.
Inferior 1 [process 6488] will be killed.
Quit anyway? (y or n)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2015-06-12 15:45 ` Glenn Morris
@ 2015-06-12 19:31 ` Eli Zaretskii
2015-06-13 1:29 ` Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2015-06-12 19:31 UTC (permalink / raw)
To: Glenn Morris; +Cc: vincent, 18851
> From: Glenn Morris <rgm@gnu.org>
> Cc: monnier@iro.umontreal.ca, vincent@vinc17.net, 18851@debbugs.gnu.org
> Date: Fri, 12 Jun 2015 11:45:18 -0400
>
> Eli Zaretskii wrote:
>
> > It doesn't segfault for me. Can you show a backtrace?
>
> Here you go (maybe it's more like 50% than 10%):
>
> bt:
>
> #0 0x00007ffff12e2c45 in __memcpy_ssse3_back () from /lib64/libc.so.6
> #1 0x00007ffff69df80d in SmcSetProperties () from /lib64/libSM.so.6
> #2 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xeae5b0,
> clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0)
> at xsmfns.c:262
Maybe SMC cannot work with current directory removed?
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2015-06-12 19:31 ` Eli Zaretskii
@ 2015-06-13 1:29 ` Glenn Morris
2015-06-13 7:56 ` Eli Zaretskii
0 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2015-06-13 1:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: vincent, 18851
Eli Zaretskii wrote:
> Maybe SMC cannot work with current directory removed?
It looks that way, though xsmfns.c already seems to take the necessary
precautions for that case, and a super-quick look at the libSM source
didn't show any obvious issue. The only solution I can think of is to
disable session-management in such a case:
--- a/src/xsmfns.c
+++ b/src/xsmfns.c
@@ -28,6 +28,7 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */
#include <unistd.h>
#include <sys/param.h>
+#include <errno.h>
#include <stdio.h>
#include "lisp.h"
@@ -402,6 +403,14 @@ x_session_initialize (struct x_display_info *dpyinfo)
SmcCallbacks callbacks;
ptrdiff_t name_len = 0;
+ /* libSM seems to crash if pwd is missing - see bug#18851. */
+ if (! get_current_dir_name ())
+ {
+ fprintf (stderr, "Disabling session management due to pwd error: %s\n",
+ emacs_strerror (errno));
+ return;
+ }
+
ice_fd = -1;
doing_interact = false;
For completeness, here's a backtrace with debug libSM and libICE included.
(What about the address-out-of-bounds in #3?)
bt:
#0 0x00007ffff12e5640 in __memcpy_ssse3_back () from /lib64/libc.so.6
#1 0x00007ffff69df80d in memcpy (__len=<optimized out>,
__src=<optimized out>, __dest=0x15b675c) at /usr/include/bits/string3.h:51
#2 SmcSetProperties (smcConn=<optimized out>, numProps=4,
props=0x7fffffff28e0) at sm_client.c:379
#3 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xea0370,
clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0)
at xsmfns.c:262
#4 0x00007ffff69e1c5d in _SmcProcessMessage (iceConn=0xea0f90,
clientData=0xea0370, opcode=<optimized out>, length=<optimized out>,
swap=0, replyWait=<optimized out>, replyReadyRet=0x7fffffff2a00)
at sm_process.c:241
#5 0x00007ffff67d1b97 in IceProcessMessages (iceConn=0xea0f90, replyWait=0x0,
replyReadyRet=0x0) at process.c:386
#6 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0)
at xsmfns.c:110
#7 0x0000000000637484 in wait_reading_process_output (time_limit=0, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0,
just_wait_proc=0) at process.c:5081
#8 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2ff8,
used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:3927
#9 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3510, used_mouse_menu=0x7fffffff395f)
at keyboard.c:2200
#10 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3510, prev_event=...,
used_mouse_menu=0x7fffffff395f) at keyboard.c:2265
#11 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=...,
used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:2875
#12 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b30,
bufsize=30, prompt=..., dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9159
#13 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407
#14 0x00000000005e229a in internal_condition_case (
bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>)
at eval.c:1348
#15 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139
#16 0x00000000005e1a2d in internal_catch (tag=...,
func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108
#17 0x000000000054859a in command_loop () at keyboard.c:1118
#18 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728
#19 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799
#20 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3ff8) at emacs.c:1626
#0 0x00007ffff12e5640 in __memcpy_ssse3_back () from /lib64/libc.so.6
bt full:
#1 0x00007ffff69df80d in memcpy (__len=<optimized out>,
__src=<optimized out>, __dest=0x15b675c) at /usr/include/bits/string3.h:51
No locals.
#2 SmcSetProperties (smcConn=<optimized out>, numProps=4,
props=0x7fffffff28e0) at sm_client.c:379
_i = <optimized out>
_j = 4
iceConn = 0xea0f90
pMsg = <optimized out>
pBuf = 0x15b675c ""
pStart = 0x15b65d0 "\004"
bytes = 400
#3 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xea0370,
clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0)
at xsmfns.c:262
props = {0x7fffffff2840,
0x7fffffff2860,
0x7fffffff2880,
0x7fffffff28a0,
0xea0a00}
prop_ptr = {{
name = 0xd887e0 "CloneCommand",
type = 0xda4930 "LISTofARRAY8",
num_vals = 1,
vals = 0x7fffffff2700
},
{
name = 0xe733b0 "Program",
type = 0xea0ba0 "ARRAY8",
num_vals = 1,
vals = 0x7fffffff2710
},
{
name = 0xf533a0 "UserID",
type = 0xf54070 "ARRAY8",
num_vals = 1,
vals = 0x7fffffff2720
},
{
name = 0xf54150 "RestartCommand",
type = 0xf54230 "LISTofARRAY8",
num_vals = 5,
vals = 0x1008d10
},
{
name = 0x7fffffff28d0 "\020$|\366\377\177",
type = 0x712665236f658c00 <Address 0x712665236f658c00 out of bounds>,
num_vals = -159636464,
vals = 0x7ffff7fc6000
}}
values = {{
length = 45,
value = 0xea1460
},
{
length = 5,
value = 0xe64690
},
{
length = 7,
value = 0xe61810
},
{
length = 20421677,
value = 0x1
},
{
length = 500000000,
value = 0x7ffff7de44c9 <check_match.9344+89>
},
{
length = 0,
value = 0x7ffff67c16a8
},
{
length = 10,
value = 0x5b
},
{
length = -456570963,
value = 0x7ffff7de4ccb <do_lookup_x+1803>
},
{
length = 499925475,
value = 0x7fffffff27c0
},
{
length = -159640236,
value = 0x7ffff67c2410
},
{
length = -55088,
value = 0x7fffffff28c0
},
{
length = 45,
value = 0x1231d
},
{
length = 0,
value = 0x0
},
{
length = -134455296,
value = 0x406e31
},
{
length = -159634424,
value = 0x403e10
},
{
length = 0,
value = 0x10000008f
},
{
length = 17519331,
value = 0x7fffffff2988
},
{
length = -54944,
value = 0x1
},
{
length = 16,
value = 0x7fffffff2920
},
{
length = -55232,
value = 0x712665236f658c00
}}
vp = 0x1008d10
val_idx = 3
vp_idx = 4
props_idx = 4
i = 2
smid_opt = 0xf2c690 "--smid=26667490d-357a-48ea-b51a-9851440ed37c"
chdir_opt = 0x0
user_login_name = {
i = 18634644
}
cwd = 0x0
#4 0x00007ffff69e1c5d in _SmcProcessMessage (iceConn=0xea0f90,
clientData=0xea0370, opcode=<optimized out>, length=<optimized out>,
swap=0, replyWait=<optimized out>, replyReadyRet=0x7fffffff2a00)
at sm_process.c:241
pMsg = 0xea4910
errVal = 0 '\000'
errOffset = -1
smcConn = <optimized out>
#5 0x00007ffff67d1b97 in IceProcessMessages (iceConn=0xea0f90, replyWait=0x0,
replyReadyRet=0x0) at process.c:386
processProc = <optimized out>
processMsgInfo = <optimized out>
header = 0xea4910
replyReady = 0
useThisReplyWait = 0x0
retStatus = IceProcessMessagesSuccess
#6 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0)
at xsmfns.c:110
ret = 11
#7 0x0000000000637484 in wait_reading_process_output (time_limit=0, nsecs=0,
read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0,
just_wait_proc=0) at process.c:5081
d = 0xc5cde8 <fd_callback_info+264>
timeout_reduced_for_timers = true
channel = 11
nfds = 1
Available = {
fds_bits = {2048,
0 <repeats 15 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = true
check_delay = 0
no_avail = false
xerrno = 11
proc = {
i = 0
}
timeout = {
tv_sec = 0,
tv_nsec = 499969517
}
end_time = {
tv_sec = 5506081,
tv_nsec = 0
}
got_some_input = -1
count = 2
#8 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2ff8,
used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:3927
do_display = true
obj = {
i = 0
}
#9 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3510, used_mouse_menu=0x7fffffff395f)
at keyboard.c:2200
c = {
i = 0
}
save_jump = {{
__jmpbuf = {0,
0,
0,
0,
0,
0,
0,
0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
kb = 0x1dcd6500
#10 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7fffffff3510, prev_event=...,
used_mouse_menu=0x7fffffff395f) at keyboard.c:2265
nextevt = {
i = 13589501
}
frame = 0x7fffffff3270
terminal = 0xcf5bfd
events = {{
i = 13076624
},
{
i = 0
},
{
i = 0
},
{
i = 140737488302576
},
{
i = 5506081
},
{
i = 499988655
},
{
i = 140737488302640
},
{
i = 5560959
},
{
i = 13076624
},
{
i = 4294967296
},
{
i = 0
},
{
i = 140737488302640
},
{
i = 5506081
},
{
i = 0
},
{
i = 140737488302688
},
{
i = 5587002
}}
n = 0
#11 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=...,
used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:2875
c = {
i = 0
}
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {0,
-2368210174059533009,
17161965,
43008,
0,
0,
-2368210174200042193,
2368209730108206383},
__mask_was_saved = 0,
__saved_mask = {
__val = {140737488303472,
5506081,
0,
140737488303760,
5643396,
0,
0,
43008,
0,
566608,
0,
0,
0,
12476142,
9644764,
12476117}
}
}}
save_jump = {{
__jmpbuf = {16844352,
18467472,
5390848,
13627136,
20960179,
16844352,
13076624,
0},
__mask_was_saved = 5390848,
__saved_mask = {
__val = {140737488303264,
13076624,
0,
140737488303472,
140737488303296,
5506081,
0,
140737488303472,
6187899,
0,
2,
0,
6600973,
0,
5506321,
5390848}
}
}}
tem = {
i = 774368
}
save = {
i = 0
}
previous_echo_area_message = {
i = 0
}
also_record = {
i = 0
}
reread = false
gcpro1 = {
next = 0x7fffffff3400,
var = 0x540614 <CAR_SAFE+47>,
nvars = 21474836480
}
gcpro2 = {
next = 0xc78890 <lispsym>,
var = 0x7fffffff33e0,
nvars = 5506081
}
polling_stopped_here = true
orig_kboard = 0xe9ab20
#12 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b30,
bufsize=30, prompt=..., dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9159
interrupted_kboard = 0xe9ab20
interrupted_frame = 0x12d3c50
key = {
i = 140737488304592
}
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = {
i = 5510211
}
count = 2
t = 0
echo_start = 0
keys_start = 0
current_binding = {
i = 17524643
}
first_event = {
i = 0
}
first_unbound = 31
mock_input = 0
fkey = {
parent = {
i = 17364467
},
map = {
i = 17364467
},
start = 0,
end = 0
}
keytran = {
parent = {
i = 13581891
},
map = {
i = 13581891
},
start = 0,
end = 0
}
indec = {
parent = {
i = 17364547
},
map = {
i = 17364547
},
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = {
i = 0
}
original_uppercase = {
i = 13076624
}
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0xcfef40
fake_prefixed_keys = {
i = 0
}
gcpro1 = {
next = 0x0,
var = 0x54a6a4 <safe_run_hook_funcall+93>,
nvars = 26832
}
#13 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407
cmd = {
i = 140737488305264
}
keybuf = {{
i = 0
},
{
i = 4274848
},
{
i = 13076624
},
{
i = 0
},
{
i = 0
},
{
i = 140737488305008
},
{
i = 5506081
},
{
i = 0
},
{
i = 140737488305184
},
{
i = 6187899
},
{
i = 16933475
},
{
i = 2
},
{
i = 0
},
{
i = 12914144
},
{
i = 8354000
},
{
i = 0
},
{
i = 16933475
},
{
i = 13104320
},
{
i = 10674493
},
{
i = 21808368
},
{
i = 140737488305184
},
{
i = 6186898
},
{
i = 3
},
{
i = 140737488305152
},
{
i = 27696
},
{
i = 27696
},
{
i = 0
},
{
i = 13104320
},
{
i = 4274848
},
{
i = 0
}}
i = 0
prev_modiff = 0
prev_buffer = 0x0
already_adjusted = false
#14 0x00000000005e229a in internal_condition_case (
bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>)
at eval.c:1348
val = {
i = 16933475
}
c = 0xe6b410
#15 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139
val = {
i = 15119072
}
#16 0x00000000005e1a2d in internal_catch (tag=...,
func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108
val = {
i = 0
}
c = 0xe6b2e0
#17 0x000000000054859a in command_loop () at keyboard.c:1118
No locals.
#18 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728
count = 1
val = {
i = 140737488305616
}
#19 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799
count = 0
buffer = {
i = 0
}
#20 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3ff8) at emacs.c:1626
dummy = {
i = 80
}
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {
rlim_cur = 33554432,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
A debugging session is active.
Inferior 1 [process 3610] will be killed.
Quit anyway? (y or n)
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2015-06-13 1:29 ` Glenn Morris
@ 2015-06-13 7:56 ` Eli Zaretskii
2015-06-13 23:45 ` Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2015-06-13 7:56 UTC (permalink / raw)
To: Glenn Morris; +Cc: vincent, 18851
> From: Glenn Morris <rgm@gnu.org>
> Cc: monnier@iro.umontreal.ca, vincent@vinc17.net, 18851@debbugs.gnu.org
> Date: Fri, 12 Jun 2015 21:29:05 -0400
>
> Eli Zaretskii wrote:
>
> > Maybe SMC cannot work with current directory removed?
>
> It looks that way, though xsmfns.c already seems to take the necessary
> precautions for that case, and a super-quick look at the libSM source
> didn't show any obvious issue. The only solution I can think of is to
> disable session-management in such a case:
I think you should install this. After all, how frequent is this
scenario that we should bother about session-management in that case?
> For completeness, here's a backtrace with debug libSM and libICE included.
> (What about the address-out-of-bounds in #3?)
props[4] is garbage, because there are only 4 valid elements in this
case (props_idx = 4). So it's just GDB displaying a garbled 5th
element of props[] array.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed
2015-06-13 7:56 ` Eli Zaretskii
@ 2015-06-13 23:45 ` Glenn Morris
0 siblings, 0 replies; 30+ messages in thread
From: Glenn Morris @ 2015-06-13 23:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: vincent, 18851
Eli Zaretskii wrote:
> I think you should install this. After all, how frequent is this
> scenario that we should bother about session-management in that case?
Agreed & installed.
Starting Emacs with PWD deleted now works.
The basics (M-x cd, find-file) work, but I'm sure there are many places
that do not expect default-directory to be nil. I doubt it is worth
correcting them all.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2015-06-13 23:45 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-27 13:33 bug#18851: 24.4; emacs cannot be started if the current directory has been removed Vincent Lefevre
2014-10-28 21:34 ` Glenn Morris
2014-10-29 1:28 ` Vincent Lefevre
2014-10-29 3:50 ` Eli Zaretskii
2014-10-29 8:09 ` Vincent Lefevre
2014-10-29 12:57 ` Stefan Monnier
2014-10-29 14:27 ` Eli Zaretskii
2014-10-29 15:39 ` Vincent Lefevre
2014-10-29 16:07 ` Eli Zaretskii
2014-10-29 16:44 ` Vincent Lefevre
2014-10-29 16:15 ` Andreas Schwab
2014-10-29 16:51 ` Vincent Lefevre
2014-10-29 17:31 ` Andreas Schwab
2014-10-29 17:45 ` Vincent Lefevre
2014-10-29 18:23 ` Ivan Shmakov
2014-10-29 21:11 ` Andreas Schwab
2014-10-30 0:39 ` Stefan Monnier
2015-06-12 0:39 ` Glenn Morris
2015-06-12 7:53 ` Eli Zaretskii
2015-06-12 15:45 ` Glenn Morris
2015-06-12 19:31 ` Eli Zaretskii
2015-06-13 1:29 ` Glenn Morris
2015-06-13 7:56 ` Eli Zaretskii
2015-06-13 23:45 ` Glenn Morris
2014-10-29 14:23 ` Eli Zaretskii
2014-10-29 15:39 ` Andreas Schwab
2014-10-29 16:00 ` Eli Zaretskii
2014-10-29 16:05 ` Vincent Lefevre
2014-10-29 16:21 ` Eli Zaretskii
2014-10-29 3:40 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).