bug#18556: 24.4.50; update-file-autoloads never ends

bug#18556: 24.4.50; update-file-autoloads never ends

[Vincent Belaïche]

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


Hello,

I try the following where `$' denotes the shell prompt, and `-|' denotes
printed output:

$ emacs -Q --batch '--eval=(update-file-autoloads "balance.el" nil "~/.emacs.d/etc/my_autoloads.el")'
-| Generating autoloads for balance.el...

and my problem is that IT NEVER ENDS.

Attached below is the balance.el file causing the trouble.
-----------------------------------------------------------------------

[-- Attachment #2: balance.el --]
[-- Type: application/emacs-lisp, Size: 113487 bytes --]

[-- Attachment #3: Type: text/plain, Size: 6602 bytes --]

-----------------------------------------------------------------------

My Emacs version is
-----------------------------------------------------------------------
GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-09-23 on CHOUNEK
-----------------------------------------------------------------------

VBR,
   Vincent.

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-09-23 on CHOUNEK
Repository revision: 117919 monnier@iro.umontreal.ca-20140922182202-1xk0sig32d1av0lw
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --prefix=c:/Programme/GNU/Emacs --without-jpeg
 --without-tiff --without-gif --without-png 'CPPFLAGS= -DFOR_MSW=1 -I
 C:/Programme/GNU/installation/emacs-install/libXpm-3.5.8/include -I
 C:/Programme/GNU/installation/emacs-install/libXpm-3.5.8/src -L
 c:/Programme/GNU/installation/emacs-install/libXpm-3.5.8/src'
 CPP=/mingw/bin/cpp.exe
 PKG_CONFIG_PATH=/mingw/lib/pkgconfig:/usr/local/lib/pkgconfig'

Configured features:
XPM SOUND NOTIFY ACL ZLIB

Important settings:
  value of $EMACSPATH: c:\Programme\NGNU\CVS;C:\Programme\GNU\GnuPG;c:\Programme\apache-ant-1.8.0\bin;c:\msys\1.0\bin;c:\msys\1.0\mingw\bin;
  value of $LANG: FRA
  locale-coding-system: cp1252

Major mode: Shell

Minor modes in effect:
  TeX-PDF-mode: t
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  mail-abbrevs-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  electric-indent-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
  line-number-mode: t

Recent input:
x m k r c ] SPC t y p o SPC i n SPC m a n y <backspace> 
u a l <down> <down> <down> <down> F o u n d SPC <return> 
<return> C-y <C-left> <C-left> <C-left> <C-left> <C-left> 
<C-left> _ <right> <right> _ <up> <return> <up> <up> 
<end> SPC i n SPC M-SPC C-y <return> <return> p a g 
e SPC <up> <up> <end> , SPC o f SPC 2 SPC D e c m <backspace> 
e m b e r SPC 2 0 1 3 , SPC p a g e SPC 7 / 3 6 , SPC 
d o c u m e n t a t i o n SPC o f SPC - n o r c SPC 
o p t i o n . <down> <down> <down> <down> <up> <up> 
C-a C-k C-k C-x C-o <up> <end> <backspace> : SPC ` 
i s ' SPC s h o u l d SPC r e a d SPC ' <backspace> 
ì <backspace> ` i t ' SPC <backspace> , SPC s h o l 
d <backspace> <backspace> u l d n ' t SPC i t SPC ? 
<down> <down> <end> <return> <return> <return> SPC 
SPC SPC V i n c e n t . <up> V B R , C-x 1 <prior> 
<up> <up> <up> <up> <up> <up> C-a <return> <up> H e 
l l o SPC J p o h n , <return> <up> <up> <down> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<backspace> <down> <down> <up> <up> <up> <up> <up> 
<up> <C-right> <left> <left> M-d <down> <down> <down> 
<down> <down> <down> <down> <down> <down> C-c C-s y 
C-x b <return> M-x r e p o r t - b u f <tab> <backspace> 
g <tab> e m <tab> <return>

Recent messages:
Sending via mail...
250 2.1.0 <vincent.belaiche@gmail.com> sender ok
250 2.1.5 <vincent.belaiche@gmail.com> recipient ok
250 2.1.5 <collins@phys.psu.edu> recipient ok
354 enter mail, end with "." on a line by itself
Sending email 
Sending email done
250 2.0.0 vFer1o0032maGi203FerKl mail accepted for delivery
221 2.0.0 mwinf5d59 ME closing connection
Sending...done

Load-path shadows:
d:/msys/1.0/home/Vincent/.emacs.d/etc/custom hides c:/Programme/GNU/Emacs/share/emacs/24.4.50/lisp/custom
c:/Programme/GNU/Emacs/share/emacs/24.4.50/lisp/loaddefs hides c:/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loaddefs

Features:
(shadow warnings emacsbug pcmpl-unix balance autoload lisp-mnt
parse-time vc-cvs plain-tex etags doc-view image-mode ps-mode find-dired
iso-transl calc-map picture calc-vec tabify table vc ediff-vers
ediff-merg ediff-wind ediff-diff ediff-mult ediff-help ediff-init
ediff-util ediff cal-move cal-menu calendar cal-loaddefs calc-store
perl-mode calc-lang thingatpt calc-embed calc-yank calc-units calccomp
calc-alg calc-aent calc-menu calc-prog calc-forms cus-edit add-log
texmathp tex-info texinfo make-mode mule-util vc-dispatcher vc-svn
preview prv-emacs reftex-dcr reftex-auc reftex reftex-vars tex-buf
noutline outline font-latex latex tex-style tex advice tex-mode compile
latexenc dired-aux mailcap whitespace diff-mode easy-mmode sh-script
smie executable rect vc-bzr autoconf autoconf-mode shell pcomplete
comint ansi-color ring bbdb-com crm network-stream starttls tls
mailalias smtpmail auth-source password-cache qp mail-extr sort
bbdb-message sendmail gnus-util message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils gmm-utils mailheader dired-x
dired ses unsafep misearch multi-isearch hl-line eieio-opt speedbar
sb-image ezimage dframe find-func help-mode help-fns jka-compr info
accents-ascii eieio byte-opt bytecomp byte-compile cconv eieio-core
tex-mik preview-latex tex-site auto-loads calc-mathfloat calc-math
edmacro kmacro w32utils java-init cl-macs cl gv bsh-init recentf
tree-widget wid-edit cl-loaddefs cl-lib generic-x cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
template mailabbrev iswitchb cus-start cus-load bbdb easymenu bbdb-site
timezone bbdb-loaddefs calc-misc calc-arith calc-ext calc calc-loaddefs
calc-macs skeleton load-path-to-cedet-svn time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars 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 w32notify w32
multi-tty emacs)

Memory information:
((conses 8 773132 199581)
 (symbols 24 43851 86)
 (miscs 20 2350 4804)
 (strings 16 108692 22663)
 (string-bytes 1 4446193)
 (vectors 8 44769)
 (vector-slots 4 1606851 63216)
 (floats 8 223 967)
 (intervals 28 51226 4510)
 (buffers 516 81))

bug#18556: 24.4.50; update-file-autoloads never ends

[Paul Eggert]

I could not reproduce the problem with Emacs trunk bzr 117958 built on 
Fedora 20 with GCC 4.9.1, in either 32- or 64-bit builds, and in either 
en_US.UTF-8 or fr_FR.iso885915@euro locales.  Here's the behavior I 
observed:

$ ls -l /tmp/d/balance.el
-rw-r--r--. 1 eggert eggert 110567 Sep 26 09:38 /tmp/d/balance.el
$ time src/emacs -Q --batch '--eval=(update-file-autoloads 
"/tmp/d/balance.el" nil "/tmp/d/my_autoloads.el")'
Generating autoloads for /tmp/d/balance.el...
Wrote /tmp/d/my_autoloads.el
Generating autoloads for /tmp/d/balance.el...done

real    0m0.041s
user    0m0.033s
sys    0m0.007s
$ ls -l /tmp/d/my_autoloads.el
-rw-r--r--. 1 eggert eggert 260 Sep 26 09:56 /tmp/d/my_autoloads.el
$ cat /tmp/d/my_autoloads.el
;;; my_autoloads.el --- automatically extracted autoloads
;;
;;; Code:

\f
(provide 'my_autoloads)
;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; coding: utf-8
;; End:
;;; my_autoloads.el ends here

bug#18556: 24.4.50; update-file-autoloads never ends

[Eli Zaretskii]

> Date: Fri, 26 Sep 2014 09:59:38 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 18556@debbugs.gnu.org
> 
> I could not reproduce the problem with Emacs trunk bzr 117958 built on 
> Fedora 20 with GCC 4.9.1, in either 32- or 64-bit builds, and in either 
> en_US.UTF-8 or fr_FR.iso885915@euro locales.

And I couldn't reproduce it on MS-Windows with trunk r117955.  It
finishes almost instantly for me.

Vincent, if you attach GDB to the hung Emacs and type "thread apply
all bt" at the GDB prompt, what do you see?

bug#18556: 24.4.50; update-file-autoloads never ends

[Eli Zaretskii]

> Date: Fri, 26 Sep 2014 20:21:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: vincent.b.1@hotmail.fr, 18556@debbugs.gnu.org
> 
> > Date: Fri, 26 Sep 2014 09:59:38 -0700
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Cc: 18556@debbugs.gnu.org
> > 
> > I could not reproduce the problem with Emacs trunk bzr 117958 built on 
> > Fedora 20 with GCC 4.9.1, in either 32- or 64-bit builds, and in either 
> > en_US.UTF-8 or fr_FR.iso885915@euro locales.
> 
> And I couldn't reproduce it on MS-Windows with trunk r117955.  It
> finishes almost instantly for me.
> 
> Vincent, if you attach GDB to the hung Emacs and type "thread apply
> all bt" at the GDB prompt, what do you see?

Btw, is it possible that one of the packages that balance.el requires
is not what we have in the Emacs trunk, but you have its different
version from some other repository?

bug#18556: 24.4.50; update-file-autoloads never ends

[Vincent Belaïche]

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

Hello Eli & Paul,

----------------------------------------
> Date: Fri, 26 Sep 2014 20:24:57 +0300
> From: eliz@gnu.org
> Subject: Re: bug#18556: 24.4.50; update-file-autoloads never ends
> To: eggert@cs.ucla.edu; vincent.b.1@hotmail.fr
> CC: 18556@debbugs.gnu.org
>
> > Date: Fri, 26 Sep 2014 20:21:16 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: vincent.b.1@hotmail.fr, 18556@debbugs.gnu.org
> >
> > > Date: Fri, 26 Sep 2014 09:59:38 -0700
> > > From: Paul Eggert <eggert@cs.ucla.edu>
> > > Cc: 18556@debbugs.gnu.org
> > >
> > > I could not reproduce the problem with Emacs trunk bzr 117958 built on
> > > Fedora 20 with GCC 4.9.1, in either 32- or 64-bit builds, and in either
> > > en_US.UTF-8 or fr_FR.iso885915@euro locales.
> >
> > And I couldn't reproduce it on MS-Windows with trunk r117955. It
> > finishes almost instantly for me.
> >
> > Vincent, if you attach GDB to the hung Emacs and type "thread apply
> > all bt" at the GDB prompt, what do you see?
>
> Btw, is it possible that one of the packages that balance.el requires
> is not what we have in the Emacs trunk, but you have its different
> version from some other repository?

It is fully possible that balance.el requires some package not in the
emacs trunk as I have this in my ~/.emacs.d/init.el

-----------------------------------------------------------------------
  ;; remove CEDET/EIEIO/SPEEDBAR that are distributed with EMACS from the load
  ;; path, and replace them with those of CEDET distribution
(load "~/.emacs.d/etc/load-path-to-cedet-svn.el")
-----------------------------------------------------------------------

This is because I develop jpicedt with jdee, and at some point of time
the eieio of Emacs was too old compared to what jdee expected. Anyhow,
In don't think that this is the problem because I can reproduce the
hanging with -Q command line option.

Attached is the gdb session log that Paul desired.

VBR,
  Vincent.


[-- Attachment #2: gbd session log --]
[-- Type: text/plain, Size: 6280 bytes --]

Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\Programme\GNU\Emacs\bin>gdb
gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) attach 231132
Attaching to process 231132
[New Thread 231132.0x382e8]
[New Thread 231132.0x38130]
[New Thread 231132.0x38750]
[New Thread 231132.0x382e4]
Reading symbols from c:\Programme\GNU\Emacs\bin\emacs.exe...done.
(gdb) thread apply all bt

Thread 4 (Thread 231132.0x382e4):
#0  0x7c91120f in ntdll!DbgUiConnectToDbg ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c962119 in ntdll!KiIntSystemCall () from C:\WINDOWS\system32\ntdll.dll
#2  0x00000005 in ?? ()
#3  0x00000004 in ?? ()
#4  0x00000001 in ?? ()
#5  0x0d35ffd0 in ?? ()
#6  0x00000000 in ?? ()

Thread 3 (Thread 231132.0x38750):
#0  0x7c91e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7e3991be in USER32!GetProcessWindowStation ()
   from C:\WINDOWS\system32\user32.dll
#2  0x7e3991f1 in USER32!GetMessageW () from C:\WINDOWS\system32\user32.dll
#3  0x01157e8c in w32_msg_pump (msg_buf=<optimized out>) at w32fns.c:2498
#4  0x011585e0 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2724
#5  0x7c80b729 in KERNEL32!GetModuleFileNameA ()
   from C:\WINDOWS\system32\kernel32.dll
#6  0x00000000 in ?? ()

Thread 2 (Thread 231132.0x38130):
#0  0x7c91e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c91d21a in ntdll!ZwDelayExecution () from C:\WINDOWS\system32\ntdll.dll
#2  0x7c8023f1 in SleepEx () from C:\WINDOWS\system32\kernel32.dll
#3  0x00000000 in ?? ()

Thread 1 (Thread 231132.0x382e8):
#0  Ffind_file_name_handler (filename=104868529, operation=21122626)
    at fileio.c:371
#1  0x010c316a in Fdirectory_file_name (directory=104868529) at fileio.c:675
#2  0x01100c16 in Ffuncall (nargs=2, args=0x82e918) at eval.c:2726
#3  0x01132691 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=36, 
    args_template=1028, nargs=21065338, args=0x2) at bytecode.c:920
#4  0x011007d9 in funcall_lambda (fun=75938813, nargs=1, arg_vector=0x82eaac)
    at eval.c:2894
#5  0x01100a2f in Ffuncall (nargs=2, args=0x82eaa8) at eval.c:2787
#6  0x01132691 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=84, 
    args_template=0, nargs=21065338, args=0x2) at bytecode.c:920
#7  0x011007d9 in funcall_lambda (fun=76245765, nargs=0, arg_vector=0x82ec44)
    at eval.c:2894
#8  0x01100a2f in Ffuncall (nargs=1, args=0x82ec40) at eval.c:2787
#9  0x01100346 in eval_sub (form=25559334) at eval.c:2153
#10 0x010ff326 in internal_catch (tag=22277098, func=0x10ffd5e <eval_sub>, 
    arg=25559334) at eval.c:1111
#11 0x01134016 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=52, 
    args_template=3076, nargs=8580368, args=0x8d) at bytecode.c:1101
#12 0x011007d9 in funcall_lambda (fun=75939429, nargs=1, arg_vector=0x82eea4)
    at eval.c:2894
#13 0x01100a2f in Ffuncall (nargs=2, args=0x82eea0) at eval.c:2787
#14 0x01132691 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=28, 
    args_template=3076, nargs=8580764, args=0x2) at bytecode.c:920
#15 0x011007d9 in funcall_lambda (fun=75939565, nargs=3, arg_vector=0x82f098)
    at eval.c:2894
#16 0x01100a2f in Ffuncall (nargs=4, args=0x82f094) at eval.c:2787
#17 0x010fcaa0 in Ffuncall_interactively (nargs=4, args=0x82f094)
    at callint.c:270
#18 0x01100afb in Ffuncall (nargs=5, args=0x82f090) at eval.c:2706
#19 0x01101a3f in Fapply (nargs=3, args=0x82f194) at eval.c:2346
#20 0x010fcde6 in Fcall_interactively (function=22713250, 
    record_flag=22541562, keys=21090829) at callint.c:416
#21 0x01100c89 in Ffuncall (nargs=4, args=0x82f25c) at eval.c:2733
#22 0x01132691 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=52, 
    args_template=4100, nargs=8581736, args=0x4) at bytecode.c:920
#23 0x011007d9 in funcall_lambda (fun=19024757, nargs=2, arg_vector=0x82f3e8)
    at eval.c:2894
#24 0x01100a2f in Ffuncall (nargs=3, args=0x82f3e4) at eval.c:2787
#25 0x01132691 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=60, 
    args_template=2052, nargs=8582112, args=0x3) at bytecode.c:920
#26 0x011007d9 in funcall_lambda (fun=19024429, nargs=2, arg_vector=0x82f5f8)
    at eval.c:2894
#27 0x01100a2f in Ffuncall (nargs=3, args=0x82f5f4) at eval.c:2787
#28 0x010fcaa0 in Ffuncall_interactively (nargs=3, args=0x82f5f4)
    at callint.c:270
#29 0x01100afb in Ffuncall (nargs=4, args=0x82f5f0) at eval.c:2706
#30 0x01101a3f in Fapply (nargs=3, args=0x82f6e4) at eval.c:2346
#31 0x010fcde6 in Fcall_interactively (function=21216914, 
    record_flag=21065338, keys=21090829) at callint.c:416
#32 0x01100c89 in Ffuncall (nargs=4, args=0x82f7ac) at eval.c:2733
#33 0x01132691 in exec_byte_code (bytestr=1, vector=22454806, maxdepth=52, 
    args_template=4100, nargs=8583096, args=0x4) at bytecode.c:920
#34 0x011007d9 in funcall_lambda (fun=19024757, nargs=1, arg_vector=0x82f92c)
    at eval.c:2894
#35 0x01100a2f in Ffuncall (nargs=2, args=0x82f928) at eval.c:2787
#36 0x01100eb3 in call1 (fn=21108970, arg1=21216914) at eval.c:2579
#37 0x010a3b49 in command_loop_1 () at keyboard.c:1572
#38 0x010ff3e2 in internal_condition_case (bfun=0x10a3836 <command_loop_1>, 
    handlers=21115634, hfun=0x109b122 <cmd_error>) at eval.c:1350
#39 0x0109a3b7 in command_loop_2 (ignore=21065338) at keyboard.c:1196
#40 0x010ff326 in internal_catch (tag=21109474, 
    func=0x109a397 <command_loop_2>, arg=21065338) at eval.c:1111
#41 0x0109adf5 in command_loop () at keyboard.c:1175
#42 recursive_edit_1 () at keyboard.c:785
#43 0x0109b06e in Frecursive_edit () at keyboard.c:856
#44 0x011aeb4e in main (argc=<optimized out>, argv=0xa42aa0) at emacs.c:1642
(gdb) quit
A debugging session is active.

	Inferior 1 [process 231132] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: c:\Programme\GNU\Emacs\bin\emacs.exe, Pid 231132

c:\Programme\GNU\Emacs\bin>

bug#18556: 24.4.50; update-file-autoloads never ends

[Vincent Belaïche]

Hello Paul,
BTW, I had not noticed this, even if you cannot reproduce getting hung, nevertheless there seems to be a problem in what you logged : the my_autoloads.el that you produced is basically empty. That should not be the case, there should be at least balance-mode function as auto-loadable.

Regards,   Vincent.
----------------------------------------
> Date: Fri, 26 Sep 2014 09:59:38 -0700
> From: eggert@cs.ucla.edu
> To: vincent.b.1@hotmail.fr
> CC: 18556@debbugs.gnu.org
> Subject: Re: 24.4.50; update-file-autoloads never ends
>
> I could not reproduce the problem with Emacs trunk bzr 117958 built on
> Fedora 20 with GCC 4.9.1, in either 32- or 64-bit builds, and in either
> en_US.UTF-8 or fr_FR.iso885915@euro locales. Here's the behavior I
> observed:
>
> $ ls -l /tmp/d/balance.el
> -rw-r--r--. 1 eggert eggert 110567 Sep 26 09:38 /tmp/d/balance.el
> $ time src/emacs -Q --batch '--eval=(update-file-autoloads
> "/tmp/d/balance.el" nil "/tmp/d/my_autoloads.el")'
> Generating autoloads for /tmp/d/balance.el...
> Wrote /tmp/d/my_autoloads.el
> Generating autoloads for /tmp/d/balance.el...done
>
> real 0m0.041s
> user 0m0.033s
> sys 0m0.007s
> $ ls -l /tmp/d/my_autoloads.el
> -rw-r--r--. 1 eggert eggert 260 Sep 26 09:56 /tmp/d/my_autoloads.el
> $ cat /tmp/d/my_autoloads.el
> ;;; my_autoloads.el --- automatically extracted autoloads
> ;;
> ;;; Code:
>
>
> (provide 'my_autoloads)
> ;; Local Variables:
> ;; version-control: never
> ;; no-byte-compile: t
> ;; no-update-autoloads: t
> ;; coding: utf-8
> ;; End:
> ;;; my_autoloads.el ends here
 		 	   		  

bug#18556: 24.4.50; update-file-autoloads never ends

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr> 
> Cc: Vincent Belaïche <vincent.b.1@hotmail.fr> ,
>     18556@debbugs.gnu.org
> Date: Sun, 28 Sep 2014 11:56:38 +0200
> 
> It is fully possible that balance.el requires some package not in the
> emacs trunk as I have this in my ~/.emacs.d/init.el
> 
> -----------------------------------------------------------------------
>   ;; remove CEDET/EIEIO/SPEEDBAR that are distributed with EMACS from the load
>   ;; path, and replace them with those of CEDET distribution
> (load "~/.emacs.d/etc/load-path-to-cedet-svn.el")
> -----------------------------------------------------------------------
> 
> This is because I develop jpicedt with jdee, and at some point of time
> the eieio of Emacs was too old compared to what jdee expected. Anyhow,
> In don't think that this is the problem because I can reproduce the
> hanging with -Q command line option.

How is -Q relevant to package shadowing?  If you have a different
eieio installed that shadows the stock one, Emacs will load it even
with -Q.

> Attached is the gdb session log that Paul desired.

Thanks.  Please use the procedure described in etc/DEBUG under "If the
symptom of the bug is that Emacs fails to respond" to find out whether
Emacs is inflooping, and if so, where.

bug#18556: 24.4.50; update-file-autoloads never ends

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> Date: Sun, 28 Sep 2014 12:36:04 +0200
> Cc: "18556@debbugs.gnu.org" <18556@debbugs.gnu.org>
> 
> Hello Paul,
> BTW, I had not noticed this, even if you cannot reproduce getting hung, nevertheless there seems to be a problem in what you logged : the my_autoloads.el that you produced is basically empty. That should not be the case, there should be at least balance-mode function as auto-loadable.

FWIW, I get the same results as Paul in that file.

bug#18556: 24.4.50; update-file-autoloads never ends

[Vincent Belaïche]

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

Hello Eli,

Just to clarify the point that -Q should or not prevent the shadowing:
it *should* prevent shadowing.

What I do in the init.el is that I remove from load-path the path to the
eieio bundled with Emacs, and I replace it with another one on some
cedet anonymous checkout.

So, if I have -Q this hacking of load-path does not occur, and shadowing
bundled module won't occur.

FYI, attached is load-path-to-cedet-svn.el which is loaded from my init file
to do the shadowing.

  Vincent.


[-- Attachment #2: load-path-to-cedet-svn.el --]
[-- Type: application/emacs-lisp, Size: 596 bytes --]

[-- Attachment #3: Type: text/plain, Size: 946 bytes --]


----------------------------------------
> Date: Sun, 28 Sep 2014 19:24:42 +0300
> From: eliz@gnu.org
> Subject: Re: bug#18556: 24.4.50; update-file-autoloads never ends
> To: vincent.b.1@hotmail.fr
> CC: eggert@cs.ucla.edu; vincent.b.1@hotmail.fr; 18556@debbugs.gnu.org
>
>> From: Vincent Belaïche <vincent.b.1@hotmail.fr>
>> Cc: Vincent Belaïche <vincent.b.1@hotmail.fr> ,
>> 18556@debbugs.gnu.org
>> Date: Sun, 28 Sep 2014 11:56:38 +0200
>>
>> It is fully possible that balance.el requires some package not in the
>> emacs trunk as I have this in my ~/.emacs.d/init.el
>>
>> -----------------------------------------------------------------------
>> ;; remove CEDET/EIEIO/SPEEDBAR that are distributed with EMACS from the load
>> ;; path, and replace them with those of CEDET distribution
>> (load "~/.emacs.d/etc/load-path-to-cedet-svn.el")
>> -----------------------------------------------------------------------
>>

bug#18556: 24.4.50; update-file-autoloads never ends

[Eli Zaretskii]

> From: Vincent Belaïche <vincent.b.1@hotmail.fr> 
> Cc: Vincent Belaïche <vincent.b.1@hotmail.fr> ,
>     18556@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 29 Sep 2014 08:38:15 +0200
> 
> Just to clarify the point that -Q should or not prevent the shadowing:
> it *should* prevent shadowing.
> 
> What I do in the init.el is that I remove from load-path the path to the
> eieio bundled with Emacs, and I replace it with another one on some
> cedet anonymous checkout.
> 
> So, if I have -Q this hacking of load-path does not occur, and shadowing
> bundled module won't occur.

This is a misunderstanding.  I didn't mean what you do in init.el, I
meant these lines in balance.el:

  (require 'eieio)
  (require 'calc-ext)
  (require 'calc-forms)

If you have another version of eieio and/or calc somewhere along your
default load-path, then these 'require' directives will load those
other versions.

bug#18556: 24.4.50; update-file-autoloads never ends

[Vincent Belaïche]

----------------------------------------
> Date: Mon, 29 Sep 2014 09:53:15 +0300
> From: eliz@gnu.org
> Subject: Re: bug#18556: 24.4.50; update-file-autoloads never ends
> To: vincent.b.1@hotmail.fr
> CC: 18556@debbugs.gnu.org; eggert@cs.ucla.edu
>
> > From: Vincent Belaïche <vincent.b.1@hotmail.fr>
> > Cc: Vincent Belaïche <vincent.b.1@hotmail.fr> ,
> > 18556@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> > Date: Mon, 29 Sep 2014 08:38:15 +0200
> >
> > Just to clarify the point that -Q should or not prevent the shadowing:
> > it *should* prevent shadowing.
> >
> > What I do in the init.el is that I remove from load-path the path to the
> > eieio bundled with Emacs, and I replace it with another one on some
> > cedet anonymous checkout.
> >
> > So, if I have -Q this hacking of load-path does not occur, and shadowing
> > bundled module won't occur.
>
> This is a misunderstanding. I didn't mean what you do in init.el, I
> meant these lines in balance.el:
>
> (require 'eieio)
> (require 'calc-ext)
> (require 'calc-forms)
>
> If you have another version of eieio and/or calc somewhere along your
> default load-path, then these 'require' directives will load those
> other versions.

Well,

Loading the other versions was what was "intended" for eieio. Indeed
that could be changed now because I presume that current Emacs has a
recent enough eieio, and anyway balance did not really needed that
recent one, I just did that in my init.el because of jdee.

Anyway, I don't think that this is the problem, with the -Q option I do
not tamper with the default load-path, so those lines in balance.el will
load the package that are bundled with Emacs, not any other ones. Won't
they? But still I have the hanging with -Q.

  Vincent.

bug#18556: 24.4.50; update-file-autoloads never ends

[Vincent Belaïche]

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

Hello Paul & Eli,

I have tried again the same thing with a fairly recent Emacs --- built
from a bzr update done yesterday, and it is still the same hanging. 

I need to C-g to exit the hanging up, and I get this in the *Message*
buffer:

-----------------------------------------------------------------------
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Generating autoloads for c:/msys/1.0/local/projects/balance/lisp/balance.el...
Quit
-----------------------------------------------------------------------

The load-path variable is the following (for this Emacs started with -Q
so that I get the standard value of load-path):

("c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/vc"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/url"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/textmodes"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/progmodes"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/play"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/org"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/nxml"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/net"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/mh-e"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/mail"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/leim"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/language"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/international"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/gnus"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/eshell"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/erc"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/emulation"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/emacs-lisp"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/cedet"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/calendar"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/calc"
"c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/obsolete")

Here is the output of 'M-x version':

GNU Emacs 25.0.50.3 (i686-pc-mingw32) of 2014-10-25 on CHOUNEK

Also I did again the gbd/attach that Paul had asked for, and it is
attached to this email.

FYI, after trimming balance.el more and more, and checking whether it
hangs up or not, it came out that if balance.el contains a single line
as follows, that is sufficient to cause the hanging forever to happen.

-----------------------------------------------------------------------
(require 'eieio)
-----------------------------------------------------------------------

If under that Emacs I do `C-h f eieio-defclass-autoload', and then from
the *Help* window I follow the eieio-core.el link, I get into the
eieio-core.el bundled with Emacs, aka that in

   c:/Programme/GNU/Emacs/share/emacs/25.0.50/lisp/emacs-lisp/


where my Emacs is installed in:

   c:/Programme/GNU/Emacs


VBR,

  Vincent.


[-- Attachment #2: bug18556.log --]
[-- Type: text/plain, Size: 5870 bytes --]


/c>cd Programme/GNU/installation/emacs-install/emacs/trunk/src/
/c/Programme/GNU/installation/emacs-install/emacs/trunk/src>gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) .gdbinit:19: Error in sourced command file:
No symbol table is loaded.  Use the "file" command.
No symbol table is loaded.  Use the "file" command.
(gdb) attach 127520
Attaching to process 127520
[New Thread 127520.0x1ec88]
[New Thread 127520.0x1f1d0]
[New Thread 127520.0x1f25c]
[New Thread 127520.0x1f6e8]
Reading symbols from c:\Programme\GNU\Emacs\bin\emacs.exe...done.
(gdb) thread apply all bt

Thread 4 (Thread 127520.0x1f6e8):
#0  0x7c91120f in ntdll!DbgUiConnectToDbg ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c962119 in ntdll!KiIntSystemCall () from C:\WINDOWS\system32\ntdll.dll
#2  0x00000005 in ?? ()
#3  0x00000004 in ?? ()
#4  0x00000001 in ?? ()
#5  0x1d48ffd0 in ?? ()
#6  0x00000000 in ?? ()

Thread 3 (Thread 127520.0x1f25c):
#0  0x7c91e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7e3991be in USER32!GetProcessWindowStation ()
   from C:\WINDOWS\system32\user32.dll
#2  0x7e3991f1 in USER32!GetMessageW () from C:\WINDOWS\system32\user32.dll
#3  0x0115a184 in w32_msg_pump (msg_buf=<optimized out>) at w32fns.c:2502
#4  0x0115a7a7 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2729
#5  0x7c80b729 in KERNEL32!GetModuleFileNameA ()
   from C:\WINDOWS\system32\kernel32.dll
#6  0x00000000 in ?? ()

Thread 2 (Thread 127520.0x1f1d0):
#0  0x7c91e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c91d21a in ntdll!ZwDelayExecution () from C:\WINDOWS\system32\ntdll.dll
#2  0x7c8023f1 in SleepEx () from C:\WINDOWS\system32\kernel32.dll
#3  0x00000000 in ?? ()

Thread 1 (Thread 127520.0x1ec88):
#0  0x011343bf in exec_byte_code (bytestr=18041728, vector=75323703, 
    maxdepth=36, args_template=1028, nargs=21057146, args=0x21)
    at bytecode.c:1963
#1  0x0110237f in funcall_lambda (fun=75560181, nargs=1, arg_vector=0x82ecd8)
    at eval.c:2890
#2  0x011025d9 in Ffuncall (nargs=2, args=0x82ecd4) at eval.c:2784
#3  0x011344d1 in exec_byte_code (bytestr=18041728, vector=75323703, 
    maxdepth=96, args_template=3076, nargs=21057146, args=0x2)
    at bytecode.c:920
#4  0x0110237f in funcall_lambda (fun=75560389, nargs=1, arg_vector=0x82ee74)
    at eval.c:2890
#5  0x011025d9 in Ffuncall (nargs=2, args=0x82ee70) at eval.c:2784
#6  0x011344d1 in exec_byte_code (bytestr=18041728, vector=75323703, 
    maxdepth=28, args_template=3076, nargs=8580716, args=0x2)
    at bytecode.c:920
#7  0x0110237f in funcall_lambda (fun=75705725, nargs=3, arg_vector=0x82f068)
    at eval.c:2890
#8  0x011025d9 in Ffuncall (nargs=4, args=0x82f064) at eval.c:2784
#9  0x010fe610 in Ffuncall_interactively (nargs=4, args=0x82f064)
    at callint.c:270
#10 0x011026a0 in Ffuncall (nargs=5, args=0x82f060) at eval.c:2703
#11 0x011035e0 in Fapply (nargs=3, args=0x82f174) at eval.c:2343
#12 0x010fe956 in Fcall_interactively (function=22603178, 
    record_flag=22873594, keys=21082637) at callint.c:416
#13 0x01102826 in Ffuncall (nargs=4, args=0x82f23c) at eval.c:2730
#14 0x011344d1 in exec_byte_code (bytestr=18041728, vector=75323703, 
    maxdepth=52, args_template=4100, nargs=8581704, args=0x4)
    at bytecode.c:920
#15 0x0110237f in funcall_lambda (fun=19000917, nargs=2, arg_vector=0x82f3c8)
    at eval.c:2890
#16 0x011025d9 in Ffuncall (nargs=3, args=0x82f3c4) at eval.c:2784
#17 0x011344d1 in exec_byte_code (bytestr=18041728, vector=75323703, 
    maxdepth=56, args_template=2052, nargs=8582080, args=0x3)
    at bytecode.c:920
#18 0x0110237f in funcall_lambda (fun=19000597, nargs=2, arg_vector=0x82f5d8)
    at eval.c:2890
#19 0x011025d9 in Ffuncall (nargs=3, args=0x82f5d4) at eval.c:2784
#20 0x010fe610 in Ffuncall_interactively (nargs=3, args=0x82f5d4)
    at callint.c:270
#21 0x011026a0 in Ffuncall (nargs=4, args=0x82f5d0) at eval.c:2703
#22 0x011035e0 in Fapply (nargs=3, args=0x82f6d4) at eval.c:2343
#23 0x010fe956 in Fcall_interactively (function=21208842, 
    record_flag=21057146, keys=21082637) at callint.c:416
#24 0x01102826 in Ffuncall (nargs=4, args=0x82f79c) at eval.c:2730
#25 0x011344d1 in exec_byte_code (bytestr=18041728, vector=75323703, 
    maxdepth=52, args_template=4100, nargs=8583080, args=0x4)
    at bytecode.c:920
#26 0x0110237f in funcall_lambda (fun=19000917, nargs=1, arg_vector=0x82f91c)
    at eval.c:2890
#27 0x011025d9 in Ffuncall (nargs=2, args=0x82f918) at eval.c:2784
#28 0x01102a4f in call1 (fn=21100778, arg1=21208842) at eval.c:2576
#29 0x010a5409 in command_loop_1 () at keyboard.c:1569
#30 0x01100f62 in internal_condition_case (bfun=0x10a50f5 <command_loop_1>, 
    handlers=21107466, hfun=0x109c80d <cmd_error>) at eval.c:1344
#31 0x0109bae7 in command_loop_2 (ignore=21057146) at keyboard.c:1197
#32 0x01100ea6 in internal_catch (tag=21101282, 
    func=0x109bac7 <command_loop_2>, arg=21057146) at eval.c:1105
#33 0x0109c4de in command_loop () at keyboard.c:1176
#34 recursive_edit_1 () at keyboard.c:786
#35 0x0109c759 in Frecursive_edit () at keyboard.c:857
#36 0x011b10e3 in main (argc=<optimized out>, argv=0xa42aa0) at emacs.c:1623
(gdb) quit
A debugging session is active.

	Inferior 1 [process 127520] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: c:\Programme\GNU\Emacs\bin\emacs.exe, Pid 127520
/c/Programme/GNU/installation/emacs-install/emacs/trunk/src>exit

Process shell finished

bug#18556: 24.4.50; update-file-autoloads never ends

[Glenn Morris]

Vincent Belaïche wrote:

> BTW, I had not noticed this, even if you cannot reproduce getting
> hung, nevertheless there seems to be a problem in what you logged :
> the my_autoloads.el that you produced is basically empty. That should
> not be the case, there should be at least balance-mode function as
> auto-loadable.

That's because you passed nil for the SAVE-AFTER argument of
update-file-autoloads.

bug#18556: 24.4.50; update-file-autoloads never ends

[Glenn Morris]

I'm a third person who can't reproduce this, so I think it's best to
close it, since it's been years, and I can't see it ever going anywhere.
The backtrace is uninformative. Sorry.

BTW, generating autoloads for foo.el does not evaluate foo.el, so
AFAICS all the comments about what libraries balance.el might require
are irrelevant. I have no idea how requires in balance.el could affect
this issue. The whole thing makes no sense to me.