bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Stephen Berman]

1. Let ~/.emacs consist solely of this sexp:

   (custom-set-variables
    '(recentf-mode t))

2. Let recentf-list contain a Tramp-style ftp pathname, e.g. let
~/.recentf be the following (with a made-up ftp-address, but the problem
also arises with real addresses):

-------------8<-------------
;;; Automatically generated by `recentf' on Tue Jul  7 14:42:00 2009.

(setq recentf-list
      '(
        "/ftp:anonymous@ftp.bla.org:/"
        ))

(setq recentf-filter-changer-current 'nil)

\f
;; Local Variables:
;; coding: utf-8-emacs
;; End:
------------->8-------------

3. emacs -Q
=> There is a pause after the echo area displays the message "Cleaning
up the recentf list...", lasting more or less 30 seconds, during which
Emacs is completely unresponsive.  Then the pause ends, Emacs completes
startup and runs normally.

I have experienced this pause only with the first graphical Emacs
started after booting my machine, i.e. when started as above in a tty,
Emacs does not pause.  The first time I experienced the pause was with
GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of
2009-06-23 on escher (my first build after the 23.1 branch), and it has
continued with every subsequent build, including my current one.  It
does not happen with GNU Emacs 23.0.94.2 (i686-pc-linux-gnu, GTK+
Version 2.14.4) of 2009-06-14 on escher (my last pre-branch build).

I initially reported this on emacs-devel and suspected the new Tramp
GVFS code, but Michael Albinus could not reproduce the problem.  See
http://thread.gmane.org/gmane.emacs.devel/111714 for our exchange.


In GNU Emacs 23.1.50.4 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-08-21 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Michael Albinus]

Stephen Berman <stephen.berman@gmx.net> writes:

> I initially reported this on emacs-devel and suspected the new Tramp
> GVFS code, but Michael Albinus could not reproduce the problem.  See
> http://thread.gmane.org/gmane.emacs.devel/111714 for our exchange.

As already said, I cannot reproduce it here. Just tried again.

Could you, please, start Emacs from gdb? When it is stalled, interrupt
it, and show the backtrace.

Best regards, Michael.

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Stephen Berman]

My report contained an obvious, yet crucial, typo, so here it is
corrected:

On Sun, 23 Aug 2009 13:35:47 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> 1. Let ~/.emacs consist solely of this sexp:
>
>    (custom-set-variables
>     '(recentf-mode t))
>
> 2. Let recentf-list contain a Tramp-style ftp pathname, e.g. let
> ~/.recentf be the following (with a made-up ftp-address, but the problem
> also arises with real addresses):
>
> -------------8<-------------
> ;;; Automatically generated by `recentf' on Tue Jul  7 14:42:00 2009.
>
> (setq recentf-list
>       '(
>         "/ftp:anonymous@ftp.bla.org:/"
>         ))
>
> (setq recentf-filter-changer-current 'nil)
>
> \f
> ;; Local Variables:
> ;; coding: utf-8-emacs
> ;; End:
> ------------->8-------------
>
> 3. emacs -Q

This should of course be:
3. emacs

> => There is a pause after the echo area displays the message "Cleaning
> up the recentf list...", lasting more or less 30 seconds, during which
> Emacs is completely unresponsive.  Then the pause ends, Emacs completes
> startup and runs normally.
>
> I have experienced this pause only with the first graphical Emacs
> started after booting my machine, i.e. when started as above in a tty,
> Emacs does not pause.  The first time I experienced the pause was with
> GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of
> 2009-06-23 on escher (my first build after the 23.1 branch), and it has
> continued with every subsequent build, including my current one.  It
> does not happen with GNU Emacs 23.0.94.2 (i686-pc-linux-gnu, GTK+
> Version 2.14.4) of 2009-06-14 on escher (my last pre-branch build).
>
> I initially reported this on emacs-devel and suspected the new Tramp
> GVFS code, but Michael Albinus could not reproduce the problem.  See
> http://thread.gmane.org/gmane.emacs.devel/111714 for our exchange.
>
>
> In GNU Emacs 23.1.50.4 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
>  of 2009-08-21 on escher
> Windowing system distributor `The X.Org Foundation', version 11.0.10502000
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: en_US.UTF-8
>   value of $XMODIFIERS: @im=local
>   locale-coding-system: utf-8-unix
>   default-enable-multibyte-characters: t

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Stephen Berman]

On Mon, 24 Aug 2009 12:22:31 +0200 Michael Albinus <michael.albinus@gmx.de> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>>> Could you, please, start Emacs from gdb? When it is stalled, interrupt
>>> it, and show the backtrace.
>>
>> Here it is; I hope it helps shed some light on the problem.
>
> It does, indeed:
>
>> Lisp Backtrace:
>> "dbus-call-method" (0xbfffc504)
>> "byte-code" (0xbfffc5b0)
>> "dbus-ping" (0xbfffc844)
>
> So for whatever reasons, one of the three dbus-ping calls in
> tramp-gvfs.el hangs (for the default 25 sec timeout of D-Bus calls).
>
> Could you, please, check the following patch? It restricts every
> dbus-ping to 0.1 sec. It will still leave a short delay for you, but
> this might be tolerable.

To test whether the patch fixes the problem I presumably have to wait
till I reboot the machine, which may not be till tomorrow.  Does it
suffice to simply apply the patch and restart Emacs, or do I need to
redump or rebuild Emacs?

Thanks for the quick response.

Steve Berman

PS: If the patch works, before you commit it you should, in the doc
string of dbus-ping, change "25.000" to "25,000": `.' and `,' have the
opposite roles in German and English numerals.

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Michael Albinus]

Stephen Berman <stephen.berman@gmx.net> writes:

> To test whether the patch fixes the problem I presumably have to wait
> till I reboot the machine, which may not be till tomorrow.  Does it
> suffice to simply apply the patch and restart Emacs, or do I need to
> redump or rebuild Emacs?

You shall byte-compile dbus.el and tramp-gvfs.el.

> Thanks for the quick response.
>
> Steve Berman
>
> PS: If the patch works, before you commit it you should, in the doc
> string of dbus-ping, change "25.000" to "25,000": `.' and `,' have the
> opposite roles in German and English numerals.

I'll do. Thanks.

Best regards, Michael.

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Stephen Berman]

On Mon, 24 Aug 2009 13:30:41 +0200 Michael Albinus <michael.albinus@gmx.de> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> To test whether the patch fixes the problem I presumably have to wait
>> till I reboot the machine, which may not be till tomorrow.  Does it
>> suffice to simply apply the patch and restart Emacs, or do I need to
>> redump or rebuild Emacs?
>
> You shall byte-compile dbus.el and tramp-gvfs.el.

I had occasion to reboot my machine today, so I could test your patch
against my bug recipe -- it worked as expected: only a barely noticeable
pause at the "Cleaning up the recentf list..." message, then startup
completed as usual.  I will test it again tomorrow with my init file and
normal recentf-file, but I expect it will also work with them.  Thanks!
(Still, I wonder what in my system is causing dbus-ping to hang...)

Steve Berman

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Michael Albinus]

Stephen Berman <stephen.berman@gmx.net> writes:

> (Still, I wonder what in my system is causing dbus-ping to hang...)

Hard to say, there are 3 different pings in tramp-gvfs.el. But it
happens only the very first time you start the system, and it does not
depend on restart of your (windowing) session. So it shall be a ping
towards the system bus: either the check for bluez, or the check for
zeroconf. (In theory!) the services shall be autostarted, or the ping
shall raise an error; both events do not happen on your system.

If you are interested in, you could continue to check (you know what to
change), but I hope the case is closed for Emacs.

After your report tomorrow, I'll close the ticket.

> Steve Berman

Thanks for your patient testing, and best regards, Michael.

bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode

[Stephen Berman]

On Mon, 24 Aug 2009 21:28:41 +0200 Michael Albinus <michael.albinus@gmx.de> wrote:

> After your report tomorrow, I'll close the ticket.

As expected, with your patches and my init file and recentf-file, there
was now only a slight, certainly tolerable, pause after the "cleaning
recentf-list" message, so for me this problem is fixed, at least as far
as Emacs is concerned.

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> (Still, I wonder what in my system is causing dbus-ping to hang...)
>
> Hard to say, there are 3 different pings in tramp-gvfs.el. But it
> happens only the very first time you start the system, and it does not
> depend on restart of your (windowing) session. So it shall be a ping
> towards the system bus: either the check for bluez, or the check for
> zeroconf. (In theory!) the services shall be autostarted, or the ping
> shall raise an error; both events do not happen on your system.
>
> If you are interested in, you could continue to check (you know what to
> change), but I hope the case is closed for Emacs.

Thanks for the tips and again for the quick fix!

Steve Berman

bug#4239: marked as done (23.1.50; Pause during Emacs startup with recentf-mode)

[Emacs bug Tracking System]

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

Your message dated Tue, 25 Aug 2009 12:45:51 +0200
with message-id <nqprak2mu8.fsf@alcatel-lucent.de>
and subject line Re: bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode
has caused the Emacs bug report #4239,
regarding 23.1.50; Pause during Emacs startup with recentf-mode
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4239: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4239
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4342 bytes --]

From: Stephen Berman <stephen.berman@gmx.net>
To: emacs-pretest-bug@gnu.org
Subject: 23.1.50; Pause during Emacs startup with recentf-mode
Date: Sun, 23 Aug 2009 13:35:47 +0200
Message-ID: <87k50un4oc.fsf@escher.local.home>

1. Let ~/.emacs consist solely of this sexp:

   (custom-set-variables
    '(recentf-mode t))

2. Let recentf-list contain a Tramp-style ftp pathname, e.g. let
~/.recentf be the following (with a made-up ftp-address, but the problem
also arises with real addresses):

-------------8<-------------
;;; Automatically generated by `recentf' on Tue Jul  7 14:42:00 2009.

(setq recentf-list
      '(
        "/ftp:anonymous@ftp.bla.org:/"
        ))

(setq recentf-filter-changer-current 'nil)

\f
;; Local Variables:
;; coding: utf-8-emacs
;; End:
------------->8-------------

3. emacs -Q
=> There is a pause after the echo area displays the message "Cleaning
up the recentf list...", lasting more or less 30 seconds, during which
Emacs is completely unresponsive.  Then the pause ends, Emacs completes
startup and runs normally.

I have experienced this pause only with the first graphical Emacs
started after booting my machine, i.e. when started as above in a tty,
Emacs does not pause.  The first time I experienced the pause was with
GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of
2009-06-23 on escher (my first build after the 23.1 branch), and it has
continued with every subsequent build, including my current one.  It
does not happen with GNU Emacs 23.0.94.2 (i686-pc-linux-gnu, GTK+
Version 2.14.4) of 2009-06-14 on escher (my last pre-branch build).

I initially reported this on emacs-devel and suspected the new Tramp
GVFS code, but Michael Albinus could not reproduce the problem.  See
http://thread.gmane.org/gmane.emacs.devel/111714 for our exchange.


In GNU Emacs 23.1.50.4 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-08-21 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t


[-- Attachment #3: Type: message/rfc822, Size: 2780 bytes --]

From: Michael Albinus <michael.albinus@gmx.de>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: <4239-done@emacsbugs.donarmstrong.com>
Subject: Re: bug#4239: 23.1.50; Pause during Emacs startup with recentf-mode
Date: Tue, 25 Aug 2009 12:45:51 +0200
Message-ID: <nqprak2mu8.fsf@alcatel-lucent.de>

Stephen Berman <stephen.berman@gmx.net> writes:

> As expected, with your patches and my init file and recentf-file, there
> was now only a slight, certainly tolerable, pause after the "cleaning
> recentf-list" message, so for me this problem is fixed, at least as far
> as Emacs is concerned.

OK, I've committed the changes to the trunk.

>> So it shall be a ping towards the system bus: either the check for
>> bluez, or the check for zeroconf.

I've updated my fix slightly: for bluez and zeroconf, I do not ping
anymore. Instead of, there is a check just for the existence of the
service names on the system bus. There is no need to autostart the
services, if they do not run already.

> Steve Berman

Best regards, Michael.