* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-25 4:07 bug#18556: 24.4.50; update-file-autoloads never ends Vincent Belaïche
@ 2014-09-26 16:59 ` Paul Eggert
2014-09-26 17:21 ` Eli Zaretskii
2014-09-28 10:36 ` Vincent Belaïche
2014-09-28 9:56 ` Vincent Belaïche
` (3 subsequent siblings)
4 siblings, 2 replies; 14+ messages in thread
From: Paul Eggert @ 2014-09-26 16:59 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: 18556
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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-26 16:59 ` Paul Eggert
@ 2014-09-26 17:21 ` Eli Zaretskii
2014-09-26 17:24 ` Eli Zaretskii
2014-09-28 10:36 ` Vincent Belaïche
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2014-09-26 17:21 UTC (permalink / raw)
To: Paul Eggert; +Cc: vincent.b.1, 18556
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-26 17:21 ` Eli Zaretskii
@ 2014-09-26 17:24 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2014-09-26 17:24 UTC (permalink / raw)
To: eggert, vincent.b.1; +Cc: 18556
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-26 16:59 ` Paul Eggert
2014-09-26 17:21 ` Eli Zaretskii
@ 2014-09-28 10:36 ` Vincent Belaïche
2014-09-28 16:27 ` Eli Zaretskii
2017-05-05 5:37 ` Glenn Morris
1 sibling, 2 replies; 14+ messages in thread
From: Vincent Belaïche @ 2014-09-28 10:36 UTC (permalink / raw)
To: Paul Eggert; +Cc: 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.
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-28 10:36 ` Vincent Belaïche
@ 2014-09-28 16:27 ` Eli Zaretskii
2017-05-05 5:37 ` Glenn Morris
1 sibling, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2014-09-28 16:27 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: 18556, eggert
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-28 10:36 ` Vincent Belaïche
2014-09-28 16:27 ` Eli Zaretskii
@ 2017-05-05 5:37 ` Glenn Morris
1 sibling, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2017-05-05 5:37 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: 18556, Paul Eggert
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-25 4:07 bug#18556: 24.4.50; update-file-autoloads never ends Vincent Belaïche
2014-09-26 16:59 ` Paul Eggert
@ 2014-09-28 9:56 ` Vincent Belaïche
2014-09-28 16:24 ` Eli Zaretskii
2014-09-29 6:38 ` Vincent Belaïche
` (2 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Vincent Belaïche @ 2014-09-28 9:56 UTC (permalink / raw)
To: Eli Zaretskii, Paul Eggert; +Cc: Vincent Belaïche, 18556
[-- 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>
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-28 9:56 ` Vincent Belaïche
@ 2014-09-28 16:24 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2014-09-28 16:24 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: vincent.b.1, eggert, 18556
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-25 4:07 bug#18556: 24.4.50; update-file-autoloads never ends Vincent Belaïche
2014-09-26 16:59 ` Paul Eggert
2014-09-28 9:56 ` Vincent Belaïche
@ 2014-09-29 6:38 ` Vincent Belaïche
2014-09-29 6:53 ` Eli Zaretskii
2014-09-29 7:06 ` Vincent Belaïche
2014-10-25 22:03 ` Vincent Belaïche
4 siblings, 1 reply; 14+ messages in thread
From: Vincent Belaïche @ 2014-09-29 6:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Vincent Belaïche, Paul Eggert, 18556
[-- 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")
>> -----------------------------------------------------------------------
>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-29 6:38 ` Vincent Belaïche
@ 2014-09-29 6:53 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2014-09-29 6:53 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: 18556, eggert
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-25 4:07 bug#18556: 24.4.50; update-file-autoloads never ends Vincent Belaïche
` (2 preceding siblings ...)
2014-09-29 6:38 ` Vincent Belaïche
@ 2014-09-29 7:06 ` Vincent Belaïche
2014-10-25 22:03 ` Vincent Belaïche
4 siblings, 0 replies; 14+ messages in thread
From: Vincent Belaïche @ 2014-09-29 7:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Vincent Belaïche, Paul Eggert, 18556
----------------------------------------
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#18556: 24.4.50; update-file-autoloads never ends
2014-09-25 4:07 bug#18556: 24.4.50; update-file-autoloads never ends Vincent Belaïche
` (3 preceding siblings ...)
2014-09-29 7:06 ` Vincent Belaïche
@ 2014-10-25 22:03 ` Vincent Belaïche
2017-05-05 5:39 ` Glenn Morris
4 siblings, 1 reply; 14+ messages in thread
From: Vincent Belaïche @ 2014-10-25 22:03 UTC (permalink / raw)
To: Eli Zaretskii, Paul Eggert; +Cc: Vincent Belaïche, 18556
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#18556: 24.4.50; update-file-autoloads never ends
2014-10-25 22:03 ` Vincent Belaïche
@ 2017-05-05 5:39 ` Glenn Morris
0 siblings, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2017-05-05 5:39 UTC (permalink / raw)
To: Vincent Belaïche; +Cc: Paul Eggert, 18556
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.
^ permalink raw reply [flat|nested] 14+ messages in thread