bug#14569: 24.3.50; bootstrap fails on Cygwin

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Katsumi Yamaoka]

Hi,

Bootstrap got to fail on Cygwin since yesterday.  An error occurs
at least when performing batch-update-autoloads as follows:

[...]
Wrote /Work/emacs/lisp/mh-e/mh-loaddefs.el
(No changes need to be saved)
EMACSLOADPATH=/Work/emacs/lisp LC_ALL=C /Work/emacs/src/bootstrap-emacs.exe \
 -batch --no-site-file --no-site-lisp -l autoload \
 --eval "(setq generate-autoload-cookie \";;;###tramp-autoload\")" \
 --eval "(setq generated-autoload-file (unmsys--file-name \"/Work/emacs/lisp/net/tramp-loaddefs.el\"))" \
 --eval "(setq make-backup-files nil)" \
 -f batch-update-autoloads /Work/emacs/lisp/net
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.
Makefile:392: recipe for target `/Work/emacs/lisp/net/tramp-loaddefs.el' failed
make[3]: *** [/Work/emacs/lisp/net/tramp-loaddefs.el] Aborted
[...]
make: *** [bootstrap] Error 2

I can run bootstrap-emacs.exe with the -Q option but I have no
clue to examine it.  Please help.

(This is of what I built last.)
In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
 of 2013-06-05 on localhost
Bzr revision: 112848 eliz@gnu.org-20130604163346-bxz8tbdsd4zt5zm2
Windowing system distributor `The Cygwin/X Project', version 11.0.11401000
Configured using:
 `configure --verbose --with-x-toolkit=lucid --without-imagemagick
 --without-dbus --without-gconf --without-gsettings'

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Katsumi Yamaoka wrote:

> Bootstrap got to fail on Cygwin since yesterday.  An error occurs
> at least when performing batch-update-autoloads as follows:

I did a similar report on emacs-devel:

http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg00333.html

Now I have discovered that trunk rev. 112858 build fine while rev. 
112859 fails as described. These are the changes that have broken the 
bootstrap on Cygwin:

=================================
2013-06-05  Paul Eggert  <eggert@cs.ucla.edu>
  2
  3        Chain glib's SIGCHLD handler from Emacs's (Bug#14474).
  4        * process.c (dummy_handler): New function.
  5        (lib_child_handler): New static var.
  6        (handle_child_signal): Invoke it.
  7        (catch_child_signal): If a library has set up a signal handler,
  8        save it into lib_child_handler.
  9        (init_process_emacs): If using glib and not on Windows, 
tickle glib's
  10        child-handling code so that it initializes its private 
SIGCHLD handler.
  11        * syssignal.h (SA_SIGINFO): Default to 0.
  12        * xterm.c (x_term_init): Remove D-bus hack that I installed 
on May
  13        31; it should no longer be needed now.
=================================


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello.

This sounds like a bug in GLib.  Put a breakpoint at g_thread_abort to get a useful backtrace.

	Jan D.

10 jun 2013 kl. 15:54 skrev Angelo Graziosi <angelo.graziosi@alice.it>:

> Katsumi Yamaoka wrote:
> 
>> Bootstrap got to fail on Cygwin since yesterday.  An error occurs
>> at least when performing batch-update-autoloads as follows:
> 
> I did a similar report on emacs-devel:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg00333.html
> 
> Now I have discovered that trunk rev. 112858 build fine while rev. 112859 fails as described. These are the changes that have broken the bootstrap on Cygwin:
> 
> =================================
> 2013-06-05  Paul Eggert  <eggert@cs.ucla.edu>
> 2
> 3        Chain glib's SIGCHLD handler from Emacs's (Bug#14474).
> 4        * process.c (dummy_handler): New function.
> 5        (lib_child_handler): New static var.
> 6        (handle_child_signal): Invoke it.
> 7        (catch_child_signal): If a library has set up a signal handler,
> 8        save it into lib_child_handler.
> 9        (init_process_emacs): If using glib and not on Windows, tickle glib's
> 10        child-handling code so that it initializes its private SIGCHLD handler.
> 11        * syssignal.h (SA_SIGINFO): Default to 0.
> 12        * xterm.c (x_term_init): Remove D-bus hack that I installed on May
> 13        31; it should no longer be needed now.
> =================================
> 
> 
> Ciao,
> Angelo.
> 
> 

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 10/06/2013 18.27, Jan Djärv ha scritto:
> Hello.
>
> This sounds like a bug in GLib.  Put a breakpoint at g_thread_abort to get a useful backtrace.

I am afraid but GDB is not for me... :(


Ciao,
  Angelo.

>
> 	Jan D.
>
> 10 jun 2013 kl. 15:54 skrev Angelo Graziosi <angelo.graziosi@alice.it>:
>
>> Katsumi Yamaoka wrote:
>>
>>> Bootstrap got to fail on Cygwin since yesterday.  An error occurs
>>> at least when performing batch-update-autoloads as follows:
>>
>> I did a similar report on emacs-devel:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg00333.html
>>
>> Now I have discovered that trunk rev. 112858 build fine while rev. 112859 fails as described. These are the changes that have broken the bootstrap on Cygwin:
>>
>> =================================
>> 2013-06-05  Paul Eggert  <eggert@cs.ucla.edu>
>> 2
>> 3        Chain glib's SIGCHLD handler from Emacs's (Bug#14474).
>> 4        * process.c (dummy_handler): New function.
>> 5        (lib_child_handler): New static var.
>> 6        (handle_child_signal): Invoke it.
>> 7        (catch_child_signal): If a library has set up a signal handler,
>> 8        save it into lib_child_handler.
>> 9        (init_process_emacs): If using glib and not on Windows, tickle glib's
>> 10        child-handling code so that it initializes its private SIGCHLD handler.
>> 11        * syssignal.h (SA_SIGINFO): Default to 0.
>> 12        * xterm.c (x_term_init): Remove D-bus hack that I installed on May
>> 13        31; it should no longer be needed now.
>> =================================
>>
>>
>> Ciao,
>> Angelo.
>>
>>
>

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

Are you linking with libxml2?  These URLs:

http://91r.net/ask/15791784.html

http://xmlsoft.org/threads.html

suggests that Emacs may not be initializing
libxml2 properly.

You should be able to tell whether you're linking
with libxml2 by looking at the 'make' output,
or by running 'ldd src/temacs'.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 10/06/2013 22.10, Paul Eggert ha scritto:
> Are you linking with libxml2?  These URLs:
>
> http://91r.net/ask/15791784.html
>
> http://xmlsoft.org/threads.html
>
> suggests that Emacs may not be initializing
> libxml2 properly.
>
> You should be able to tell whether you're linking
> with libxml2 by looking at the 'make' output,
> or by running 'ldd src/temacs'.
>

Hmm... I configure with:

$ "${source_dir}"/configure --prefix="${prefix_dir}"

and "configure" adds all it finds,

...
Configured for `i686-pc-cygwin'.

   Where should the build process find the source code?    /work/emacs
   What compiler should emacs be built with?               gcc 
-std=gnu99 -g3 -O2
   Should Emacs use the GNU version of malloc?             yes
   Should Emacs use a relocating allocator for buffers?    no
   Should Emacs use mmap(2) for buffer allocation?         yes
   What window system should Emacs use?                    x11
   What toolkit should Emacs use?                          GTK3
   Where do we find X Windows header files?                Standard dirs
   Where do we find X Windows libraries?                   Standard dirs
   Does Emacs use -lXaw3d?                                 no
   Does Emacs use -lXpm?                                   yes
   Does Emacs use -ljpeg?                                  yes
   Does Emacs use -ltiff?                                  yes
   Does Emacs use a gif library?                           yes -lgif
   Does Emacs use -lpng?                                   yes
   Does Emacs use -lrsvg-2?                                yes
   Does Emacs use imagemagick?                             yes
   Does Emacs use -lgpm?                                   no
   Does Emacs use -ldbus?                                  yes
   Does Emacs use -lgconf?                                 yes
   Does Emacs use GSettings?                               yes
   Does Emacs use a file notification library?             yes -lgio (gfile)
   Does Emacs use -lselinux?                               no
   Does Emacs use -lgnutls?                                yes
   Does Emacs use -lxml2?                                  yes
   Does Emacs use -lfreetype?                              yes
   Does Emacs use -lm17n-flt?                              yes
   Does Emacs use -lotf?                                   yes
   Does Emacs use -lxft?                                   yes
   Does Emacs use toolkit scroll bars?                     yes
...


It is certainly not my will that wants to link with xml2,

$ ldd emacs/Work/src/temacs.exe | grep xml
	cygxml2-2.dll => /usr/bin/cygxml2-2.dll (0x45990000)


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/10/13 14:15, Angelo Graziosi wrote:
> I configure with:
> 
> $ "${source_dir}"/configure --prefix="${prefix_dir}"

What happens if you configure --without-xml2?
Something like this, say:

"${source_dir}"/configure --prefix="${prefix_dir}" --without-xml2
make clean
make

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 10/06/2013 23.52, Paul Eggert ha scritto:
> On 06/10/13 14:15, Angelo Graziosi wrote:
>> I configure with:
>>
>> $ "${source_dir}"/configure --prefix="${prefix_dir}"
>
> What happens if you configure --without-xml2?
> Something like this, say:


Hmm... I have just verified that my builds on Kubuntu uses xm2 too, and 
the same rev. that fails to bootstrap on Cygwin, there builds fine..

For example, rev. 112902 gives

...
Configured for `x86_64-unknown-linux-gnu'.

   Where should the build process find the source code?    /work/emacs 
What compiler should emacs be built with?               clang -O3
   Should Emacs use the GNU version of malloc?             yes
       (Using Doug Lea's new malloc from the GNU C Library.)
   Should Emacs use a relocating allocator for buffers?    no
   Should Emacs use mmap(2) for buffer allocation?         no
   What window system should Emacs use?                    x11
   What toolkit should Emacs use?                          GTK3
   Where do we find X Windows header files?                Standard dirs
   Where do we find X Windows libraries?                   Standard dirs
   Does Emacs use -lXaw3d?                                 no
   Does Emacs use -lXpm?                                   yes
   Does Emacs use -ljpeg?                                  yes
   Does Emacs use -ltiff?                                  yes
   Does Emacs use a gif library?                           yes -lgif
   Does Emacs use -lpng?                                   yes
   Does Emacs use -lrsvg-2?                                yes
   Does Emacs use imagemagick?                             yes
   Does Emacs use -lgpm?                                   yes
   Does Emacs use -ldbus?                                  yes
   Does Emacs use -lgconf?                                 yes
   Does Emacs use GSettings?                               yes
   Does Emacs use a file notification library?             yes -lgio (gfile)
   Does Emacs use -lselinux?                               no
   Does Emacs use -lgnutls?                                yes
   Does Emacs use -lxml2?                                  yes
   Does Emacs use -lfreetype?                              yes
   Does Emacs use -lm17n-flt?                              yes
   Does Emacs use -lotf?                                   yes
   Does Emacs use -lxft?                                   yes
   Does Emacs use toolkit scroll bars?                     yes
...

and

$ ldd /usr/local/emacs/bin/emacs | grep xml
         libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 
(0x00007f4858e01000)


> "${source_dir}"/configure --prefix="${prefix_dir}" --without-xml2
> make clean
> make
>

tomorrow...

Good Night,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 10/06/2013 23.52, Paul Eggert ha scritto:
> On 06/10/13 14:15, Angelo Graziosi wrote:
>> I configure with:
>>
>> $ "${source_dir}"/configure --prefix="${prefix_dir}"
>
> What happens if you configure --without-xml2?
> Something like this, say:
>
> "${source_dir}"/configure --prefix="${prefix_dir}" --without-xml2
> make clean
> make
>

I am afraid for you, but what you suggest fails in the same manner:

$ cd emacs
$ mkdir Work
$ ./autogen.sh
$ cd Work/
$ ../configure --prefix=/usr/local/emacs --without-xml2
...
Configured for `i686-pc-cygwin'.

   Where should the build process find the source code?    /work/emacs
   What compiler should emacs be built with?               gcc 
-std=gnu99 -g3 -O2
   Should Emacs use the GNU version of malloc?             yes
   Should Emacs use a relocating allocator for buffers?    no
   Should Emacs use mmap(2) for buffer allocation?         yes
   What window system should Emacs use?                    x11
   What toolkit should Emacs use?                          GTK3
   Where do we find X Windows header files?                Standard dirs
   Where do we find X Windows libraries?                   Standard dirs
   Does Emacs use -lXaw3d?                                 no
   Does Emacs use -lXpm?                                   yes
   Does Emacs use -ljpeg?                                  yes
   Does Emacs use -ltiff?                                  yes
   Does Emacs use a gif library?                           yes -lgif
   Does Emacs use -lpng?                                   yes
   Does Emacs use -lrsvg-2?                                yes
   Does Emacs use imagemagick?                             yes
   Does Emacs use -lgpm?                                   no
   Does Emacs use -ldbus?                                  yes
   Does Emacs use -lgconf?                                 yes
   Does Emacs use GSettings?                               yes
   Does Emacs use a file notification library?             yes -lgio (gfile)
   Does Emacs use -lselinux?                               no
   Does Emacs use -lgnutls?                                yes
   Does Emacs use -lxml2?                                  no
   Does Emacs use -lfreetype?                              yes
   Does Emacs use -lm17n-flt?                              yes
   Does Emacs use -lotf?                                   yes
   Does Emacs use -lxft?                                   yes
   Does Emacs use toolkit scroll bars?                     yes
...

(notice that now it says: "Does Emacs use -lxml2? no")

$ make
...
Compiling /work/emacs/src/../lisp/language/cham.el
GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Makefile:229: recipe for target `compile-onefile' failed
make[2]: *** [compile-onefile] Aborted
make[2]: uscita dalla directory "/work/emacs/Work/lisp"
Makefile:809: recipe for target 
`/work/emacs/src/../lisp/language/cham.elc' failed
make[1]: *** [/work/emacs/src/../lisp/language/cham.elc] Error 2
make[1]: uscita dalla directory "/work/emacs/Work/src"
Makefile:381: recipe for target `src' failed
make: *** [src] Error 2


I would have been surprised if it had worked.. As I explained, on 
GNU/Linux Kubuntu 12.04 Emacs Trunk bootstrap fine with the XML2 support..


and now, really, Good Night!!!


Ciao,
  Angelo.

(PS. When I replay, TB refuses to send the replay to the address 
14569@debbugs.gnu.org, I need to change it manually into 
bug-gnu-emacs@gnu.org, IS there some tricks I can do to avoid this? TIA, A.)

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 10/06/2013 23.52, Paul Eggert ha scritto:
> On 06/10/13 14:15, Angelo Graziosi wrote:
>> I configure with:
>>
>> $ "${source_dir}"/configure --prefix="${prefix_dir}"
>
> What happens if you configure --without-xml2?
> Something like this, say:
>
> "${source_dir}"/configure --prefix="${prefix_dir}" --without-xml2
> make clean
> make
>

As you have seen, what you propose fails... but also this fails:

$ cd emacs
$ ./autogen.sh
$ mkdir Work
$ cd Work
$ ../configure --without-all
...
Configured for `i686-pc-cygwin'.

   Where should the build process find the source code?    /work/emacs
   What compiler should emacs be built with?               gcc 
-std=gnu99 -g3 -O2
   Should Emacs use the GNU version of malloc?             yes
   Should Emacs use a relocating allocator for buffers?    no
   Should Emacs use mmap(2) for buffer allocation?         yes
   What window system should Emacs use?                    x11
   What toolkit should Emacs use?                          GTK3
   Where do we find X Windows header files?                Standard dirs
   Where do we find X Windows libraries?                   Standard dirs
   Does Emacs use -lXaw3d?                                 no
   Does Emacs use -lXpm?                                   no
   Does Emacs use -ljpeg?                                  no
   Does Emacs use -ltiff?                                  no
   Does Emacs use a gif library?                           no
   Does Emacs use -lpng?                                   no
   Does Emacs use -lrsvg-2?                                no
   Does Emacs use imagemagick?                             no
   Does Emacs use -lgpm?                                   no
   Does Emacs use -ldbus?                                  no
   Does Emacs use -lgconf?                                 no
   Does Emacs use GSettings?                               no
   Does Emacs use a file notification library?             yes -lgio (gfile)
   Does Emacs use -lselinux?                               no
   Does Emacs use -lgnutls?                                no
   Does Emacs use -lxml2?                                  no
   Does Emacs use -lfreetype?                              no
   Does Emacs use -lm17n-flt?                              no
   Does Emacs use -lotf?                                   no
   Does Emacs use -lxft?                                   no
   Does Emacs use toolkit scroll bars?                     no

$ make
...
make[2]: uscita dalla directory "/work/emacs/Work/lisp"
make[2]: ingresso nella directory "/work/emacs/Work/lisp"
Compiling /work/emacs/src/../lisp/international/characters.el
Wrote /work/emacs/lisp/international/characters.elc
make[2]: uscita dalla directory "/work/emacs/Work/lisp"
make[2]: ingresso nella directory "/work/emacs/Work/lisp"
Compiling /work/emacs/src/../lisp/composite.el
Wrote /work/emacs/lisp/composite.elc
make[2]: uscita dalla directory "/work/emacs/Work/lisp"
make[2]: ingresso nella directory "/work/emacs/Work/lisp"
Compiling /work/emacs/src/../lisp/language/chinese.el
GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Makefile:229: recipe for target `compile-onefile' failed
make[2]: *** [compile-onefile] Aborted
make[2]: uscita dalla directory "/work/emacs/Work/lisp"
Makefile:809: recipe for target 
`/work/emacs/src/../lisp/language/chinese.elc' failed
make[1]: *** [/work/emacs/src/../lisp/language/chinese.elc] Error 2
make[1]: uscita dalla directory "/work/emacs/Work/src"
Makefile:381: recipe for target `src' failed
make: *** [src] Error 2


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello.

10 jun 2013 kl. 20:56 skrev Angelo Graziosi <angelo.graziosi@alice.it>:

> Il 10/06/2013 18.27, Jan Djärv ha scritto:
>> Hello.
>> 
>> This sounds like a bug in GLib.  Put a breakpoint at g_thread_abort to get a useful backtrace.
> 
> I am afraid but GDB is not for me... :(

The error is not even consistent, it only occurs sometimes.  There seems to be a random memory corruption going on.  Sometimes bootstrap fails with a core dump, sometimes with

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.

And this is while compiling .el-files.  It is not crashing in the same .el-file, many files compile just fine before the crash happens (if it happens).  Redoing the make after a crash usually produces an Emacs executable.  It seems to run fine, but I haven't run it for a very long time.  Maybe the bug manifests itself only in bootstrap-emacs when using GLib?

I got one backtrace for the setspecific error:

Breakpoint 1, 0x610dcd26 in abort () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x610dcd26 in abort () from /usr/bin/cygwin1.dll
#1  0x6a90d066 in g_spawn_close_pid () from /usr/bin/cygglib-2.0-0.dll
#2  0x6a908e8c in g_private_set () from /usr/bin/cygglib-2.0-0.dll
#3  0x6a8f06ce in g_thread_self () from /usr/bin/cygglib-2.0-0.dll
#4  0x6a8ce250 in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll
#5  0x6a8ce2aa in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll
#6  0x6a8f017d in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
#7  0x610ffe1a in pthread::thread_init_wrapper(void*) ()
   from /usr/bin/cygwin1.dll
#8  0x6108974c in thread_wrapper(void*) () from /usr/bin/cygwin1.dll


This is in a separate thread, Emacs is executing in another thread:

(gdb) info threads
  Id   Target Id         Frame
* 3    Thread 1564.0x2d4 0x610dcd26 in abort () from /usr/bin/cygwin1.dll
  2    Thread 1564.0xfd0 0x7c90e514 in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  1    Thread 1564.0xa8c 0x0054b2d5 in oblookup (obarray=<optimized out>,
    ptr=<optimized out>, size=10, size_byte=<optimized out>) at lread.c:3905
(gdb) thr 1
[Switching to thread 1 (Thread 1564.0xa8c)]
#0  0x0054b2d5 in oblookup (obarray=<optimized out>, ptr=<optimized out>,
    size=10, size_byte=<optimized out>) at lread.c:3905
3905            if (SBYTES (SYMBOL_NAME (tail)) == size_byte

(gdb) thr 1
[Switching to thread 1 (Thread 1564.0xa8c)]
#0  0x0054b2d5 in oblookup (obarray=<optimized out>, ptr=<optimized out>,
    size=10, size_byte=<optimized out>) at lread.c:3905
3905            if (SBYTES (SYMBOL_NAME (tail)) == size_byte
(gdb) bt
#0  0x0054b2d5 in oblookup (obarray=<optimized out>, ptr=<optimized out>,
    size=10, size_byte=<optimized out>) at lread.c:3905
#1  0x0054b678 in intern_c_string_1 (
    str=0x779503 <targets.14003+4547> ":keepalive", len=10) at lread.c:3715
#2  0x0056b76b in intern_c_string (
    str=0x779503 <targets.14003+4547> ":keepalive") at lisp.h:3332
#3  init_process_emacs () at process.c:7144
#4  0x004bf335 in main (argc=<optimized out>, argv=0x22abc0) at emacs.c:1464
(gdb) fr3
Undefined command: "fr3".  Try "help".
(gdb) fr 3
#3  init_process_emacs () at process.c:7144
7144         subfeatures = pure_cons (intern_c_string (sopt->name), subfeatures);

As there seems to be no good memory debuggers for Cygwin, this will be hard to find.  I still think it is an GLib/Cygwin error.

	Jan D.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Tue, 11 Jun 2013 17:39:00 +0200
> Cc: eggert@cs.ucla.edu, 14569@debbugs.gnu.org
> 
> Breakpoint 1, 0x610dcd26 in abort () from /usr/bin/cygwin1.dll
> (gdb) bt
> #0  0x610dcd26 in abort () from /usr/bin/cygwin1.dll
> #1  0x6a90d066 in g_spawn_close_pid () from /usr/bin/cygglib-2.0-0.dll
> #2  0x6a908e8c in g_private_set () from /usr/bin/cygglib-2.0-0.dll
> #3  0x6a8f06ce in g_thread_self () from /usr/bin/cygglib-2.0-0.dll
> #4  0x6a8ce250 in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll
> #5  0x6a8ce2aa in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll
> #6  0x6a8f017d in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll
> #7  0x610ffe1a in pthread::thread_init_wrapper(void*) ()
>    from /usr/bin/cygwin1.dll
> #8  0x6108974c in thread_wrapper(void*) () from /usr/bin/cygwin1.dll

Can you find out (by looking at the glib sources) when and why would
g_spawn_close_pid call 'abort'?  It might give us some clues.

Also, what process (or is it a thread?) did glib spawn here, and why?

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/11/13 08:13, Angelo Graziosi wrote:
> $ ../configure --without-all
> ...
>   Does Emacs use a file notification library?             yes -lgio (gfile)

That's a bug; --without-all should disable file notification.

I installed a fix in trunk bzr 112928.
You'll also need --without-x (or some other non-glib X toolkit)
to suppress glib.

Please update to the trunk and then run:

   ./autogen.sh
   ./configure --without-all --without-x

This should build you a glib-less Emacs.  On my Fedora 17 host,
the shell command 'ldd src/temacs' reports:

	linux-vdso.so.1 =>  (0x00007fffcbffe000)
	libacl.so.1 => /lib64/libacl.so.1 (0x000000386cc00000)
	librt.so.1 => /lib64/librt.so.1 (0x000000385ea00000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003868a00000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x000000385e600000)
	libm.so.6 => /lib64/libm.so.6 (0x000000385de00000)
	libc.so.6 => /lib64/libc.so.6 (0x000000385da00000)
	libattr.so.1 => /lib64/libattr.so.1 (0x000000386ba00000)
	/lib64/ld-linux-x86-64.so.2 (0x000000385d600000)

Arguably, --without-all should disable some of these
remaining libraries, too; but at least it now disables glib.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/11/13 09:58, Eli Zaretskii wrote:
> Can you find out (by looking at the glib sources) when and why would
> g_spawn_close_pid call 'abort'?  It might give us some clues.

On POSIX platforms, g_spawn_close_pid does nothing.
So apparently glib is compiled for Windows (i.e.,
glib/gspawn.c is not being compiled, but glib/gspawn-win32.c
is being compiled instead.

The Emacs code that tickles gnulib is written this way:

#if defined HAVE_GLIB && !defined WINDOWSNT
      /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
	 this should always fail, but is enough to initialize glib's
	 private SIGCHLD handler.  */
      g_source_unref (g_child_watch_source_new (getpid ()));
#endif

I did notice one problem: the code previously invoked
g_child_watch_source_new (0), which is not safe if Emacs
has already forked -- perhaps Cygwin was doing that?
So I changed it to g_child_watch_source_new (getpid ())
in trunk bzr 112929.

Another thought is that there may be a mismatch between
glib builds.  Since WINDOWSNT is not defined for Cygwin builds,
a Cygwin Emacs will call g_child_watch_source_new.  My reading of
the bleeding-edge glib source code is that a Cygwin glib should call
waitpid and mess with the SIGCHLD handler, just as a
POSIX glib would, so the above Emacs code is correct.
But if you're building under Cygwin and linking with
a mingw glib, the above code may well run into problems.
Is this a possibility that we should worry about?

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

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

On 6/11/2013 2:50 PM, Paul Eggert wrote:
> On 06/11/13 09:58, Eli Zaretskii wrote:
>> Can you find out (by looking at the glib sources) when and why would
>> g_spawn_close_pid call 'abort'?  It might give us some clues.
>
> On POSIX platforms, g_spawn_close_pid does nothing.
> So apparently glib is compiled for Windows (i.e.,
> glib/gspawn.c is not being compiled, but glib/gspawn-win32.c
> is being compiled instead.

No, this is not the case.  I just replicated the glib build to make 
sure.  Cygwin is a POSIX platform, to the extent possible.

> The Emacs code that tickles gnulib is written this way:
>
> #if defined HAVE_GLIB && !defined WINDOWSNT
>        /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
> 	 this should always fail, but is enough to initialize glib's
> 	 private SIGCHLD handler.  */
>        g_source_unref (g_child_watch_source_new (getpid ()));
> #endif
>
> I did notice one problem: the code previously invoked
> g_child_watch_source_new (0), which is not safe if Emacs
> has already forked -- perhaps Cygwin was doing that?
> So I changed it to g_child_watch_source_new (getpid ())
> in trunk bzr 112929.
>
> Another thought is that there may be a mismatch between
> glib builds.  Since WINDOWSNT is not defined for Cygwin builds,
> a Cygwin Emacs will call g_child_watch_source_new.  My reading of
> the bleeding-edge glib source code is that a Cygwin glib should call
> waitpid and mess with the SIGCHLD handler, just as a
> POSIX glib would, so the above Emacs code is correct.
> But if you're building under Cygwin and linking with
> a mingw glib, the above code may well run into problems.
> Is this a possibility that we should worry about?

No.  This does not happen.  The Cygwin glib maintainer takes pains to 
patch the source if necessary to make sure that Cygwin is not treated 
like Windows.  See, for instance, the attached patch that is used in the 
Cygwin build.

Ken


[-- Attachment #2: 2.32.1-not-win32.patch --]
[-- Type: text/plain, Size: 11865 bytes --]

--- origsrc/glib-2.27.2/configure.ac	2010-10-29 21:36:51.000000000 -0500
+++ src/glib-2.27.2/configure.ac	2010-11-04 14:53:53.616433900 -0500
@@ -1855,7 +1855,7 @@ dnl ************************************
 
 AC_MSG_CHECKING(for platform-dependent source)
 case "$host" in
-  *-*-cygwin*|*-*-mingw*)
+  *-*-mingw*)
     PLATFORMDEP=gwin32.lo
     ;;
   *)
@@ -2696,9 +2696,6 @@ dnl *** Win32 API libs ***
 dnl **********************
 
 case $host in
-  *-*-cygwin*)
-	G_LIBS_EXTRA="-luser32 -lkernel32"
-    ;;
   *-*-mingw*)
 	G_LIBS_EXTRA="-lws2_32 -lole32"
     ;;
--- origsrc/glib-2.32.1/docs/reference/gio/Makefile.am	2012-03-11 19:42:39.000000000 -0500
+++ src/glib-2.32.1/docs/reference/gio/Makefile.am	2012-04-30 04:02:06.244723100 -0500
@@ -77,6 +77,8 @@ IGNORE_HFILES = \
 	gunixvolume.h			\
 	gunixvolumemonitor.h		\
 	gwin32appinfo.h			\
+	gwin32inputstream.h		\
+	gwin32outputstream.h		\
 	gwin32mount.h			\
 	gwin32resolver.h		\
 	gwin32volumemonitor.h
--- origsrc/glib-2.32.2/gio/giomodule-priv.h	2012-04-30 11:24:02.000000000 -0500
+++ src/glib-2.32.2/gio/giomodule-priv.h	2012-05-01 00:33:18.725235600 -0500
@@ -35,7 +35,7 @@ gpointer _g_io_module_get_default (const
 				   const gchar         *envvar,
 				   GIOModuleVerifyFunc  verify_func);
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 void *_g_io_win32_get_module (void);
 #endif
 
--- origsrc/glib-2.27.2/gio/giomodule.c	2010-10-16 22:31:23.000000000 -0500
+++ src/glib-2.27.2/gio/giomodule.c	2010-11-04 14:53:53.616433900 -0500
@@ -478,7 +478,7 @@ extern GType _g_winhttp_vfs_get_type (vo
 
 extern GType _g_dummy_proxy_resolver_get_type (void);
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 
 #include <windows.h>
 
--- origsrc/glib-2.27.2/gio/tests/live-g-file.c	2010-07-09 06:23:33.000000000 -0500
+++ src/glib-2.27.2/gio/tests/live-g-file.c	2010-11-04 14:53:53.632033900 -0500
@@ -1148,7 +1148,7 @@ main (int argc, char *argv[])
 	  write_test = TRUE;
 	  only_create_struct = FALSE;
 	  target_path = DEFAULT_TEST_DIR;
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 	  posix_compat = FALSE;
 #else
 	  posix_compat = TRUE;
--- origsrc/glib-2.32.1/glib/gatomic.c	2012-03-11 19:42:41.000000000 -0500
+++ src/glib-2.32.1/glib/gatomic.c	2012-04-30 02:16:33.314500200 -0500
@@ -464,7 +464,7 @@ gsize
   return g_atomic_pointer_xor ((volatile gpointer *) atomic, val);
 }
 
-#elif defined (G_PLATFORM_WIN32)
+#elif defined (G_OS_WIN32)
 
 #include <windows.h>
 #if !defined(_M_AMD64) && !defined (_M_IA64) && !defined(_M_X64)
--- origsrc/glib-2.32.1/glib/gcharset.c	2012-03-11 19:42:41.000000000 -0500
+++ src/glib-2.32.1/glib/gcharset.c	2012-04-30 02:17:01.563115900 -0500
@@ -496,7 +496,7 @@ guess_category_value (const gchar *categ
   if ((retval != NULL) && (retval[0] != '\0'))
     return retval;
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
   /* g_win32_getlocale() first checks for LC_ALL, LC_MESSAGES and
    * LANG, which we already did above. Oh well. The main point of
    * calling g_win32_getlocale() is to get the thread's locale as used
--- origsrc/glib-2.27.2/glib/gconvert.c	2010-09-13 08:40:53.000000000 -0500
+++ src/glib-2.27.2/glib/gconvert.c	2010-11-04 14:53:53.647634000 -0500
@@ -33,9 +33,6 @@
 
 #ifdef G_OS_WIN32
 #include "win_iconv.c"
-#endif
-
-#ifdef G_PLATFORM_WIN32
 #define STRICT
 #include <windows.h>
 #undef STRICT
@@ -1263,7 +1260,7 @@ g_locale_from_utf8 (const gchar *utf8str
 		      charset, "UTF-8", bytes_read, bytes_written, error);
 }
 
-#ifndef G_PLATFORM_WIN32
+#ifndef G_OS_WIN32
 
 typedef struct _GFilenameCharsetCache GFilenameCharsetCache;
 
@@ -1379,7 +1376,7 @@ g_get_filename_charsets (G_CONST_RETURN
   return cache->is_utf8;
 }
 
-#else /* G_PLATFORM_WIN32 */
+#else /* G_OS_WIN32 */
 
 gboolean
 g_get_filename_charsets (G_CONST_RETURN gchar ***filename_charsets) 
@@ -1408,7 +1405,7 @@ g_get_filename_charsets (G_CONST_RETURN
 #endif
 }
 
-#endif /* G_PLATFORM_WIN32 */
+#endif /* G_OS_WIN32 */
 
 static gboolean
 get_filename_charset (const gchar **filename_charset)
--- origsrc/glib-2.32.1/glib/gfileutils.c	2012-03-11 19:42:41.000000000 -0500
+++ src/glib-2.32.1/glib/gfileutils.c	2012-04-30 02:17:19.313131200 -0500
@@ -2176,7 +2176,7 @@ g_path_skip_root (const gchar *file_name
 {
   g_return_val_if_fail (file_name != NULL, NULL);
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
   /* Skip \\server\share or //server/share */
   if (G_IS_DIR_SEPARATOR (file_name[0]) &&
       G_IS_DIR_SEPARATOR (file_name[1]) &&
@@ -2186,7 +2186,6 @@ g_path_skip_root (const gchar *file_name
       gchar *p;
       p = strchr (file_name + 2, G_DIR_SEPARATOR);
 
-#ifdef G_OS_WIN32
       {
         gchar *q;
 
@@ -2194,7 +2193,6 @@ g_path_skip_root (const gchar *file_name
         if (p == NULL || (q != NULL && q < p))
         p = q;
       }
-#endif
 
       if (p && p > file_name + 2 && p[1])
         {
--- origsrc/glib-2.27.2/glib/glib.h	2010-09-17 17:01:03.000000000 -0500
+++ src/glib-2.27.2/glib/glib.h	2010-11-04 14:53:53.647634000 -0500
@@ -90,7 +90,7 @@
 #include <glib/gvariant.h>
 #include <glib/gversion.h>
 #include <glib/gversionmacros.h>
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 #include <glib/gwin32.h>
 #endif
 
--- origsrc/glib-2.27.2/glib/gutf8.c	2010-09-04 22:39:27.000000000 -0500
+++ src/glib-2.27.2/glib/gutf8.c	2010-11-04 14:53:53.663234000 -0500
@@ -27,7 +27,7 @@
 #endif
 #include <string.h>
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 #include <stdio.h>
 #define STRICT
 #include <windows.h>
--- origsrc/glib-2.32.1/glib/gutils.c	2012-03-11 19:42:42.000000000 -0500
+++ src/glib-2.32.1/glib/gutils.c	2012-04-30 02:13:18.139336800 -0500
@@ -71,7 +71,7 @@
 #include "garray.h"
 #include "glibintl.h"
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 #include "gconvert.h"
 #include "gwin32.h"
 #endif
@@ -85,16 +85,13 @@
  * These are portable utility functions.
  */
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 #  include <windows.h>
 #  ifndef GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
 #    define GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT 2
 #    define GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS 4
 #  endif
 #  include <lmcons.h>		/* For UNLEN */
-#endif /* G_PLATFORM_WIN32 */
-
-#ifdef G_OS_WIN32
 #  include <direct.h>
 #  include <shlobj.h>
    /* older SDK (e.g. msvc 5.0) does not have these*/
@@ -130,7 +127,7 @@
 #include <langinfo.h>
 #endif
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 
 gchar *
 _glib_get_dll_directory (void)
--- origsrc/glib-2.27.2/glib/gutils.h	2010-10-29 21:36:52.000000000 -0500
+++ src/glib-2.27.2/glib/gutils.h	2010-11-04 14:53:53.678834000 -0500
@@ -458,7 +458,7 @@ G_END_DECLS
  * On non-Windows platforms, expands to nothing.
  */
 
-#ifndef G_PLATFORM_WIN32
+#ifndef G_OS_WIN32
 # define G_WIN32_DLLMAIN_FOR_DLL_NAME(static, dll_name)
 #else
 # define G_WIN32_DLLMAIN_FOR_DLL_NAME(static, dll_name)			\
@@ -486,6 +486,6 @@ DllMain (HINSTANCE hinstDLL,						\
 
 #endif	/* !G_DISABLE_DEPRECATED */
 
-#endif /* G_PLATFORM_WIN32 */
+#endif /* G_OS_WIN32 */
 
 #endif /* __G_UTILS_H__ */
--- origsrc/glib-2.27.2/glib/gwin32.h	2009-03-31 18:04:20.000000000 -0500
+++ src/glib-2.27.2/glib/gwin32.h	2010-11-04 14:53:53.678834000 -0500
@@ -33,7 +33,7 @@
 
 #include <glib/gtypes.h>
 
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
 
 G_BEGIN_DECLS
 
@@ -41,8 +41,6 @@ G_BEGIN_DECLS
 #define MAXPATHLEN 1024
 #endif
 
-#ifdef G_OS_WIN32
-
 /*
  * To get prototypes for the following POSIXish functions, you have to
  * include the indicated non-POSIX headers. The functions are defined
@@ -67,7 +65,6 @@ G_BEGIN_DECLS
  */
 gint		g_win32_ftruncate	(gint		 f,
 					 guint		 size);
-#endif /* G_OS_WIN32 */
 
 /* The MS setlocale uses locale names of the form "English_United
  * States.1252" etc. We want the Unixish standard form "en", "zh_TW"
@@ -109,6 +106,6 @@ gchar*          g_win32_locale_filename_
 
 G_END_DECLS
 
-#endif	 /* G_PLATFORM_WIN32 */
+#endif	 /* G_OS_WIN32 */
 
 #endif /* __G_WIN32_H__ */
--- origsrc/glib-2.27.2/glib/libcharset/localcharset.c	2009-03-31 18:04:20.000000000 -0500
+++ src/glib-2.27.2/glib/libcharset/localcharset.c	2010-11-04 14:53:53.678834000 -0500
@@ -46,10 +46,6 @@
 #   include <locale.h>
 #  endif
 # endif
-# ifdef __CYGWIN__
-#  define WIN32_LEAN_AND_MEAN
-#  include <windows.h>
-# endif
 #elif defined WIN32_NATIVE
 # define WIN32_LEAN_AND_MEAN
 # include <windows.h>
@@ -111,7 +107,7 @@ _g_locale_get_charset_aliases (void)
   cp = charset_aliases;
   if (cp == NULL)
     {
-#if !(defined VMS || defined WIN32_NATIVE || defined __CYGWIN__)
+#if !(defined VMS || defined WIN32_NATIVE)
       FILE *fp;
       const char *dir;
       const char *base = "charset.alias";
@@ -237,7 +233,7 @@ _g_locale_get_charset_aliases (void)
 	   "DECKOREAN" "\0" "EUC-KR" "\0";
 # endif
 
-# if defined WIN32_NATIVE || defined __CYGWIN__
+# if defined WIN32_NATIVE
       /* To avoid the troubles of installing a separate file in the same
 	 directory as the DLL and of retrieving the DLL's directory at
 	 runtime, simply inline the aliases here.  */
@@ -292,53 +288,6 @@ _g_locale_charset_raw (void)
   /* Most systems support nl_langinfo (CODESET) nowadays.  */
   codeset = nl_langinfo (CODESET);
 
-#  ifdef __CYGWIN__
-  /* Cygwin 2006 does not have locales.  nl_langinfo (CODESET) always
-     returns "US-ASCII".  As long as this is not fixed, return the suffix
-     of the locale name from the environment variables (if present) or
-     the codepage as a number.  */
-  if (codeset != NULL && strcmp (codeset, "US-ASCII") == 0)
-    {
-      const char *locale;
-      static char buf[2 + 10 + 1];
-
-      locale = getenv ("LC_ALL");
-      if (locale == NULL || locale[0] == '\0')
-	{
-	  locale = getenv ("LC_CTYPE");
-	  if (locale == NULL || locale[0] == '\0')
-	    locale = getenv ("LANG");
-	}
-      if (locale != NULL && locale[0] != '\0')
-	{
-	  /* If the locale name contains an encoding after the dot, return
-	     it.  */
-	  const char *dot = strchr (locale, '.');
-
-	  if (dot != NULL)
-	    {
-	      const char *modifier;
-
-	      dot++;
-	      /* Look for the possible @... trailer and remove it, if any.  */
-	      modifier = strchr (dot, '@');
-	      if (modifier == NULL)
-		return dot;
-	      if (modifier - dot < sizeof (buf))
-		{
-		  memcpy (buf, dot, modifier - dot);
-		  buf [modifier - dot] = '\0';
-		  return buf;
-		}
-	    }
-	}
-
-      /* Woe32 has a function returning the locale's codepage as a number.  */
-      sprintf (buf, "CP%u", GetACP ());
-      codeset = buf;
-    }
-#  endif
-
 # else
 
   /* On old systems which lack it, use setlocale or getenv.  */
--- origsrc/glib-2.27.2/glib/tests/uri.c	2010-07-05 22:29:21.000000000 -0500
+++ src/glib-2.27.2/glib/tests/uri.c	2010-11-04 14:53:58.093641700 -0500
@@ -56,7 +56,7 @@ to_uri_tests[] = {
   { "c:\\windows", "otherhost", NULL, G_CONVERT_ERROR_NOT_ABSOLUTE_PATH},
 #endif
   { "etc", "localhost", NULL, G_CONVERT_ERROR_NOT_ABSOLUTE_PATH},
-#ifndef G_PLATFORM_WIN32
+#ifndef G_OS_WIN32
   { "/etc/\xE5\xE4\xF6", NULL, "file:///etc/%E5%E4%F6" },
   { "/etc/\xC3\xB6\xC3\xA4\xC3\xA5", NULL, "file:///etc/%C3%B6%C3%A4%C3%A5"},
 #endif
--- origsrc/glib-2.27.2/tests/Makefile.am	2010-08-16 13:43:54.000000000 -0500
+++ src/glib-2.27.2/tests/Makefile.am	2010-11-04 14:53:53.694434000 -0500
@@ -19,7 +19,9 @@ libadd_libgmodule = $(libgmodule)
 libadd_libglib = $(libglib)
 if PLATFORM_WIN32
 no_undefined = -no-undefined
+endif
 
+if OS_WIN32
 module_test_exp = module-test.exp
 
 module-test.exp: module-test.o
--- origsrc/glib-2.27.2/tests/testglib.c	2010-10-16 22:31:23.000000000 -0500
+++ src/glib-2.27.2/tests/testglib.c	2010-11-04 14:53:53.694434000 -0500
@@ -744,7 +744,7 @@ test_info (void)
 
   if (g_test_verbose())
     {
-#ifdef G_PLATFORM_WIN32
+#ifdef G_OS_WIN32
       g_print ("current locale: %s\n", g_win32_getlocale ());
 
       g_print ("found more.com as %s\n", g_find_program_in_path ("more.com"));

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Tue, 11 Jun 2013 15:26:56 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 14569@debbugs.gnu.org,
>         angelo.graziosi@alice.it
> 
> No.  This does not happen.  The Cygwin glib maintainer takes pains to 
> patch the source if necessary to make sure that Cygwin is not treated 
> like Windows.  See, for instance, the attached patch that is used in the 
> Cygwin build.

So, in this patched glib, what does g_spawn_close_pid do, and under
what circumstances could it call 'abort'?

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/11/2013 3:53 PM, Eli Zaretskii wrote:
>> Date: Tue, 11 Jun 2013 15:26:56 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: Eli Zaretskii <eliz@gnu.org>, 14569@debbugs.gnu.org,
>>          angelo.graziosi@alice.it
>>
>> No.  This does not happen.  The Cygwin glib maintainer takes pains to
>> patch the source if necessary to make sure that Cygwin is not treated
>> like Windows.  See, for instance, the attached patch that is used in the
>> Cygwin build.
>
> So, in this patched glib, what does g_spawn_close_pid do, and under
> what circumstances could it call 'abort'?

It does nothing.  So Jan's backtrace is suspect.  I don't know if that 
could result from optimization, but I'll build a non-optimized glib and 
see if I can get a more reliable backtrace.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Ciao Paul,

Il 11/06/2013 20.10, Paul Eggert ha scritto:
> On 06/11/13 08:13, Angelo Graziosi wrote:
>> $ ../configure --without-all
>> ...
>>    Does Emacs use a file notification library?             yes -lgio (gfile)
>
> That's a bug; --without-all should disable file notification.
>
> I installed a fix in trunk bzr 112928.
> You'll also need --without-x (or some other non-glib X toolkit)
> to suppress glib.
>
> Please update to the trunk and then run:
>
>     ./autogen.sh
>     ./configure --without-all --without-x



obviously the car without the wheels doesn't crash! ;)

Ciao,
  Angelo.


>
> This should build you a glib-less Emacs.  On my Fedora 17 host,
> the shell command 'ldd src/temacs' reports:
>
> 	linux-vdso.so.1 =>  (0x00007fffcbffe000)
> 	libacl.so.1 => /lib64/libacl.so.1 (0x000000386cc00000)
> 	librt.so.1 => /lib64/librt.so.1 (0x000000385ea00000)
> 	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003868a00000)
> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x000000385e600000)
> 	libm.so.6 => /lib64/libm.so.6 (0x000000385de00000)
> 	libc.so.6 => /lib64/libc.so.6 (0x000000385da00000)
> 	libattr.so.1 => /lib64/libattr.so.1 (0x000000386ba00000)
> 	/lib64/ld-linux-x86-64.so.2 (0x000000385d600000)
>
> Arguably, --without-all should disable some of these
> remaining libraries, too; but at least it now disables glib.
>

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello.

11 jun 2013 kl. 22:06 skrev Ken Brown <kbrown@cornell.edu>:

> On 6/11/2013 3:53 PM, Eli Zaretskii wrote:
>>> Date: Tue, 11 Jun 2013 15:26:56 -0400
>>> From: Ken Brown <kbrown@cornell.edu>
>>> CC: Eli Zaretskii <eliz@gnu.org>, 14569@debbugs.gnu.org,
>>>         angelo.graziosi@alice.it
>>> 
>>> No.  This does not happen.  The Cygwin glib maintainer takes pains to
>>> patch the source if necessary to make sure that Cygwin is not treated
>>> like Windows.  See, for instance, the attached patch that is used in the
>>> Cygwin build.
>> 
>> So, in this patched glib, what does g_spawn_close_pid do, and under
>> what circumstances could it call 'abort'?
> 
> It does nothing.  So Jan's backtrace is suspect.  I don't know if that could result from optimization, but I'll build a non-optimized glib and see if I can get a more reliable backtrace.
> 

It is suspect, the error message does belong to g_private_set (frame #2).  Frame #1 should have been g_thread_abort.  If there is indeed a memory corruption, such as a stack overwrite, that might explain it.  Or it might just be that gdb is in error.

The build BTW, was un-optimized.

	Jan D.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello.

11 jun 2013 kl. 22:58 skrev Jan Djärv <jan.h.d@swipnet.se>:

> 
> It is suspect, the error message does belong to g_private_set (frame #2).  Frame #1 should have been g_thread_abort.  If there is indeed a memory corruption, such as a stack overwrite, that might explain it.  Or it might just be that gdb is in error.
> 
> The build BTW, was un-optimized.

That is the Emacs build, I did not build GLib, so that was probably optimized.
We have seen in Emacs that breaks in abort shows strange backtraces.

	Jan D.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> Bootstrap got to fail on Cygwin since yesterday.  An error occurs
> at least when performing batch-update-autoloads as follows:

> [...]
> Wrote /Work/emacs/lisp/mh-e/mh-loaddefs.el
> (No changes need to be saved)
> EMACSLOADPATH=/Work/emacs/lisp LC_ALL=C /Work/emacs/src/bootstrap-emacs.exe \
>  -batch --no-site-file --no-site-lisp -l autoload \
>  --eval "(setq generate-autoload-cookie \";;;###tramp-autoload\")" \
>  --eval "(setq generated-autoload-file (unmsys--file-name
> \"/Work/emacs/lisp/net/tramp-loaddefs.el\"))" \
>  --eval "(setq make-backup-files nil)" \
>  -f batch-update-autoloads /Work/emacs/lisp/net
> GLib (gthread-posix.c): Unexpected error from C library during
> pthread_setspecific': Invalid argument.  Aborting.
> Makefile:392: recipe for target `/Work/emacs/lisp/net/tramp-loaddefs.el' failed
> make[3]: *** [/Work/emacs/lisp/net/tramp-loaddefs.el] Aborted
> [...]
> make: *** [bootstrap] Error 2

After that I tried `make -k' for four times and I got to get no
such error.  Though it must not be a right solution, the built
one works so far.  In the early three `make -k', the error
happened when byte-compiling an *.el file, but each time an *.el
file causing the error varied.  So, this isn't due to a Lisp code,
I guess.  For instance, one happened when compiling nntp.el, but
I can build Ma Gnus (from the Git master) without causing such
an error using this Emacs.  Anyway I will report it again if I
have a chance to get a C backtrace or other.

In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
 of 2013-06-12 on localhost
Bzr revision: 112936 yamaoka@jpl.org-20130612013823-xw8ar9emw320nl12
Windowing system distributor `The Cygwin/X Project', version 11.0.11401000
Configured using:
 `configure --verbose --with-x-toolkit=lucid --without-imagemagick
 --without-dbus --without-gconf --without-gsettings'

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

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

Hi.

Paul Eggert wrote:

> I did notice one problem: the code previously invoked g_child_watch_source_new (0), which is not safe if Emacs has already forked -- perhaps Cygwin was doing that? So I changed it to g_child_watch_source_new (getpid ()) in trunk bzr 112929.

It is crasches much less with this change, about one in three builds.  Previously it crasched on every build. 
Some sort of race condition, perhaps?

As for what the threads do, I don't know. There are five threads created when Emacs byte-compiles one file.

      Jan D. 

[-- Attachment #2: Type: text/html, Size: 2971 bytes --]

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/12/13 00:00, Jan Djärv wrote:
 
> It crashes much less with this change

That's surprising -- I'd expect it to either crash not
at all, or to crash just as often as before.

Can you strace a failing instance?  The syscall pattern
may help explain things.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Just for completeness,

Il 12/06/2013 20.33, Paul Eggert ha scritto:
> On 06/12/13 00:00, Jan Djärv wrote:
>
>> It crashes much less with this change
>
> That's surprising -- I'd expect it to either crash not
> at all, or to crash just as often as before.
>
> Can you strace a failing instance?  The syscall pattern
> may help explain things.
>

here it crashes (on different .el files) every time I try to build.


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello. 

12 jun 2013 kl. 22:11 skrev Angelo Graziosi <angelo.graziosi@alice.it>:

> Just for completeness,
> 
> Il 12/06/2013 20.33, Paul Eggert ha scritto:
>> On 06/12/13 00:00, Jan Djärv wrote:
>> 
>>> It crashes much less with this change
>> 
>> That's surprising -- I'd expect it to either crash not
>> at all, or to crash just as often as before.
>> 
>> Can you strace a failing instance?  The syscall pattern
>> may help explain things.
>> 
> 
> here it crashes (on different .el files) every time I try to build.
> 

Well, the crashes are kind of random, so maybe the randomness just shifted a bit on my system?

I do get segmentation violations sometimes instead of the pthread abort.  
But I haven't been able to get one while running the debugger yet 

     Jan D. 

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/13/13 00:08, Jan Djärv wrote:
> I do get segmentation violations sometimes instead of the pthread abort.  
> But I haven't been able to get one while running the debugger yet 

Which version of glib are you using?  Older versions
require special handholding with initialization,
e.g., g_type_init, and perhaps we're running into
that problem -- or perhaps you're using a newer
version and its autoinitialization code isn't working.

Also, a bit of Googling found this bug:

http://cygwin.com/ml/cygwin/2012-05/msg00472.html

where signals may nor may not reach the correct thread
with pthread_kill.  Emacs uses pthread_kill to redirect
SIGCHLD to the main thread; if this is sent to a random
thread instead, that could explain the random crashes
you're observing (maybe a recursive runaway in a
signal handler?).

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hi.

13 jun 2013 kl. 19:39 skrev Paul Eggert <eggert@cs.ucla.edu>:

> On 06/13/13 00:08, Jan Djärv wrote:
>> I do get segmentation violations sometimes instead of the pthread abort.  
>> But I haven't been able to get one while running the debugger yet 
> 
> Which version of glib are you using?  Older versions
> require special handholding with initialization,
> e.g., g_type_init, and perhaps we're running into
> that problem -- or perhaps you're using a newer
> version and its autoinitialization code isn't working.

Glib 2.32.3.  If g_type_init isn't run, an error message will be shown at once.  As it is now, Emacs runs for a bit before crashing.

> 
> Also, a bit of Googling found this bug:
> 
> http://cygwin.com/ml/cygwin/2012-05/msg00472.html
> 
> where signals may nor may not reach the correct thread
> with pthread_kill.  Emacs uses pthread_kill to redirect
> SIGCHLD to the main thread; if this is sent to a random
> thread instead, that could explain the random crashes
> you're observing (maybe a recursive runaway in a
> signal handler?).

Could be.  Unfortunately, Emacs does not crash when running under strace.

	Jan D.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

Cygwin developers, I'm worried about a Cygwin bug where
pthread_kill may not send a signal to the correct thread.
This bug may be causing Emacs to crash.  The Cygwin bug is
discussed in this thread:

http://cygwin.com/ml/cygwin/2012-05/msg00472.html

Emacs uses pthread_kill to redirect
SIGCHLD to the main thread; if this is sent to a random
thread instead, that could explain the random crashes.

My question is: does this bug still exist with Cygwin,
and if so is it likely to get fixed soon?

More details about the Emacs bug can be found here:

  http://bugs.gnu.org/14569

Briefly, Emacs is crashing randomly on Cygwin ever since it started
doing this:

  /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
     this should always fail, but is enough to initialize glib's            
     private SIGCHLD handler.  */
  g_source_unref (g_child_watch_source_new (getpid ()));

After this newly-inserted code, Emacs finds out what the
child signal handler was:

  /* Now, find out what glib's signal handler was, and store it
     into lib_child_handler.  */
  struct sigaction action, old_action;
  emacs_sigaction_init (&action, deliver_child_signal);
  sigaction (SIGCHLD, &action, &old_action);
  eassert (! (old_action.sa_flags & SA_SIGINFO));
  if (old_action.sa_handler != SIG_DFL && old_action.sa_handler != SIG_IGN
      && old_action.sa_handler != deliver_child_signal)
    lib_child_handler = old_action.sa_handler;

Emacs's SIGCHILD handler, deliver_child_signal, arranges the
signal handling to occur in the main thread (to avoid races
within Emacs), like this:

  int old_errno = errno;
  bool on_main_thread = true;
  if (! pthread_equal (pthread_self (), main_thread))
    {
      sigset_t blocked;
      sigemptyset (&blocked);
      sigaddset (&blocked, sig);
      pthread_sigmask (SIG_BLOCK, &blocked, 0);
      pthread_kill (main_thread, sig);
      on_main_thread = false;
    }
  if (on_main_thread)
    handle_child_signal (sig);
  errno = old_errno;

And handle_child_signal, which runs in the main thread, does
a bunch of Emacsish things and then invokes lib_child_handler (sig),
which is glib's SIGCHLD handler.

All this works just fine on Fedora and other platforms; but it
doesn't work on Cygwin.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Christopher Faylor]

On Fri, Jun 14, 2013 at 10:45:47AM -0700, Paul Eggert wrote:
>Cygwin developers, I'm worried about a Cygwin bug where
>pthread_kill may not send a signal to the correct thread.
>This bug may be causing Emacs to crash.  The Cygwin bug is
>discussed in this thread:
>
>http://cygwin.com/ml/cygwin/2012-05/msg00472.html
>
>Emacs uses pthread_kill to redirect
>SIGCHLD to the main thread; if this is sent to a random
>thread instead, that could explain the random crashes.
>
>My question is: does this bug still exist with Cygwin,
>and if so is it likely to get fixed soon?

You pointed to an archived mail messages which implies that was fixed
more than a year ago.  What makes you think it is still a problem?

I'd expect that if it was still a problem our emacs maintainer would
be on top of it.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Christopher Faylor]

On Fri, Jun 14, 2013 at 10:45:47AM -0700, Paul Eggert wrote:
>Cygwin developers, I'm worried about a Cygwin bug where
>pthread_kill may not send a signal to the correct thread.
>This bug may be causing Emacs to crash.  The Cygwin bug is
>discussed in this thread:
>
>http://cygwin.com/ml/cygwin/2012-05/msg00472.html
>
>Emacs uses pthread_kill to redirect
>SIGCHLD to the main thread; if this is sent to a random
>thread instead, that could explain the random crashes.
>
>My question is: does this bug still exist with Cygwin,
>and if so is it likely to get fixed soon?

You pointed to an archived mail messages which implies that was fixed
more than a year ago.  What makes you think it is still a problem?

I'd expect that if it was still a problem our emacs maintainer would
be on top of it.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Fri, 14 Jun 2013 10:45:47 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 14569@debbugs.gnu.org
> 
> Cygwin developers, I'm worried about a Cygwin bug where
> pthread_kill may not send a signal to the correct thread.
> This bug may be causing Emacs to crash.  The Cygwin bug is
> discussed in this thread:
> 
> http://cygwin.com/ml/cygwin/2012-05/msg00472.html

Caveat: I'm not a Cygwin developer, and don't even use Cygwin.

> Emacs uses pthread_kill to redirect
> SIGCHLD to the main thread; if this is sent to a random
> thread instead, that could explain the random crashes.

It should be easy to instrument deliver_child_signal so that it prints
something when it redirects SIGCHLD, and then the Cygwin users could
see if there's such a report immediately before the crash, or at all.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/14/2013 2:03 PM, Christopher Faylor wrote:
> On Fri, Jun 14, 2013 at 10:45:47AM -0700, Paul Eggert wrote:
>> Cygwin developers, I'm worried about a Cygwin bug where
>> pthread_kill may not send a signal to the correct thread.
>> This bug may be causing Emacs to crash.  The Cygwin bug is
>> discussed in this thread:
>>
>> http://cygwin.com/ml/cygwin/2012-05/msg00472.html
>>
>> Emacs uses pthread_kill to redirect
>> SIGCHLD to the main thread; if this is sent to a random
>> thread instead, that could explain the random crashes.
>>
>> My question is: does this bug still exist with Cygwin,
>> and if so is it likely to get fixed soon?
>
> You pointed to an archived mail messages which implies that was fixed
> more than a year ago.  What makes you think it is still a problem?
>
> I'd expect that if it was still a problem our emacs maintainer would
> be on top of it.

Unfortunately, the emacs maintainer doesn't have any idea why the recent 
emacs changes are causing random crashes on Cygwin.  It's almost 
impossible to catch this under gdb; and the one time it was caught, the 
backtrace didn't make sense.  Also, the crash doesn't occur when emacs 
is run under strace.

I'm not going to speculate on whether the problem is caused by a bug in 
Cygwin's pthread_kill.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Fri, 14 Jun 2013 16:22:26 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: 14569@debbugs.gnu.org
> 
> Unfortunately, the emacs maintainer doesn't have any idea why the recent 
> emacs changes are causing random crashes on Cygwin.  It's almost 
> impossible to catch this under gdb; and the one time it was caught, the 
> backtrace didn't make sense.  Also, the crash doesn't occur when emacs 
> is run under strace.

What are the difficulties of catching this when Emacs is run under
GDB?

P.S.  I removed the Cygwin list from the adressees, as I don't think
we have any evidence at this time that this is a Cygwin problem.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello.

15 jun 2013 kl. 09:04 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Fri, 14 Jun 2013 16:22:26 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: 14569@debbugs.gnu.org
>> 
>> Unfortunately, the emacs maintainer doesn't have any idea why the recent 
>> emacs changes are causing random crashes on Cygwin.  It's almost 
>> impossible to catch this under gdb; and the one time it was caught, the 
>> backtrace didn't make sense.  Also, the crash doesn't occur when emacs 
>> is run under strace.
> 
> What are the difficulties of catching this when Emacs is run under
> GDB?

Its not difficult, but takes some time.  The error happens when make compiles one lisp file at the time with emacs.  It appears to be random so it does not crash in the same lisp-file.  Thus, you have to start emacs from gdb, and repet run, quit in gdb for each lisp file until it crashes.  Running in gdb is slow with cygwin, and running in gdb makes the bug appear less often.

The make rule is in lisp/Makefile, compile-onefile.

	Jan D.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 15 Jun 2013 11:54:16 +0200
> Cc: Ken Brown <kbrown@cornell.edu>,
>  14569@debbugs.gnu.org
> 
> > What are the difficulties of catching this when Emacs is run under
> > GDB?
> 
> Its not difficult, but takes some time.  The error happens when make compiles one lisp file at the time with emacs.  It appears to be random so it does not crash in the same lisp-file.  Thus, you have to start emacs from gdb, and repet run, quit in gdb for each lisp file until it crashes.  Running in gdb is slow with cygwin, and running in gdb makes the bug appear less often.
> 
> The make rule is in lisp/Makefile, compile-onefile.

Would it make things easier if compile-onefile is modified to invoke
Emacs under GDB to begin with, using the --args switch to GDB?

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello.

15 jun 2013 kl. 12:42 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sat, 15 Jun 2013 11:54:16 +0200
>> Cc: Ken Brown <kbrown@cornell.edu>,
>> 14569@debbugs.gnu.org
>> 
>>> What are the difficulties of catching this when Emacs is run under
>>> GDB?
>> 
>> Its not difficult, but takes some time.  The error happens when make compiles one lisp file at the time with emacs.  It appears to be random so it does not crash in the same lisp-file.  Thus, you have to start emacs from gdb, and repet run, quit in gdb for each lisp file until it crashes.  Running in gdb is slow with cygwin, and running in gdb makes the bug appear less often.
>> 
>> The make rule is in lisp/Makefile, compile-onefile.
> 
> Would it make things easier if compile-onefile is modified to invoke
> Emacs under GDB to begin with, using the --args switch to GDB?

That is what I do. 

      Jan D. 

Re: bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Christopher Faylor wrote
>>On 06/14/2013 11:03 AM, Christopher Faylor wrote:
>>>You pointed to an archived mail messages which implies that was fixed
>>>more than a year ago.  What makes you think it is still a problem?
>>
>>The message I pointed to
>><http://cygwin.com/ml/cygwin/2012-05/msg00472.html> says this:
>>
>>>Testcase signal/kill: Signals may or may not reach the correct thread
>>>with 1.7.12-1 and newer.
>>
>>Confirmed.  I think the reason is that we only have a single event to
>>signal that a POSIX signal arrived instead of a per-thread event, but
>>I'm not sure.  This is cgf's domain so I leave it at that for now.
>>
>>I interpreted this to mean "the existence of the bug is confirmed,
>>here's why the bug occurs, and I'll let cgf deal with it".  I didn't
>>see any followup message where cgf (is that you?) dealt with it.  My
>>apologies if I misinterpreted the email.
>
> Oops.  I didn't read Corinna's message as thoroughly as I should have.
> Sorry.
>
> That particular issue was supposed to have been fixed in Cygwin 1.7.17,
> released in October 2012.

Out of curiosity, I tried the test cases I found in that thread, more 
precisely here:

   http://cygwin.com/ml/cygwin/2012-05/msg00434.html


and the results are:

$ gcc otto_test1.c -o otto_test1
$ ./otto_test1
Testing deferred pthread_cancel()

Thread 0 starting (0x200102c0)
Thread 1 starting (0x20010360)
Thread 2 starting (0x20010400)

Cancelling thread 2 (0x20010400)
Thread 2 exiting (0x20010400)
Cancelling thread 1 (0x20010360)
Thread 1 exiting (0x20010360)
Cancelling thread 0 (0x200102c0)
Thread 0 exiting (0x200102c0)

Thread 0 is gone (0x200102c0)
Thread 1 is gone (0x20010360)
Thread 2 is gone (0x20010400)

$ gcc otto_test2.c -o otto_test2
$ ./otto_test2
Testing asynchronous pthread_cancel()

Thread 0 starting (0x200102c0)
Changing canceltype from 0 to 1
Thread 1 starting (0x20010360)
Changing canceltype from 0 to 1
Thread 2 starting (0x20010400)
Changing canceltype from 0 to 1

Cancelling thread 2 (0x20010400)
Thread 2 exiting (0x20010400)
Cancelling thread 1 (0x20010360)
Thread 1 exiting (0x20010360)
Cancelling thread 0 (0x200102c0)
Thread 0 exiting (0x200102c0)

Thread 0 is gone (0x200102c0)
Thread 1 is gone (0x20010360)
Thread 2 is gone (0x20010400)

$ gcc otto_test3.c -o otto_test3
$ ./otto_test3
Testing pthread_kill()

Thread 0 starting (0x200102c0)
Thread 1 starting (0x20010360)
Thread 2 starting (0x20010400)

Sending SIGUSR1 to thread 2 (0x20010400)
Thread 2 executes signal handler (0x20010400)
Thread 2 encountered an error: Interrupted system call (0x20010400)
Sending SIGUSR1 to thread 1 (0x20010360)
Thread 1 executes signal handler (0x20010360)
Thread 1 encountered an error: Interrupted system call (0x20010360)
Sending SIGUSR1 to thread 0 (0x200102c0)
Thread 0 executes signal handler (0x200102c0)
Thread 0 encountered an error: Interrupted system call (0x200102c0)

Are the errors in the last test case to be expected under the 20130612 
snapshot (CYGWIN_NT-5.1, 1.7.21s 20130612 21:06:59, i686 Cygwin)?


Ciao,
Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

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

[Adding the bug address back to the CC so that this gets archived.]

On 6/15/2013 9:54 AM, Angelo Graziosi wrote:
> Christopher Faylor wrote
>>> On 06/14/2013 11:03 AM, Christopher Faylor wrote:
>>>> You pointed to an archived mail messages which implies that was fixed
>>>> more than a year ago.  What makes you think it is still a problem?
>>>
>>> The message I pointed to
>>> <http://cygwin.com/ml/cygwin/2012-05/msg00472.html> says this:
>>>
>>>> Testcase signal/kill: Signals may or may not reach the correct thread
>>>> with 1.7.12-1 and newer.
>>>
>>> Confirmed.  I think the reason is that we only have a single event to
>>> signal that a POSIX signal arrived instead of a per-thread event, but
>>> I'm not sure.  This is cgf's domain so I leave it at that for now.
>>>
>>> I interpreted this to mean "the existence of the bug is confirmed,
>>> here's why the bug occurs, and I'll let cgf deal with it".  I didn't
>>> see any followup message where cgf (is that you?) dealt with it.  My
>>> apologies if I misinterpreted the email.
>>
>> Oops.  I didn't read Corinna's message as thoroughly as I should have.
>> Sorry.
>>
>> That particular issue was supposed to have been fixed in Cygwin 1.7.17,
>> released in October 2012.
>
> Out of curiosity, I tried the test cases I found in that thread, more
> precisely here:
>
>    http://cygwin.com/ml/cygwin/2012-05/msg00434.html
>
>
> and the results are:
>
> $ gcc otto_test1.c -o otto_test1
> $ ./otto_test1
> Testing deferred pthread_cancel()
>
> Thread 0 starting (0x200102c0)
> Thread 1 starting (0x20010360)
> Thread 2 starting (0x20010400)
>
> Cancelling thread 2 (0x20010400)
> Thread 2 exiting (0x20010400)
> Cancelling thread 1 (0x20010360)
> Thread 1 exiting (0x20010360)
> Cancelling thread 0 (0x200102c0)
> Thread 0 exiting (0x200102c0)
>
> Thread 0 is gone (0x200102c0)
> Thread 1 is gone (0x20010360)
> Thread 2 is gone (0x20010400)
>
> $ gcc otto_test2.c -o otto_test2
> $ ./otto_test2
> Testing asynchronous pthread_cancel()
>
> Thread 0 starting (0x200102c0)
> Changing canceltype from 0 to 1
> Thread 1 starting (0x20010360)
> Changing canceltype from 0 to 1
> Thread 2 starting (0x20010400)
> Changing canceltype from 0 to 1
>
> Cancelling thread 2 (0x20010400)
> Thread 2 exiting (0x20010400)
> Cancelling thread 1 (0x20010360)
> Thread 1 exiting (0x20010360)
> Cancelling thread 0 (0x200102c0)
> Thread 0 exiting (0x200102c0)
>
> Thread 0 is gone (0x200102c0)
> Thread 1 is gone (0x20010360)
> Thread 2 is gone (0x20010400)
>
> $ gcc otto_test3.c -o otto_test3
> $ ./otto_test3
> Testing pthread_kill()
>
> Thread 0 starting (0x200102c0)
> Thread 1 starting (0x20010360)
> Thread 2 starting (0x20010400)
>
> Sending SIGUSR1 to thread 2 (0x20010400)
> Thread 2 executes signal handler (0x20010400)
> Thread 2 encountered an error: Interrupted system call (0x20010400)
> Sending SIGUSR1 to thread 1 (0x20010360)
> Thread 1 executes signal handler (0x20010360)
> Thread 1 encountered an error: Interrupted system call (0x20010360)
> Sending SIGUSR1 to thread 0 (0x200102c0)
> Thread 0 executes signal handler (0x200102c0)
> Thread 0 encountered an error: Interrupted system call (0x200102c0)
>
> Are the errors in the last test case to be expected under the 20130612
> snapshot (CYGWIN_NT-5.1, 1.7.21s 20130612 21:06:59, i686 Cygwin)?

I can replicate this on my system, consistently.  There's clearly a 
problem, but it's not the same as in the original Cygwin bug report.  In 
the present case, the signal is received by the right thread, but 
something goes wrong afterwards.

I'm attaching the test case for ease of reference.

Ken

[-- Attachment #2: otto_test3.c --]
[-- Type: text/plain, Size: 2544 bytes --]

/* http://cygwin.com/ml/cygwin/2012-05/msg00434.html */

#include <errno.h>
#include <pthread.h>
#include <semaphore.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

pthread_t tids[3];
sem_t semaphore;

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);

  pthread_cleanup_push(&cleanup_handler, intptr);

  while (1) {
    if (sem_wait(&semaphore) != 0) {
      fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
          *intptr, strerror(errno), self);
    } else {
      fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
    }
  }

  pthread_cleanup_pop(1);
  return NULL;
}

static void sigusr1_handler(int signal __attribute((unused))) {
  pthread_t self = pthread_self();
  int tnum = 0;
  while (tnum < 3) {
    if (tids[tnum] == self) {
      break;
    }
    tnum++;
  }

  fprintf(stderr, "Thread %i executes signal handler (%p)\n", tnum, self);
}

static void install_handler(void) {
  struct sigaction act;
  act.sa_handler = &sigusr1_handler;
  sigemptyset(&(act.sa_mask));
  act.sa_flags = 0;

  if (sigaction(SIGUSR1, &act, NULL) != 0) {
    fprintf(stderr, "Can't set signal handler: %s\n", strerror(errno));
    exit(1);
  }

  sigset_t sset;
  sigemptyset(&sset);
  sigaddset(&sset, SIGUSR1);
  if (sigprocmask(SIG_UNBLOCK, &sset, NULL) != 0) {
    fprintf(stderr, "Can't unblock SIGUSR1: %s\n", strerror(errno));
  }
}

int main() {
  fprintf(stderr, "Testing pthread_kill()\n\n");

  int i;
  int result;

  sem_init(&semaphore, 0, 0);
  install_handler();

  for (i=0; i<3; i++) {
    int *intptr = (int*)malloc(sizeof(int));
    *intptr = i;
    result = pthread_create(tids+i, NULL, &simplethread, intptr);
    if (result != 0) {
      fprintf(stderr, "Can't create thread: %s\n", strerror(result));
      return 1;
    }
  }

  sleep(1);
  install_handler();
  fprintf(stderr, "\n");

  int mainint = 42;
  pthread_cleanup_push(&cleanup_handler, &mainint);

  for (i=2; i>=0; i--) {
    fprintf(stderr, "Sending SIGUSR1 to thread %i (%p)\n", i, tids[i]);
    result = pthread_kill(tids[i], SIGUSR1);
    if (result != 0) {
      fprintf(stderr, "Error during pthread_kill: %s\n", strerror(result));
    }
    sleep(1);
  }

  pthread_cleanup_pop(0);
  return 0;
}

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/16/2013 11:01 AM, Christopher Faylor wrote:
> On Sun, Jun 16, 2013 at 09:11:21AM -0400, Ken Brown wrote:
>> [Adding the bug address back to the CC so that this gets archived.]
>>
>> On 6/15/2013 9:54 AM, Angelo Graziosi wrote:
>>> Christopher Faylor wrote
>>>>> On 06/14/2013 11:03 AM, Christopher Faylor wrote:
>>>>>> You pointed to an archived mail messages which implies that was fixed
>>>>>> more than a year ago.  What makes you think it is still a problem?
>>>>>
>>>>> The message I pointed to
>>>>> <http://cygwin.com/ml/cygwin/2012-05/msg00472.html> says this:
>>>>>
>>>>>> Testcase signal/kill: Signals may or may not reach the correct thread
>>>>>> with 1.7.12-1 and newer.
>>>>>
>>>>> Confirmed.  I think the reason is that we only have a single event to
>>>>> signal that a POSIX signal arrived instead of a per-thread event, but
>>>>> I'm not sure.  This is cgf's domain so I leave it at that for now.
>>>>>
>>>>> I interpreted this to mean "the existence of the bug is confirmed,
>>>>> here's why the bug occurs, and I'll let cgf deal with it".  I didn't
>>>>> see any followup message where cgf (is that you?) dealt with it.  My
>>>>> apologies if I misinterpreted the email.
>>>>
>>>> Oops.  I didn't read Corinna's message as thoroughly as I should have.
>>>> Sorry.
>>>>
>>>> That particular issue was supposed to have been fixed in Cygwin 1.7.17,
>>>> released in October 2012.
>>>
>>> Out of curiosity, I tried the test cases I found in that thread, more
>>> precisely here:
>>>
>>>     http://cygwin.com/ml/cygwin/2012-05/msg00434.html
>>>
>>>
>>> and the results are:
>>>
>>> $ gcc otto_test1.c -o otto_test1
>>> $ ./otto_test1
>>> Testing deferred pthread_cancel()
>>>
>>> Thread 0 starting (0x200102c0)
>>> Thread 1 starting (0x20010360)
>>> Thread 2 starting (0x20010400)
>>>
>>> Cancelling thread 2 (0x20010400)
>>> Thread 2 exiting (0x20010400)
>>> Cancelling thread 1 (0x20010360)
>>> Thread 1 exiting (0x20010360)
>>> Cancelling thread 0 (0x200102c0)
>>> Thread 0 exiting (0x200102c0)
>>>
>>> Thread 0 is gone (0x200102c0)
>>> Thread 1 is gone (0x20010360)
>>> Thread 2 is gone (0x20010400)
>>>
>>> $ gcc otto_test2.c -o otto_test2
>>> $ ./otto_test2
>>> Testing asynchronous pthread_cancel()
>>>
>>> Thread 0 starting (0x200102c0)
>>> Changing canceltype from 0 to 1
>>> Thread 1 starting (0x20010360)
>>> Changing canceltype from 0 to 1
>>> Thread 2 starting (0x20010400)
>>> Changing canceltype from 0 to 1
>>>
>>> Cancelling thread 2 (0x20010400)
>>> Thread 2 exiting (0x20010400)
>>> Cancelling thread 1 (0x20010360)
>>> Thread 1 exiting (0x20010360)
>>> Cancelling thread 0 (0x200102c0)
>>> Thread 0 exiting (0x200102c0)
>>>
>>> Thread 0 is gone (0x200102c0)
>>> Thread 1 is gone (0x20010360)
>>> Thread 2 is gone (0x20010400)
>>>
>>> $ gcc otto_test3.c -o otto_test3
>>> $ ./otto_test3
>>> Testing pthread_kill()
>>>
>>> Thread 0 starting (0x200102c0)
>>> Thread 1 starting (0x20010360)
>>> Thread 2 starting (0x20010400)
>>>
>>> Sending SIGUSR1 to thread 2 (0x20010400)
>>> Thread 2 executes signal handler (0x20010400)
>>> Thread 2 encountered an error: Interrupted system call (0x20010400)
>>> Sending SIGUSR1 to thread 1 (0x20010360)
>>> Thread 1 executes signal handler (0x20010360)
>>> Thread 1 encountered an error: Interrupted system call (0x20010360)
>>> Sending SIGUSR1 to thread 0 (0x200102c0)
>>> Thread 0 executes signal handler (0x200102c0)
>>> Thread 0 encountered an error: Interrupted system call (0x200102c0)
>>>
>>> Are the errors in the last test case to be expected under the 20130612
>>> snapshot (CYGWIN_NT-5.1, 1.7.21s 20130612 21:06:59, i686 Cygwin)?
>>
>> I can replicate this on my system, consistently.  There's clearly a
>> problem, but it's not the same as in the original Cygwin bug report.  In
>> the present case, the signal is received by the right thread, but
>> something goes wrong afterwards.
>
> Try it on Linux.  I don't see any difference.  "An error" in this case
> seems to be the script working as designed.
>
> % man sem_wait
>
>      SEM_WAIT(3)   Linux Programmer's Manual      SEM_WAIT(3)
>
>
>
>      NAME
> 	   sem_wait, sem_timedwait, sem_trywait - lock a semaphore
>
>      ...
>
>      ERRORS
> 	   EINTR  The call was interrupted by a signal handler; see signal(7).

Yeah, I missed that.  Sorry for the noise.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

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

On 6/16/2013 1:51 PM, Ken Brown wrote:
>>      ERRORS
>>        EINTR  The call was interrupted by a signal handler; see
>> signal(7).

I've revised the test case (attached) so that it checks for EINTR.  It 
now runs as expected on Cygwin:

Testing pthread_kill()

Thread 0 starting (0x800102a8)
Thread 1 starting (0x80010348)
Thread 2 starting (0x800103e8)

Sending SIGUSR1 to thread 2 (0x800103e8)
Thread 2 executes signal handler (0x800103e8)
Thread 2 woke up just fine
Sending SIGUSR1 to thread 1 (0x80010348)
Thread 1 executes signal handler (0x80010348)
Thread 1 woke up just fine
Sending SIGUSR1 to thread 0 (0x800102a8)
Thread 0 executes signal handler (0x800102a8)
Thread 0 woke up just fine

So there's no reason to think that a pthread_kill bug is causing the 
problem.  Back to the drawing board.

Ken

[-- Attachment #2: otto_test4.c --]
[-- Type: text/plain, Size: 2563 bytes --]

/* http://cygwin.com/ml/cygwin/2012-05/msg00434.html */

#include <errno.h>
#include <pthread.h>
#include <semaphore.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

pthread_t tids[3];
sem_t semaphore;

static void cleanup_handler(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}

static void* simplethread(void *arg) {
  int *intptr = (int*)arg;
  pthread_t self = pthread_self();
  fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);

  pthread_cleanup_push(&cleanup_handler, intptr);

  while (1) {
    if (sem_wait(&semaphore) != 0  && errno != EINTR) {
      fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
          *intptr, strerror(errno), self);
    } else {
      fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
    }
  }

  pthread_cleanup_pop(1);
  return NULL;
}

static void sigusr1_handler(int signal __attribute((unused))) {
  pthread_t self = pthread_self();
  int tnum = 0;
  while (tnum < 3) {
    if (tids[tnum] == self) {
      break;
    }
    tnum++;
  }

  fprintf(stderr, "Thread %i executes signal handler (%p)\n", tnum, self);
}

static void install_handler(void) {
  struct sigaction act;
  act.sa_handler = &sigusr1_handler;
  sigemptyset(&(act.sa_mask));
  act.sa_flags = 0;

  if (sigaction(SIGUSR1, &act, NULL) != 0) {
    fprintf(stderr, "Can't set signal handler: %s\n", strerror(errno));
    exit(1);
  }

  sigset_t sset;
  sigemptyset(&sset);
  sigaddset(&sset, SIGUSR1);
  if (sigprocmask(SIG_UNBLOCK, &sset, NULL) != 0) {
    fprintf(stderr, "Can't unblock SIGUSR1: %s\n", strerror(errno));
  }
}

int main() {
  fprintf(stderr, "Testing pthread_kill()\n\n");

  int i;
  int result;

  sem_init(&semaphore, 0, 0);
  install_handler();

  for (i=0; i<3; i++) {
    int *intptr = (int*)malloc(sizeof(int));
    *intptr = i;
    result = pthread_create(tids+i, NULL, &simplethread, intptr);
    if (result != 0) {
      fprintf(stderr, "Can't create thread: %s\n", strerror(result));
      return 1;
    }
  }

  sleep(1);
  install_handler();
  fprintf(stderr, "\n");

  int mainint = 42;
  pthread_cleanup_push(&cleanup_handler, &mainint);

  for (i=2; i>=0; i--) {
    fprintf(stderr, "Sending SIGUSR1 to thread %i (%p)\n", i, tids[i]);
    result = pthread_kill(tids[i], SIGUSR1);
    if (result != 0) {
      fprintf(stderr, "Error during pthread_kill: %s\n", strerror(result));
    }
    sleep(1);
  }

  pthread_cleanup_pop(0);
  return 0;
}

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/15/2013 8:47 AM, Jan Djärv wrote:
> Hello.
>
> 15 jun 2013 kl. 12:42 skrev Eli Zaretskii <eliz@gnu.org>:
>
>>> From: Jan Djärv <jan.h.d@swipnet.se>
>>> Date: Sat, 15 Jun 2013 11:54:16 +0200
>>> Cc: Ken Brown <kbrown@cornell.edu>,
>>> 14569@debbugs.gnu.org
>>>
>>>> What are the difficulties of catching this when Emacs is run under
>>>> GDB?
>>>
>>> Its not difficult, but takes some time.  The error happens when make compiles one lisp file at the time with emacs.  It appears to be random so it does not crash in the same lisp-file.  Thus, you have to start emacs from gdb, and repet run, quit in gdb for each lisp file until it crashes.  Running in gdb is slow with cygwin, and running in gdb makes the bug appear less often.
>>>
>>> The make rule is in lisp/Makefile, compile-onefile.
>>
>> Would it make things easier if compile-onefile is modified to invoke
>> Emacs under GDB to begin with, using the --args switch to GDB?
>
> That is what I do.

Can you tell me exactly how you modified the rule for compile-onefile? 
I tried but kept getting errors, so I'm obviously not doing it right.

Thanks.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Jan Djärv]

Hello. 


17 jun 2013 kl. 03:56 skrev Ken Brown <kbrown@cornell.edu>:

> 
> Can you tell me exactly how you modified the rule for compile-onefile? I tried but kept getting errors, so I'm obviously not doing it right.

There is something fishy with quoting, Cygwin and gdb so you have to comment out BIG_STACK_OPTS. 

Then I added:

emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb -ex 'b abort' -ex run --args $(EMACS) $(EMACSOPT)

and used it:

compile-onefile:
	echo Compiling $(THEFILE)
	@# Use byte-compile-refresh-preloaded to try and work around some of
	@# the most common bootstrapping problems.
	$(emacsdbg) $(BYTE_COMPILE_FLAGS) \
		-l bytecomp -f byte-compile-refresh-preloaded \
		-f batch-byte-compile $(THEFILE)

The modifications where done in the generated Makefile. I guess it will work in Makefile.in also. 

      Jan D. 

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,
>  "14569@debbugs.gnu.org" <14569@debbugs.gnu.org>
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Mon, 17 Jun 2013 08:22:54 +0200
> 
> emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb -ex 'b abort' -ex run --args $(EMACS) $(EMACSOPT)

This should make your life quality better, I think:

  emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb --batch-silent --return-child-result -ex 'b abort' -ex run --args $(EMACS) $(EMACSOPT)

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/17/2013 11:06 AM, Eli Zaretskii wrote:
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>>   "14569@debbugs.gnu.org" <14569@debbugs.gnu.org>
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Mon, 17 Jun 2013 08:22:54 +0200
>>
>> emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb -ex 'b abort' -ex run --args $(EMACS) $(EMACSOPT)
>
> This should make your life quality better, I think:
>
>    emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb --batch-silent --return-child-result -ex 'b abort' -ex run --args $(EMACS) $(EMACSOPT)

This causes gdb to exit, whether or not the breakpoint was hit, without 
giving the user a chance to get a backtrace.  I tried adding

   -x $(lisp)/commands.txt

where commands.txt contains

   commands
   bt
   end

but that didn't work.  gdb still exited (with an error) when 
compile-onefile failed, but it didn't print a backtrace first.  There 
has to be a way to get a backtrace when gdb runs in batch mode.  Do you 
know how, Eli?

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Mon, 17 Jun 2013 16:15:33 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 14569@debbugs.gnu.org
> 
> >    emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb --batch-silent --return-child-result -ex 'b abort' -ex run --args $(EMACS) $(EMACSOPT)
> 
> This causes gdb to exit, whether or not the breakpoint was hit, without 
> giving the user a chance to get a backtrace.  I tried adding
> 
>    -x $(lisp)/commands.txt
> 
> where commands.txt contains
> 
>    commands
>    bt
>    end
> 
> but that didn't work.  gdb still exited (with an error) when 
> compile-onefile failed, but it didn't print a backtrace first.  There 
> has to be a way to get a backtrace when gdb runs in batch mode.  Do you 
> know how, Eli?

Sorry, I went overboard with --batch-silent, please use --batch
instead.  (--batch-silent prevents the backtrace from showing up.)

As for displaying the backtrace, just add the "bt" command to the
chain, like this:

  emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb --batch --return-child-result -ex 'b abort' -ex run -ex bt -ex cont --args $(EMACS) $(EMACSOPT)

GDB executes the commands given via -ex in order, so think of this as
if you typed the commands whenever GDB shows its prompt.

Note that I also added "continue", to let Emacs exit abnormally after
hitting the breakpoint (or a segfault).  When neither the breakpoint
nor a fatal signal fire, GDB will say "No stack." when Emacs exits
normally, but that's harmless.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

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

On 6/18/2013 11:53 AM, Eli Zaretskii wrote:
> As for displaying the backtrace, just add the "bt" command to the
> chain, like this:
>
>    emacsdbg = EMACSLOADPATH=$(lisp) LC_ALL=C gdb --batch --return-child-result -ex 'b abort' -ex run -ex bt -ex cont --args $(EMACS) $(EMACSOPT)
>
> GDB executes the commands given via -ex in order, so think of this as
> if you typed the commands whenever GDB shows its prompt.

Thanks, Eli.  I replaced "bt" by "thread apply all bt", which probably 
didn't provide additional useful information.  I then ran "make 
bootstrap" followed by repeated "make -k" until the bootstrap completed. 
  Early in the process there were two crashes with SIGSEGV, for which I 
got backtraces (attached).  In both cases the crash occurred in 
gmalloc.c, which probably explains why we're seeing problems only on Cygwin.

After that there were many compile failures with errors like those that 
others have reported:

Compiling gnus/gnus-cache.el
GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Makefile:254: recipe for target `gnus/gnus-cache.elc' failed

But these compilations didn't invoke gdb, apparently because they 
involved Makefile targets other than compile-onefile.  So I didn't get 
any more backtraces.

I can modify the Makefile further if necessary, but the attached 
backtraces are a start.

Ken

[-- Attachment #2: backtrace5.txt --]
[-- Type: text/plain, Size: 33194 bytes --]

Converting CTLau-b5.html to CTLau-b5.el...
[New Thread 6580.0x197c]
[New Thread 6580.0x804]
[New Thread 6580.0x18d4]

Program received signal SIGSEGV, Segmentation fault.
0x005eb763 in _malloc_internal_nolock (size=0) at gmalloc.c:742
742		  next->prev->next = next->next;

Thread 6 (Thread 6580.0x18d4):
#0  0x7779f8b1 in ntdll!ZwWaitForSingleObject () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7779f8b1 in ntdll!ZwWaitForSingleObject () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x7707149d in WaitForSingleObjectEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000314 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 5 (Thread 6580.0x804):
#0  0x7779fd71 in ntdll!ZwDelayExecution () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7779fd71 in ntdll!ZwDelayExecution () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x77073bc8 in SleepEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 6580.0x197c):
#0  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x770715e9 in WaitForMultipleObjectsEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000003 in ?? ()
No symbol table info available.
#4  0xfff5c898 in ?? ()
No symbol table info available.
#5  0x75481a2c in WaitForMultipleObjectsEx () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#6  0x75484220 in WaitForMultipleObjects () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#7  0x610d4433 in select_stuff::wait (this=0xfff5cb68, readfds=0xfff5cb00, writefds=0xfff5cae0, exceptfds=0xfff5cac0, ms=4294967295) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:385
        s = 0x0
        m = 3
        __PRETTY_FUNCTION__ = "select_stuff::wait_states select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, DWORD)"
        w4 = {0x304, 0x2fc, 0x320, 0x5ecee1 <calloc+59>, 0x8002ee70, 0x0, 0xc, 0x8004dc00, 0x75484220 <WaitForMultipleObjects+24>, 0x3, 0xfff5c9d8, 0xfff5cb68, 0x1, 0xc, 0xfff5ca08, 0x61085bad <calloc(size_t, size_t)+45>, 0x1, 0xc, 0x0, 0x0, 0x75481194 <WaitForSingleObjectEx+67>, 0x1, 0xfff5ca08, 0x5ecee1 <calloc+59>, 0xfff5cb68, 0x6127a828, 0x0, 0x61003429 <operator new(unsigned int)+25>, 0x1, 0xc, 0x0, 0x3, 0x1, 0x2c, 0xfff5ca28, 0x610d539c <fhandler_pipe::select_read(select_stuff*)+76>, 0xc, 0x2c, 0x8c282d90, 0x2e4, 0x3, 0x3, 0xfff5ca98, 0x6102c779 <dtable::select_read(int, select_stuff*)+105>, 0x6127a828, 0xfff5cb68, 0x0, 0x61003429 <operator new(unsigned int)+25>, 0x1, 0x2c, 0x0, 0x6103a0ef <fhandler_base_overlapped::wait_overlapped(bool, bool, unsigned long*, bool, unsigned long)@24+479>, 0x2e4, 0x8004dc00, 0x3, 0x610d40f1 <select_stuff::test_and_set(int, _types_fd_set*, _types_fd_set*, _types_fd_set*)+305>, 0x61274c14, 0x3, 0xfff5cb68, 0x8c282d2a, 0xfff5cc8c, 0x2dc, 0xfff5cc90, 0xfff5cb68}
        startfds = <optimized out>
        wait_ret = <optimized out>
        res = <optimized out>
#8  0x610d4b6f in select (maxfds=4, readfds=0xfff5cc90, writefds=0xfff5cc70, exceptfds=0xfff5cc50, ms=4294967295) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:186
Converting CTLau-b5.html to CTLau-b5.el...done
        start_time = <optimized out>
        w = 0xfff5cae0
        e = 0xfff5cac0
        __PRETTY_FUNCTION__ = "int select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, DWORD)"
        res = <optimized out>
        sel = {return_on_signal = false, always_ready = false, windows_used = falseConverting cangjie-table.cns to tsang-cns.el...
, start = {fd = 1628363602, h = 0xfff5cbb0, fh = 0x7707149d <WaitForSingleObjectEx+152>, thread_errno = -668728, windows_handle = 39, read_ready = 252, write_ready = 15, except_ready = 97, read_selected = 208, write_selected = 20, except_selected = 7, except_on_write = 119, startup = 0x8c282c1c, peek = 0xfff5cbd8, verify = 0x610ffc27 <pthread_mutex::unlock()+23>, cleanup = 0x611a2600 <lock_process::locker>, next = 0x8004dc00}, device_specific_pipe = 0x8002ee70, device_specific_socket = 0x0, device_specific_serial = 0x0, device_specific_mailslot = 0x0}
        r = 0xfff5cb00
#9  0x610d501f in cygwin_select (maxfds=4, readfds=0xfff5cc90, writefds=0xfff5cc70, exceptfds=0xfff5cc50, to=0x0) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:122
        ms = <optimized out>
        __PRETTY_FUNCTION__ = "int cygwin_select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, timeval*)"
        res = <optimized out>
#10 0x610b5b37 in poll (fds=0x80041c38, nfds=1, timeout=-1) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/poll.cc:85
        invalid_fds = <optimized out>
        read_fds = 0xfff5cc90
        write_fds = 0xfff5cc70
        tv = {tv_sec = 0, tv_usec = -1000}
        ret = <optimized out>
        max_fd = <optimized out>
        except_fds = 0xfff5cc50
        fds_size = <optimized out>
#11 0x610d9285 in _sigfe () from /usr/bin/cygwin1.dll
No symbol table info available.
#12 0xffffffff in ?? ()
No symbol table info available.
#13 0x80041c38 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 6580.0x1a20):
#0  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x777d2f51 in ntdll!RtlMoveMemory () from /c/windows/system32/ntdll.dll
No symbol table info available.
#3  0x00000001 in ?? ()
No symbol table info available.
#4  0x00000001 in ?? ()
No symbol table info available.
#5  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 6580.0x1be0):
#0  0x7779f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7779f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x7706dd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000090 in ?? ()
No symbol table info available.
#4  0x75483f07 in ReadFile () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#5  0x00000090 in ?? ()
No symbol table info available.
#6  0x610de6be in wait_sig () at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/sigproc.cc:1229
        nb = 0
        q = <optimized out>
        pack = {si = {si_signo = 0, si_code = 0, si_pid = 0, si_uid = 0, si_errno = 0, {__pad = {0 <repeats 32 times>}, _si_commune = {_si_code = 0, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {_si_fd = 0, _si_pipe_fhandler = 0x0, _si_str = 0x0}}, {{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0, sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0, si_stime = 0}, si_addr = 0x0, {__pad2 = {0 <repeats 31 times>}, si_cyg = 0x0}}}, pid = 0, sigtls = 0x0, mask = 0x0, {wakeup = 0x0, thread_handle = 0x0, next = 0x0}}
        dummy_mask = 0
        clearwait = <optimized out>
        sig_held = false
        __PRETTY_FUNCTION__ = "void wait_sig(void*)"
#7  0x61004a05 in cygthread::callfunc(bool)@8 (this=0x6118d880 <threads>, issimplestub=<optimized out>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:51
        pass_arg = 0x6118d880 <threads>
#8  0x61004f8f in cygthread::stub(void*)@4 (arg=0x6118d880 <threads>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:93
        notify = <optimized out>
        info = 0x6118d880 <threads>
        __PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#9  0x61005d1d in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*)@16 (this=<optimized out>, func=0x61004f40 <cygthread::stub(void*)@4>, arg=0x6118d880 <threads>, buf=0x61005ebb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#10 0x0358ff88 in ?? ()
No symbol table info available.
#11 0x754833aa in KERNEL32!BaseThreadInitThunk () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#12 0x777b9ef2 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#13 0x777b9ec5 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 6580.0x169c):
#0  0x005eb763 in _malloc_internal_nolock (size=0) at gmalloc.c:742
        log = 6
        result = 0x8004dd80
        block = 2656648
        blocks = 2656672
        lastblocks = 8689666
        start = 2
        i = 91
        next = 0x8004dd80
#1  0x005eca83 in special_realloc (ptr=0x110ae40 <bss_sbrk_buffer+9374464>, size=48) at gmalloc.c:1308
        result = 0x815ebc <o_fwd.60737>
        type = 5
        block = 2288
        oldsize = 32
#2  0x005ecb12 in _realloc_internal_nolock (ptr=0x110ae40 <bss_sbrk_buffer+9374464>, size=48) at gmalloc.c:1342
        result = 0x16
        type = 2657312
        block = 2656600
        blocks = 8666397
        oldlimit = 5562602
#3  0x005ece41 in _realloc_internal (ptr=0x110ae40 <bss_sbrk_buffer+9374464>, size=48) at gmalloc.c:1452
        result = 0x54e83d <CHAR_TABLE_P+25>
#4  0x005ecea4 in realloc (ptr=0x110ae40 <bss_sbrk_buffer+9374464>, size=48) at gmalloc.c:1467
        hook = 0x0
#5  0x0054f2ba in xrealloc (block=0x110ae40 <bss_sbrk_buffer+9374464>, size=48) at alloc.c:683
        val = 0xe4
#6  0x0053f16e in regex_compile (pattern=0x8005c1dc "\\`\\(?:.*8859[-_]?9\\>\\)", size=22, syntax=3408388, bufp=0x813480 <searchbufs+640>) at regex.c:2789
        old_buffer = 0x110ae40 <bss_sbrk_buffer+9374464> "\v\022\004"
        p1 = 0x54df7f <SCHARS+17> "\213"
        c = 91
        c1 = 57
        b = 0x110ae4e <bss_sbrk_buffer+9374478> "lic\001mode\f\001\002"
        compile_stack = {stack = 0x80059800, size = 32, avail = 1}
        p = 0x8005c1e9 "-_]?9\\>\\)"
        pend = 0x8005c1f2 ""
        translate = 8665885
        pending_exact = 0x110ae49 <bss_sbrk_buffer+9374473> "\004\070\070\065\071lic\001mode\f\001\002"
        laststart = 0x110ae48 <bss_sbrk_buffer+9374472> "\002\004\070\070\065\071lic\001mode\f\001\002"
        begalt = 0x110ae41 <bss_sbrk_buffer+9374465> "\022\004"
        beg_interval = 0xf915de <bss_sbrk_buffer+7828126> "\371"
        fixup_alt_jump = 0x0
        range_table_work = {table = 0x0, allocated = 0, used = 0, bits = 0}
        multibyte = 0 '\000'
        in_subpattern = 0
        main_p = 0x8005b141 ""
        main_pattern = 0x8005b140 "c"
        main_pend = 0x8005b141 ""
#7  0x0054d0e6 in re_compile_pattern (pattern=0x8005c1dc "\\`\\(?:.*8859[-_]?9\\>\\)", length=22, bufp=0x813480 <searchbufs+640>) at regex.c:6324
        ret = 2657528
#8  0x0053644a in compile_pattern_1 (cp=0x813470 <searchbufs+624>, pattern=18197681, translate=8665885, posix=false) at search.c:150
        val = 0x0
        old = 0
#9  0x005366a0 in compile_pattern (pattern=18197681, regp=0x0, translate=8665885, posix=false, multibyte=false) at search.c:245
        cp = 0x813470 <searchbufs+624>
        cpp = 0x8136e0 <searchbufs+1248>
#10 0x00536c90 in string_match_1 (regexp=18197681, string=17441953, start=8619034, posix=false) at search.c:402
        val = -1
        bufp = 0x8135b8 <searchbufs+952>
        pos = 0
        pos_byte = 0
        i = 8478396
#11 0x00536e24 in Fstring_match (regexp=18197681, string=17441953, start=8619034) at search.c:452
No locals.
#12 0x0056d874 in eval_sub (form=9666190) at eval.c:2166
        numargs = 12
        args_left = 8619034
        i = 5467645
        maxargs = 3
        argvals = {18197681, 17441953, 8619034, 5692401, 11223552, 1, -1, 5600938}
        fun = 6373653
        val = 8473252
        original_fun = 8980698
        original_args = 9666198
        funcar = 8473252
        gcpro1 = {next = 0x288ea8, var = 0x288ea8, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x54e708 <BUFFER_OBJFWDP+17>, nvars = 8473252}
        gcpro3 = {next = 0x890892 <bss_sbrk_buffer+484690>, var = 0x288e60, nvars = 3}
#13 0x0056ae7b in Fprogn (args=9666222) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8980624}
#14 0x0056b9e6 in Flet (args=9666182) at eval.c:918
        temps = 0x288f40
        tem = 8619058
        lexenv = 16534534
        elt = 9666158
        varlist = 8619034
        count = 31
        argnum = 1
        gcpro1 = {next = 0x8e90da <bss_sbrk_buffer+847258>, var = 0x8cb4ce <bss_sbrk_buffer+725390>, nvars = 2658184}
        gcpro2 = {next = 0x288f70, var = 0x288f98, nvars = 1}
        sa_count = 31
        sa_must_free = false
#15 0x0056d59d in eval_sub (form=9666150) at eval.c:2108
        numargs = 8
        args_left = 9666182
        i = 2
        maxargs = 2658624
        argvals = {8478396, 2660500, 2658344, 8695744, 3, 2658384, 2658376, 5600859}
        fun = 8087325
        val = 8478396
        original_fun = 8961866
        original_args = 9666182
        funcar = 8478396
        gcpro1 = {next = 0x289048, var = 0x289048, nvars = 5564168}
        gcpro2 = {next = 0x56dbf1 <eval_sub+2201>, var = 0xab41e0 <bss_sbrk_buffer+2727584>, nvars = 2658384}
        gcpro3 = {next = 0x84afc2 <bss_sbrk_buffer+199810>, var = 0x289894, nvars = 2658600}
#16 0x0056ae7b in Fprogn (args=9661662) at eval.c:459
        val = 9639649
        gcpro1 = {next = 0x289050, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8961528}
#17 0x0056f1ce in funcall_lambda (fun=9661830, nargs=2, arg_vector=0x289140) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 8979010
        lexenv = 16534534
        count = 29
        i = 2
        optional = true
        rest = false
#18 0x0056edbd in apply_lambda (fun=9661838, args=13970950) at eval.c:2899
        args_left = 8619034
        i = 2
        numargs = 2
        arg_vector = 0x289140
        gcpro1 = {next = 0x0, var = 0x1, nvars = 2}
        gcpro2 = {next = 0xd525f6 <bss_sbrk_buffer+5472950>, var = 0x7b57d0 <Scdr>, nvars = 2658696}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x289188, nvars = 5596975}
        tem = 17441953
        sa_count = 29
        sa_must_free = false
#19 0x0056dbba in eval_sub (form=13971022) at eval.c:2235
        fun = 9661838
        val = 2658952
        original_fun = 9618986
        original_args = 13970950
        funcar = 8961290
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x4, nvars = 8688858}
        gcpro2 = {next = 0x56ae00 <Fcond+31>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 16323854}
        gcpro3 = {next = 0x1, var = 0xd52d9e <bss_sbrk_buffer+5474910>, nvars = 2658888}
#20 0x0056ad98 in Fif (args=13970934) at eval.c:405
        cond = 2
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2892b8, nvars = 2}
#21 0x0056d59d in eval_sub (form=13971030) at eval.c:2108
        numargs = 8
        args_left = 13970934
        i = 2
        maxargs = 8619034
        argvals = {9367650, 2, 2659304, 5692401, 11223488, 2659220, -1, 13732294}
        fun = 8087013
        val = 13968870
        original_fun = 8961626
        original_args = 13970934
        funcar = 5561891
        gcpro1 = {next = 0x2893a8, var = 0x56dfe0 <Fapply+927>, nvars = 3}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x8ef062 <bss_sbrk_buffer+871714>, nvars = 2659600}
        gcpro3 = {next = 0x90b10e <bss_sbrk_buffer+986574>, var = 0xc, nvars = 2659336}
#22 0x0056ae7b in Fprogn (args=13970878) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x2893c4, var = 0x2893e8, nvars = 3}
#23 0x0056ba84 in Fwhile (args=13971062) at eval.c:940
        test = 13971118
        body = 13970878
        gcpro1 = {next = 0x55672f <Fcdr+17>, var = 0xd189c6 <bss_sbrk_buffer+5236358>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2659336}
#24 0x0056d59d in eval_sub (form=13971126) at eval.c:2108
        numargs = 12
        args_left = 13971062
        i = 3
        maxargs = 8619034
        argvals = {13732294, 17082625, 2659640, 1, 14123313, 8619034, 20, 8619034}
        fun = 8087349
        val = 2659608
        original_fun = 8961914
        original_args = 13971062
        funcar = 14128418
        gcpro1 = {next = 0x2, var = 0x8, nvars = 8963506}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0xd79552 <bss_sbrk_buffer+5632530>, nvars = 2659424}
        gcpro3 = {next = 0x0, var = 0x289450, nvars = 1}
#25 0x0056ae7b in Fprogn (args=13970822) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x289538, nvars = 9367648}
#26 0x0056b9e6 in Flet (args=13971134) at eval.c:918
        temps = 0x289530
        tem = 8619034
        lexenv = 8619034
        elt = 9367650
        varlist = 8619034
        count = 25
        argnum = 1
        gcpro1 = {next = 0xab4190 <bss_sbrk_buffer+2727504>, var = 0x1, nvars = 2659704}
        gcpro2 = {next = 0x1, var = 0x289638, nvars = 1}
        sa_count = 25
        sa_must_free = false
#27 0x0056d59d in eval_sub (form=13971166) at eval.c:2108
        numargs = 12
        args_left = 13971134
        i = 3
        maxargs = 2660144
        argvals = {5562239, 17082625, 2659880, 14130040, 1, 12, 2659896, 5600859}
        fun = 8087325
        val = 2660024
        original_fun = 8961866
        original_args = 13971134
        funcar = 14130042
        gcpro1 = {next = 0x289718, var = 0xd52626 <bss_sbrk_buffer+5472998>, nvars = 17082625}
        gcpro2 = {next = 0x289628, var = 0x54ed72 <string_intervals+17>, nvars = 17082625}
        gcpro3 = {next = 0xd79b7a <bss_sbrk_buffer+5634106>, var = 0x104a901 <bss_sbrk_buffer+8586689>, nvars = 2659912}
#28 0x0056ae7b in Fprogn (args=13970662) at eval.c:459
        val = 14114753
        gcpro1 = {next = 0xe, var = 0x1, nvars = 9343192}
#29 0x0056f1ce in funcall_lambda (fun=13970574, nargs=2, arg_vector=0x289730) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 9343194
        lexenv = 8619034
        count = 22
        i = 2
        optional = false
        rest = false
#30 0x0056edbd in apply_lambda (fun=13970574, args=14151606) at eval.c:2899
        args_left = 8619034
        i = 2
        numargs = 2
        arg_vector = 0x289730
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0xd7f516 <bss_sbrk_buffer+5657046>, nvars = 2}
        gcpro2 = {next = 0x16, var = 0x4a901, nvars = 2}
        gcpro3 = {next = 0x0, var = 0x63, nvars = 2}
        tem = 13968934
        sa_count = 22
        sa_must_free = false
#31 0x0056dbba in eval_sub (form=14151614) at eval.c:2235
        fun = 13970574
        val = 2660472
        original_fun = 14128226
        original_args = 14151606
        funcar = 8689666
        gcpro1 = {next = 0x289848, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 17082625}
        gcpro2 = {next = 0x56f777 <unbind_to+167>, var = 0xab4160 <bss_sbrk_buffer+2727456>, nvars = 12}
        gcpro3 = {next = 0xab4160 <bss_sbrk_buffer+2727456>, var = 0xd7f4b6 <bss_sbrk_buffer+5656950>, nvars = 2660440}
#32 0x0056b8b4 in Flet (args=14200638) at eval.c:888
        temps = 0x289890
        tem = 5564423
        lexenv = 2660808
        elt = 14151622
        varlist = 14020214
        count = 21
        argnum = 1
        gcpro1 = {next = 0xd7f40e <bss_sbrk_buffer+5656782>, var = 0x10a24a1 <bss_sbrk_buffer+8946017>, nvars = 2660568}
        gcpro2 = {next = 0x289c50, var = 0x289908, nvars = 1}
        sa_count = 21
        sa_must_free = false
#33 0x0056d59d in eval_sub (form=14200694) at eval.c:2108
        numargs = 20
        args_left = 14200638
        i = 5
        maxargs = 8619034
        argvals = {14154174, 8619034, 2660840, 5683733, 20, 8619034, 2660792, 1}
        fun = 8087325
        val = 17441953
        original_fun = 8961866
        original_args = 14200638
        funcar = 14154398
        gcpro1 = {next = 0x2899b8, var = 0x8, nvars = 8961866}
        gcpro2 = {next = 0x56b784 <Flet+89>, var = 0xd7f9be <bss_sbrk_buffer+5658238>, nvars = 2660756}
        gcpro3 = {next = 0xd7f9ee <bss_sbrk_buffer+5658286>, var = 0xd7f4e6 <bss_sbrk_buffer+5656998>, nvars = 320}
#34 0x0056ae7b in Fprogn (args=14200718) at eval.c:459
        val = 17441953
        gcpro1 = {next = 0x7b6610 <Sprogn>, var = 0x289a18, nvars = 2}
#35 0x0056d59d in eval_sub (form=14200702) at eval.c:2108
        numargs = 8
        args_left = 14200710
        i = 2
        maxargs = 8619034
        argvals = {8963506, 2660928, 1, 5602828, 8612864, 14073094, 2661064, 5699447}
        fun = 8087061
        val = 2661112
        original_fun = 8961674
        original_args = 14200710
        funcar = 9485870
        gcpro1 = {next = 0x289ac8, var = 0x8, nvars = 8961578}
        gcpro2 = {next = 0x0, var = 0x88bf4a <bss_sbrk_buffer+465930>, nvars = 2661088}
        gcpro3 = {next = 0xab4130 <bss_sbrk_buffer+2727408>, var = 0xd7f536 <bss_sbrk_buffer+5657078>, nvars = 4}
#36 0x0056adbe in Fif (args=14200734) at eval.c:409
        cond = 17082625
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x289b28, nvars = 2}
#37 0x0056d59d in eval_sub (form=14200726) at eval.c:2108
        numargs = 8
        args_left = 14200734
        i = 2
        maxargs = 8619034
        argvals = {8619034, 1, 8619034, 2661152, 8619034, 8087320, 2661272, 3}
        fun = 8087013
        val = 17082625
        original_fun = 8961626
        original_args = 14200734
        funcar = 8961530
        gcpro1 = {next = 0xffffffff, var = 0x88bdf8 <bss_sbrk_buffer+465592>, nvars = 2664536}
        gcpro2 = {next = 0x56dbf1 <eval_sub+2201>, var = 0xab4120 <bss_sbrk_buffer+2727392>, nvars = 2661412}
        gcpro3 = {next = 0x289e50, var = 0x28a2d0, nvars = 2661496}
#38 0x0056ae7b in Fprogn (args=14200758) at eval.c:459
        val = 17082625
        gcpro1 = {next = 0xc, var = 0x289c58, nvars = 14128392}
#39 0x0056b9e6 in Flet (args=10765726) at eval.c:918
        temps = 0x289c50
        tem = 8619034
        lexenv = 8619034
        elt = 14154286
        varlist = 8619034
        count = 17
        argnum = 1
        gcpro1 = {next = 0xd7fa46 <bss_sbrk_buffer+5658374>, var = 0xd75601 <bss_sbrk_buffer+5616321>, nvars = 2661528}
        gcpro2 = {next = 0x28a2d0, var = 0x289cc8, nvars = 1}
        sa_count = 17
        sa_must_free = false
#40 0x0056d59d in eval_sub (form=10863254) at eval.c:2108
        numargs = 32
        args_left = 10765726
        i = 8
        maxargs = 2661968
        argvals = {8478396, 9417345, 8619034, 8619032, 9397409, 8702746, 2661720, 5600859}
        fun = 8087325
        val = 14112257
        original_fun = 8961866
        original_args = 10765726
        funcar = 8478396
        gcpro1 = {next = 0x289d58, var = 0x289d58, nvars = 5564168}
        gcpro2 = {next = 0x5740b9 <Fassq+272>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 12}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x8fb281 <bss_sbrk_buffer+921409>, nvars = 2661720}
#41 0x0056ae7b in Fprogn (args=10862974) at eval.c:459
        val = 14112257
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0xa80c06 <bss_sbrk_buffer+2517190>, nvars = 8961528}
#42 0x0056f1ce in funcall_lambda (fun=10863246, nargs=1, arg_vector=0x289e50) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 8689362
        lexenv = 8619034
        count = 13
        i = 1
        optional = true
        rest = false
#43 0x0056edbd in apply_lambda (fun=10863246, args=11013926) at eval.c:2899
        args_left = 8619034
        i = 1
        numargs = 1
        arg_vector = 0x289e50
        gcpro1 = {next = 0x56ae36 <Fcond+85>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 1}
        gcpro2 = {next = 0xa80ed6 <bss_sbrk_buffer+2517910>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 2662072}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x289e88, nvars = 8619034}
        tem = 8619034
        sa_count = 13
        sa_must_free = false
#44 0x0056dbba in eval_sub (form=11013918) at eval.c:2235
        fun = 10863246
        val = 9417345
        original_fun = 10783202
        original_args = 11013926
        funcar = 8689666
        gcpro1 = {next = 0x289f48, var = 0x289f48, nvars = 5564168}
        gcpro2 = {next = 0x289ed0, var = 0x84afda <bss_sbrk_buffer+199834>, nvars = 8087320}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x1, nvars = 8619034}
#45 0x0056ae7b in Fprogn (args=10737566) at eval.c:459
        val = 9417345
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0xf941ce <bss_sbrk_buffer+7839374>, nvars = 8961528}
#46 0x0056f1ce in funcall_lambda (fun=10939654, nargs=0, arg_vector=0x28a040) at eval.c:3017
        val = 5706672
        syms_left = 8619034
        next = 8478396
        lexenv = 11013126
        count = 11
        i = 0
        optional = false
        rest = false
#47 0x0056edbd in apply_lambda (fun=10939662, args=8619034) at eval.c:2899
        args_left = 8619034
        i = 0
        numargs = 0
        arg_vector = 0x28a040
        gcpro1 = {next = 0x836e00 <bss_sbrk_buffer+117440>, var = 0x815ebc <o_fwd.60737>, nvars = 0}
        gcpro2 = {next = 0x812cdc <bo_fwd.18329>, var = 0x28a2d0, nvars = 8478396}
        gcpro3 = {next = 0x28a1b0, var = 0x28a088, nvars = 5600768}
        tem = 7
        sa_count = 11
        sa_must_free = false
#48 0x0056dbba in eval_sub (form=11136198) at eval.c:2235
        fun = 10939662
        val = 2662776
        original_fun = 11282746
        original_args = 8619034
        funcar = 8961290
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x1, nvars = 8689362}
        gcpro2 = {next = 0x56ae7b <Fprogn+31>, var = 0xa2f03e <bss_sbrk_buffer+2182398>, nvars = 8619034}
        gcpro3 = {next = 0x28a1b0, var = 0x1, nvars = 2662712}
#49 0x0056be0a in Funwind_protect (args=10768462) at eval.c:1150
        val = 2662824
        count = 9
#50 0x0056d59d in eval_sub (form=10768470) at eval.c:2108
        numargs = 28
        args_left = 10768462
        i = 7
        maxargs = 8619034
        argvals = {8478396, 8962386, 2662968, 5694505, 2, 2662936, 1, 8619034}
        fun = 8087445
        val = 8478396
        original_fun = 8962010
        original_args = 10768462
        funcar = 8478396
        gcpro1 = {next = 0x28a238, var = 0x28a238, nvars = 5564168}
        gcpro2 = {next = 0x104ab51 <bss_sbrk_buffer+8587281>, var = 0xab4080 <bss_sbrk_buffer+2727232>, nvars = 11136270}
        gcpro3 = {next = 0xa9ed1e <bss_sbrk_buffer+2640350>, var = 0x28a610, nvars = 8690434}
#51 0x0056ae7b in Fprogn (args=11168886) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xa557a6 <bss_sbrk_buffer+2339942>, nvars = 8961528}
#52 0x0056b9e6 in Flet (args=11168822) at eval.c:918
        temps = 0x28a2d0
        tem = 17606710
        lexenv = 16335310
        elt = 11136238
        varlist = 8619034
        count = 7
        argnum = 1
        gcpro1 = {next = 0xa9ed06 <bss_sbrk_buffer+2640326>, var = 0x104ab51 <bss_sbrk_buffer+8587281>, nvars = 2663192}
        gcpro2 = {next = 0x1, var = 0x28a348, nvars = 1}
        sa_count = 7
        sa_must_free = false
#53 0x0056d59d in eval_sub (form=11091870) at eval.c:2108
        numargs = 8
        args_left = 11168822
        i = 2
        maxargs = 2663952
        argvals = {8968674, 9725026, 13864070, 2663792, 0, 32047104, 3670069, 2949168}
        fun = 8087325
        val = 17083217
        original_fun = 8961866
        original_args = 11168822
        funcar = 32047104
        gcpro1 = {next = 0x0, var = 0x28a3fc, nvars = 2005206902}
        gcpro2 = {next = 0x4, var = 0x1e90000, nvars = 32172440}
        gcpro3 = {next = 0x690070 <pure+507280>, var = 0x28a390, nvars = 3}
#54 0x0056ae7b in Fprogn (args=11091830) at eval.c:459
        val = 17083217
        gcpro1 = {next = 0x850fde <bss_sbrk_buffer+224414>, var = 0x28a458, nvars = 11}
#55 0x0056addb in Fif (args=11222926) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x28a488, nvars = 11}
#56 0x0056d59d in eval_sub (form=11222934) at eval.c:2108
        numargs = 44
        args_left = 11222926
        i = 11
        maxargs = 2663952
        argvals = {8478396, 2664848, 2663572, 4, 2664096, 2004840917, 397963447, 1996909470}
        fun = 8087013
        val = 8478396
        original_fun = 8961626
        original_args = 11222926
        funcar = 8478396
        gcpro1 = {next = 0x28a518, var = 0x28a518, nvars = 5564168}
        gcpro2 = {next = 0x18d4, var = 0x28a6b0, nvars = 2004484189}
        gcpro3 = {next = 0x7707ef9d <KERNELBASE!CheckTokenMembership+2167>, var = 0x31c, nvars = 6580}
#57 0x0056ae7b in Fprogn (args=10953926) at eval.c:459
        val = 9129921
        gcpro1 = {next = 0x10003, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8961528}
#58 0x0056f1ce in funcall_lambda (fun=10953766, nargs=0, arg_vector=0x28a610) at eval.c:3017
        val = 5706672
        syms_left = 8619034
        next = 2664304
        lexenv = 10835878
        count = 4
        i = 0
        optional = false
        rest = false
#59 0x0056edbd in apply_lambda (fun=10953758, args=8619034) at eval.c:2899
        args_left = 8619034
        i = 0
        numargs = 0
        arg_vector = 0x28a610
        gcpro1 = {next = 0x5ecee1 <calloc+59>, var = 0x8004dd40, nvars = 0}
        gcpro2 = {next = 0x1eaca00, var = 0x1, nvars = 2664040}
        gcpro3 = {next = 0xffe5f000, var = 0x0, nvars = 0}
        tem = 2665344
        sa_count = 4
        sa_must_free = false
#60 0x0056dbba in eval_sub (form=9944750) at eval.c:2235
        fun = 10953758
        val = 8619034
        original_fun = 11281130
        original_args = 8619034
        funcar = 8961290
        gcpro1 = {next = 0x28a718, var = 0x836e01 <bss_sbrk_buffer+117441>, nvars = 5}
        gcpro2 = {next = 0x61004d43 <cygthread::create()@4+403>, var = 0x28ab80, nvars = 0}
        gcpro3 = {next = 0x815ebc <o_fwd.60737>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8613376}
#61 0x0056d202 in Feval (form=9944750, lexical=8619034) at eval.c:1993
        count = 2
#62 0x004f03b7 in top_level_2 () at keyboard.c:1173
No locals.
#63 0x0056c136 in internal_condition_case (bfun=0x4f039a <top_level_2>, handlers=8689762, hfun=0x4effff <cmd_error>) at eval.c:1289
        val = 0
        c = {tag = 8619034, val = 8619034, next = 0x28a908, gcpro = 0x0, jmp = {2664404, 2665344, 32, 11223088, 0, 1, 2664648, 2664352, 5685457, 5439531, 2818091, 2686740, 2677272, 2818091, 2686740, 2664796, -2147164704, 2664744, 0, 14, 0, 0, 2664908, -2147171666, 2664500, 2, 1629103712, 0, 1, 2664792, 1628480791, 1629103712, 0, 2664848, 2664832, 2686740, -2147164672, 2664632, 1704608770, -2147171666, 2664564, 1629103712, 0, 0, 0, 1, 2664792, 2664528, 1628480743, 5439531, 2818091, 2686740}, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
        h = {handler = 8689762, var = 8619034, chosen_clause = 2686740, tag = 0x28a7c4, next = 0x0}
#64 0x004f03eb in top_level_1 (ignore=8619034) at keyboard.c:1181
No locals.
#65 0x0056bc9c in internal_catch (tag=8687834, func=0x4f03b9 <top_level_1>, arg=8619034) at eval.c:1063
        c = {tag = 8687834, val = 8619034, next = 0x0, gcpro = 0x0, jmp = {2664728, 2665344, 32, 11223088, 0, 1, 2664968, 2664688, 5684365, 5439531, 2818091, 2686740, 2677272, 0, -2147289248, 0, 2664888, 1628481649, 1629103712, 0, 2664888, 5599614, 8237784, 1, 0, 6214653, 0, 0, 0, 0, 0, 0, 2, 0, -2147283840, 385779400, 2664888, 2664888, 5564168, 11223072, 2664968, 5601931, 8237784, 8619034, 8613376, 5996542, 2665344, 0, 2664968, 8613377, 5, 5}, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
#66 0x004f031f in command_loop () at keyboard.c:1142
No locals.
#67 0x004efc7b in recursive_edit_1 () at keyboard.c:776
        count = 1
        val = 2665112
#68 0x004efdb7 in Frecursive_edit () at keyboard.c:840
        count = 0
        buffer = 8619034
#69 0x004ee375 in main (argc=11, argv=0x28ab80) at emacs.c:1550
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = false
        dumping = false
        skip_args = 2
        rlim = {rlim_cur = 2097082, rlim_max = 2097152}
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x28ab98 ".\254("
[Thread 6580.0x1be0 exited with code 3221225477]
[Thread 6580.0x1a20 exited with code 3221225477]
[Thread 6580.0x18d4 exited with code 3221225477]
[Thread 6580.0x197c exited with code 3221225477]
[Inferior 1 (process 6580) exited with code 030000000005]

[-- Attachment #3: backtrace6.txt --]
[-- Type: text/plain, Size: 122019 bytes --]

Compiling /home/kbrown/src/emacs/test/src/../lisp/mwheel.el
EMACSLOADPATH=/home/kbrown/src/emacs/test/lisp LC_ALL=C gdb --batch --return-child-result -ex 'b abort' -ex run -ex 'thread apply all bt full' -ex cont --args /home/kbrown/src/emacs/test/src/bootstrap-emacs.exe -batch --no-site-file --no-site-lisp    \
	-l bytecomp -f byte-compile-refresh-preloaded \
	-f batch-byte-compile /home/kbrown/src/emacs/test/src/../lisp/mwheel.el
Breakpoint 1 at 0x60f268
[New Thread 6952.0x768]
[New Thread 6952.0x1574]
[New Thread 6952.0x174c]
[New Thread 6952.0x186c]
[New Thread 6952.0x1bd4]
[New Thread 6952.0x18a4]

Program received signal SIGSEGV, Segmentation fault.
0x005eb763 in _malloc_internal_nolock (size=0) at gmalloc.c:742
742		  next->prev->next = next->next;

Thread 6 (Thread 6952.0x18a4):
#0  0x7779f8b1 in ntdll!ZwWaitForSingleObject () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7779f8b1 in ntdll!ZwWaitForSingleObject () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x7707149d in WaitForSingleObjectEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000324 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Thread 5 (Thread 6952.0x1bd4):
#0  0x7779fd71 in ntdll!ZwDelayExecution () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7779fd71 in ntdll!ZwDelayExecution () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x77073bc8 in SleepEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 6952.0x186c):
#0  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x770715e9 in WaitForMultipleObjectsEx () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000003 in ?? ()
No symbol table info available.
#4  0xfff5c898 in ?? ()
No symbol table info available.
#5  0x75481a2c in WaitForMultipleObjectsEx () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#6  0x75484220 in WaitForMultipleObjects () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#7  0x610d4433 in select_stuff::wait (this=0xfff5cb68, readfds=0xfff5cb00, writefds=0xfff5cae0, exceptfds=0xfff5cac0, ms=4294967295) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:385
        s = 0x0
        m = 3
        __PRETTY_FUNCTION__ = "select_stuff::wait_states select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, DWORD)"
        w4 = {0x30c, 0x304, 0x318, 0x5ecee1 <calloc+59>, 0x8002ee50, 0x0, 0xc, 0x8004dc00, 0x75484220 <WaitForMultipleObjects+24>, 0x3, 0xfff5c9d8, 0xfff5cb68, 0x1, 0xc, 0xfff5ca08, 0x61085bad <calloc(size_t, size_t)+45>, 0x1, 0xc, 0x0, 0x0, 0x75481194 <WaitForSingleObjectEx+67>, 0x1, 0xfff5ca08, 0x5ecee1 <calloc+59>, 0xfff5cb68, 0x6127aafc, 0x0, 0x61003429 <operator new(unsigned int)+25>, 0x1, 0xc, 0x0, 0x3, 0x1, 0x2c, 0xfff5ca28, 0x610d539c <fhandler_pipe::select_read(select_stuff*)+76>, 0xc, 0x2c, 0x68dc352a, 0x2ec, 0x3, 0x3, 0xfff5ca98, 0x6102c779 <dtable::select_read(int, select_stuff*)+105>, 0x6127aafc, 0xfff5cb68, 0x0, 0x61003429 <operator new(unsigned int)+25>, 0x1, 0x2c, 0x0, 0x6103a0ef <fhandler_base_overlapped::wait_overlapped(bool, bool, unsigned long*, bool, unsigned long)@24+479>, 0x2ec, 0x8004dc00, 0x3, 0x610d40f1 <select_stuff::test_and_set(int, _types_fd_set*, _types_fd_set*, _types_fd_set*)+305>, 0x61274c14, 0x3, 0xfff5cb68, 0x68dc35f5, 0xfff5cc8c, 0x2e4, 0xfff5cc90, 0xfff5cb68}
        startfds = <optimized out>
        wait_ret = <optimized out>
        res = <optimized out>
#8  0x610d4b6f in select (maxfds=4, readfds=0xfff5cc90, writefds=0xfff5cc70, exceptfds=0xfff5cc50, ms=4294967295) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:186
        start_time = <optimized out>
        w = 0xfff5cae0
        e = 0xfff5cac0
        __PRETTY_FUNCTION__ = "int select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, DWORD)"
        res = <optimized out>
        sel = {return_on_signal = false, always_ready = false, windows_used = false, start = {fd = 1628363602, h = 0xfff5cbb0, fh = 0x0, thread_errno = -668728, windows_handle = 39, read_ready = 252, write_ready = 15, except_ready = 97, read_selected = 2, write_selected = false, except_selected = false, except_on_write = false, startup = 0xfff5cc2c, peek = 0xfff5cbd8, verify = 0x610ffc27 <pthread_mutex::unlock()+23>, cleanup = 0x30c, next = 0x8004dc00}, device_specific_pipe = 0x8002ee50, device_specific_socket = 0x0, device_specific_serial = 0x0, device_specific_mailslot = 0x0}
        r = 0xfff5cb00
#9  0x610d501f in cygwin_select (maxfds=4, readfds=0xfff5cc90, writefds=0xfff5cc70, exceptfds=0xfff5cc50, to=0x0) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:122
        ms = <optimized out>
        __PRETTY_FUNCTION__ = "int cygwin_select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, timeval*)"
        res = <optimized out>
#10 0x610b5b37 in poll (fds=0x80041c80, nfds=1, timeout=-1) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/poll.cc:85
        invalid_fds = <optimized out>
        read_fds = 0xfff5cc90
        write_fds = 0xfff5cc70
        tv = {tv_sec = 0, tv_usec = -1000}
        ret = <optimized out>
        max_fd = <optimized out>
        except_fds = 0xfff5cc50
        fds_size = <optimized out>
#11 0x610d9285 in _sigfe () from /usr/bin/cygwin1.dll
No symbol table info available.
#12 0xffffffff in ?? ()
No symbol table info available.
#13 0x80041c80 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 6952.0x174c):
#0  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x777a013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x777d2f51 in ntdll!RtlMoveMemory () from /c/windows/system32/ntdll.dll
No symbol table info available.
#3  0x00000001 in ?? ()
No symbol table info available.
#4  0x00000001 in ?? ()
No symbol table info available.
#5  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 6952.0x1574):
#0  0x7779f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7779f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x7706dd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000090 in ?? ()
No symbol table info available.
#4  0x75483f07 in ReadFile () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#5  0x00000090 in ?? ()
No symbol table info available.
#6  0x610de6be in wait_sig () at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/sigproc.cc:1229
        nb = 0
        q = <optimized out>
        pack = {si = {si_signo = 0, si_code = 0, si_pid = 0, si_uid = 0, si_errno = 0, {__pad = {0 <repeats 32 times>}, _si_commune = {_si_code = 0, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {_si_fd = 0, _si_pipe_fhandler = 0x0, _si_str = 0x0}}, {{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0, sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0, si_stime = 0}, si_addr = 0x0, {__pad2 = {0 <repeats 31 times>}, si_cyg = 0x0}}}, pid = 0, sigtls = 0x0, mask = 0x0, {wakeup = 0x0, thread_handle = 0x0, next = 0x0}}
        dummy_mask = 0
        clearwait = <optimized out>
        sig_held = false
        __PRETTY_FUNCTION__ = "void wait_sig(void*)"
#7  0x61004a05 in cygthread::callfunc(bool)@8 (this=0x6118d880 <threads>, issimplestub=<optimized out>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:51
        pass_arg = 0x6118d880 <threads>
#8  0x61004f8f in cygthread::stub(void*)@4 (arg=0x6118d880 <threads>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:93
        notify = <optimized out>
        info = 0x6118d880 <threads>
        __PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#9  0x61005d1d in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*)@16 (this=<optimized out>, func=0x61004f40 <cygthread::stub(void*)@4>, arg=0x6118d880 <threads>, buf=0x61005ebb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#10 0x0384ff88 in ?? ()
No symbol table info available.
#11 0x754833aa in KERNEL32!BaseThreadInitThunk () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#12 0x777b9ef2 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#13 0x777b9ec5 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 6952.0x768):
#0  0x005eb763 in _malloc_internal_nolock (size=0) at gmalloc.c:742
        log = 4
        result = 0x8002ee50
        block = 0
        blocks = 2
        lastblocks = 8619034
        start = 4199230
        i = 13922246
        next = 0x8002ee50
#1  0x005ecdc7 in _realloc_internal_nolock (ptr=0x80041c88, size=15) at gmalloc.c:1432
        result = 0x56dbf1 <eval_sub+2201>
        type = 3
        block = 66
        blocks = 65536
        oldlimit = 6205623
#2  0x005ece41 in _realloc_internal (ptr=0x80041c88, size=15) at gmalloc.c:1452
        result = 0x55765b <Fsymbol_value+17>
#3  0x005ecea4 in realloc (ptr=0x80041c88, size=15) at gmalloc.c:1467
        hook = 0x0
#4  0x0054f2ba in xrealloc (block=0x80041c88, size=15) at alloc.c:683
        val = 0x8005a000
#5  0x004729ee in coding_alloc_by_realloc (coding=0x28147c, bytes=10) at coding.c:1041
No locals.
#6  0x00472c9c in alloc_destination (coding=0x28147c, nbytes=10, dst=0x80041c88 "0\034\004\200x\244Q\001") at coding.c:1082
        offset = 0
#7  0x00485c19 in encode_coding_charset (coding=0x28147c) at coding.c:5613
        more_bytes = 10
        charset = 0x55199c <make_save_pointer+32>
        code = 8616731
        multibytep = false
        charbuf = 0x8005a000
        charbuf_end = 0x8005a014
        dst = 0x80041c88 "0\034\004\200x\244Q\001"
        dst_end = 0x80041c8d "\244Q\001"
        safe_room = 5
        produced_chars = 0
        attrs = 10282613
        charset_list = 10025566
        ascii_compatible = true
        c = 4663311
#8  0x0048b6ae in encode_coding (coding=0x28147c) at coding.c:7700
        attrs = 10282613
        translation_table = 8619034
        max_lookup = 1
        cclspec = {ccl = {idx = 2626360, size = 6209282, prog = 0x0, ic = 11398870, eof_ic = 1, reg = {2626344, 5561891, 14072270, 2626392, -2147214200, 14072270, 8619034, 2626408}, private_state = 6209374, last_block = 5, status = 5, buf_magnification = 1, stack_idx = 5699447, src_multibyte = 11226608, dst_multibyte = 17, cr_consumed = 2626456, consumed = 0, produced = 4765755, suppress_error = 14072270, eight_bit_control = 2626456, quit_silently = 5566967}, cr_carryover = 5, eight_bit_carryover = "\002\000\000\000"}
        sa_count = 219
        sa_must_free = true
#9  0x0048cef7 in encode_coding_object (coding=0x28147c, src_object=16849873, from=0, from_byte=0, to=5, to_byte=5, dst_object=8619058) at coding.c:8269
        count = 218
        chars = 5
        bytes = 5
        attrs = 10282613
        saved_pt = -1
        saved_pt_byte = 2557210
        need_marker_adjustment = false
        kill_src_buffer = false
        old_deactivate_mark = 8619034
#10 0x0048fe7e in code_convert_string (string=16849873, coding_system=10228834, dst_object=8619058, encodep=true, nocopy=false, norecord=true) at coding.c:9355
        coding = {id = 17, common_flags = 7168, mode = 1, spec = {iso_2022 = {flags = 0, current_invocation = {101, 2}, current_designation = {0, 2626936, 5692401, -2147123232}, ctext_extended_segment_len = 5, single_shifting = 0, bol = 0, embedded_utf_8 = 0, cmp_status = {state = 2147844069, method = COMPOSITION_RELATIVE, old_form = true, length = 1, nchars = 0, ncomps = -2147165050, carryover = {0, 0, 8, 8961866, 0, -2147123227, 2626792, 5561891, 11396830, 2626872, 5699447, 11226560, 13921622, 2626968, 8499681, 2, 18, 0, 5680763, 11396774, 13921622, 2626872, 5573253, 16849873, 13921622, 0, 25396250, 104, 58, 2626968, 5698168, 0, 0, 0, 0, 0, 0, -2147123227, -2147123232, -2147123227, 0, 1, 1, 47, 47, 2627096, 5530218, 8472888, 0, 0, -2147123232, 5, 0, 0, 5, 11226544, 0, 8472924, 0, 5, 0, 2627032, 10721436, 4, 18152049, 16849873, 2627032, 5562134}}}, ccl = 0x0, utf_16 = {bom = utf_detect_bom, endian = (utf_16_little_endian | unknown: 100), surrogate = 2}, utf_8_bom = utf_detect_bom, emacs_mule = {cmp_status = {state = COMPOSING_NO, method = 101, old_form = 2, length = 0, nchars = 2626936, ncomps = 5692401, carryover = {-2147123232, 5, 0, -2147123227, 0, 1, 1, 0, -2147165050, 0, 0, 8, 8961866, 0, -2147123227, 2626792, 5561891, 11396830, 2626872, 5699447, 11226560, 13921622, 2626968, 8499681, 2, 18, 0, 5680763, 11396774, 13921622, 2626872, 5573253, 16849873, 13921622, 0, 25396250, 104, 58, 2626968, 5698168, 0, 0, 0, 0, 0, 0, -2147123227, -2147123232, -2147123227, 0, 1, 1, 47, 47, 2627096, 5530218, 8472888, 0, 0, -2147123232, 5, 0, 0, 5, 11226544, 0, 8472924, 0}}}}, max_charset_id = 1, safe_charsets = 0x9c3c5c <bss_sbrk_buffer+1743132> "\377", src_multibyte = 0, dst_multibyte = 0, head_ascii = 0, detected_utf8_chars = 7652, eol_seen = 5, produced = 0, produced_char = 0, consumed = 5, consumed_char = 5, errors = 0, error_positions = 0xd46fc6 <bss_sbrk_buffer+5426310>, result = CODING_RESULT_SUCCESS, src_pos = 0, src_pos_byte = 0, src_chars = 5, src_bytes = 5, src_object = 16849873, source = 0x80057fe0 "/home", dst_pos = 8472888, dst_pos_byte = 0, dst_bytes = 5, dst_object = 8619034, destination = 0x80041c88 "0\034\004\200x\244Q\001", charbuf = 0x8005a000, charbuf_size = 16384, charbuf_used = 5, chars_at_source = 0, annotated = 0, carryover = "\000\000\000\026\337T\000\321\033\001\001X\026(\000,\337T\000\321\033\001\001\230\026(\000\353nS\000\070I\201\000\340\177\005\200\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\230\026(\000\245QW\000\032", carryover_bytes = 0, default_char = 32, detector = 0x484977 <detect_coding_charset>, decoder = 0x484f51 <decode_coding_charset>, encoder = 0x485af6 <encode_coding_charset>}
        chars = 5
        bytes = 5
#11 0x0048ff51 in code_convert_string_norecord (string=16849873, coding_system=10228834, encodep=true) at coding.c:9377
No locals.
#12 0x005261e9 in Ffile_symlink_p (filename=16849873) at fileio.c:2777
        handler = 8619034
#13 0x0056e8f2 in Ffuncall (nargs=2, args=0x281820) at eval.c:2790
        fun = 6372021
        original_fun = 8696530
        funcar = 12
        numargs = 1
        lisp_numargs = 2627496
        val = 2627480
        internal_args = 0x281824
        i = 8619034
#14 0x0056dcd1 in Fapply (nargs=2, args=0x281820) at eval.c:2276
        i = 2627620
        numargs = 1
        spread_arg = 13922246
        funcall_args = 0x0
        fun = 8696530
        retval = 10851930
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2818a8, nvars = 5690112}
        sa_count = 217
        sa_must_free = false
#15 0x0056d716 in eval_sub (form=10868478) at eval.c:2132
        vals = 0x281820
        argnum = 2
        sa_count = 217
        sa_must_free = false
        numargs = 8
        args_left = 8619034
        i = 2627620
        maxargs = 2628368
        argvals = {8466740, 13897638, 8699482, 8619034, 2628240, 2628964, 2627752, 5680763}
        fun = 8087613
        val = 8466740
        original_fun = 8960098
        original_args = 10868470
        funcar = 8466740
        gcpro1 = {next = 0x2818a8, var = 0x2818a8, nvars = 5564168}
        gcpro2 = {next = 0x55672f <Fcdr+17>, var = 0xc18922 <bss_sbrk_buffer+4187618>, nvars = 13922182}
        gcpro3 = {next = 0xa5d6fe <bss_sbrk_buffer+2372542>, var = 0x281820, nvars = 2}
#16 0x0056ae7b in Fprogn (args=10868454) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x281994, var = 0x88b0f2 <bss_sbrk_buffer+462258>, nvars = 8699480}
#17 0x0056b710 in FletX (args=11363774) at eval.c:848
        varlist = 8619034
        var = 8699482
        val = 8696530
        elt = 10868510
        lexenv = 8619034
        count = 214
        gcpro1 = {next = 0x281988, var = 0x57138f <Flength+328>, nvars = 8619034}
        gcpro2 = {next = 0x54e807 <COMPILEDP+25>, var = 0xad65be <bss_sbrk_buffer+2867838>, nvars = 12}
        gcpro3 = {next = 0xab4d50 <bss_sbrk_buffer+2730512>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2627928}
#18 0x0056d59d in eval_sub (form=11363718) at eval.c:2108
        numargs = 8
        args_left = 11363774
        i = 2
        maxargs = 2628368
        argvals = {11226432, 12, 2628104, 8979152, 2628240, 2628964, 2628120, 5600859}
        fun = 8087301
        val = 13971542
        original_fun = 8961890
        original_args = 11363774
        funcar = 8979154
        gcpro1 = {next = 0xd40, var = 0xd46fc6 <bss_sbrk_buffer+5426310>, nvars = 10883526}
        gcpro2 = {next = 0x2, var = 0x84b16a <bss_sbrk_buffer+200234>, nvars = 13971638}
        gcpro3 = {next = 0x8902d2 <bss_sbrk_buffer+483218>, var = 0x2, nvars = 2628096}
#19 0x0056ae7b in Fprogn (args=11363686) at eval.c:459
        val = 8499217
        gcpro1 = {next = 0x2, var = 0x281a90, nvars = 8979152}
#20 0x0056f1ce in funcall_lambda (fun=11363710, nargs=2, arg_vector=0x281b10) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 8979154
        lexenv = 8619034
        count = 211
        i = 2
        optional = false
        rest = false
#21 0x0056edbd in apply_lambda (fun=11363710, args=10883526) at eval.c:2899
        args_left = 8619034
        i = 2
        numargs = 2
        arg_vector = 0x281b10
        gcpro1 = {next = 0xc18890 <bss_sbrk_buffer+4187472>, var = 0xa611ce <bss_sbrk_buffer+2387598>, nvars = 2}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2628472}
        gcpro3 = {next = 0x281bb4, var = 0xffffffff, nvars = 8619034}
        tem = 13922246
        sa_count = 211
        sa_must_free = false
#22 0x0056dbba in eval_sub (form=10883534) at eval.c:2235
        fun = 11363710
        val = 2628888
        original_fun = 12683626
        original_args = 10883526
        funcar = 8689666
        gcpro1 = {next = 0x281c08, var = 0xab8ed6 <bss_sbrk_buffer+2747286>, nvars = 8619034}
        gcpro2 = {next = 0x55672f <Fcdr+17>, var = 0xadeece <bss_sbrk_buffer+2902926>, nvars = 2626928}
        gcpro3 = {next = 0xc18892 <bss_sbrk_buffer+4187474>, var = 0xad4406 <bss_sbrk_buffer+2859206>, nvars = 2628616}
#23 0x0056ae7b in Fprogn (args=10883510) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x281c88, nvars = 3}
#24 0x0056addb in Fif (args=11398870) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x281cb8, nvars = 3}
#25 0x0056d59d in eval_sub (form=11398878) at eval.c:2108
        numargs = 12
        args_left = 11398870
        i = 3
        maxargs = 8619034
        argvals = {11226368, 2627200, 20, 0, 0, -2147165052, 2628936, -2147123229}
        fun = 8087013
        val = 20
        original_fun = 8961626
        original_args = 11398870
        funcar = 207
        gcpro1 = {next = 0x281d68, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 11355174}
        gcpro2 = {next = 0x55672f <Fcdr+17>, var = 0x84b2d2 <bss_sbrk_buffer+200594>, nvars = 11243222}
        gcpro3 = {next = 0x80030511, var = 0x2, nvars = 2628936}
#26 0x0056ae7b in Fprogn (args=11396886) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x281de8, nvars = 9567400}
#27 0x0056b9e6 in Flet (args=11396830) at eval.c:918
        temps = 0x281de0
        tem = 8619034
        lexenv = 8619034
        elt = 11355214
        varlist = 8619034
        count = 207
        argnum = 2
        gcpro1 = {next = 0xab4ce0 <bss_sbrk_buffer+2730400>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2629160}
        gcpro2 = {next = 0x2814b0, var = 0x281e58, nvars = 2}
        sa_count = 207
        sa_must_free = false
#28 0x0056d59d in eval_sub (form=11396774) at eval.c:2108
        numargs = 8
        args_left = 11396830
        i = 2
        maxargs = 1
        argvals = {11226320, 13971590, 2629448, 8499681, 2, 18, 0, 5680763}
        fun = 8087325
        val = 2629448
        original_fun = 8961866
        original_args = 11396830
        funcar = 0
        gcpro1 = {next = 0x0, var = 0x183841a, nvars = 104}
        gcpro2 = {next = 0x550a85 <Flist+42>, var = 0x1011bd1 <bss_sbrk_buffer+8353937>, nvars = 13971590}
        gcpro3 = {next = 0xade6a6 <bss_sbrk_buffer+2900838>, var = 0xd53086 <bss_sbrk_buffer+5475654>, nvars = 2629352}
#29 0x0056ae7b in Fprogn (args=11396742) at eval.c:459
        val = 8499681
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x81495c <searchbufs+5980>, nvars = 8979152}
#30 0x0056f1ce in funcall_lambda (fun=11396766, nargs=2, arg_vector=0x282078) at eval.c:3017
        val = 0
        syms_left = 8619034
        next = 8979154
        lexenv = 8619034
        count = 204
        i = 2
        optional = false
        rest = true
#31 0x0056ebc5 in Ffuncall (nargs=3, args=0x282074) at eval.c:2851
        fun = 11396766
        original_fun = 12683554
        funcar = 8689666
        numargs = 2
        lisp_numargs = 2629704
        val = -1
        internal_args = 0x1
        i = 8696050
#32 0x0056e463 in call2 (fn=12683554, arg1=8696530, arg2=16849873) at eval.c:2604
        ret_ungc_val = 8619034
        gcpro1 = {next = 0x0, var = 0xc18922 <bss_sbrk_buffer+4187618>, nvars = 3}
        args = {12683554, 8696530, 16849873}
#33 0x0052618f in Ffile_symlink_p (filename=16849873) at fileio.c:2775
        handler = 12683554
#34 0x0056d814 in eval_sub (form=10661534) at eval.c:2160
        numargs = 4
        args_left = 8619034
        i = 1
        maxargs = 1
        argvals = {16849873, 8696170, 17705873, 5706639, 8619034, 8619034, 16472977, 12683554}
        fun = 6372021
        val = 2630056
        original_fun = 8696530
        original_args = 10661542
        funcar = 1
        gcpro1 = {next = 0x282228, var = 0x56dbf1 <eval_sub+2201>, nvars = 11226288}
        gcpro2 = {next = 0x1, var = 0x1, nvars = 2631072}
        gcpro3 = {next = 0xa2adee <bss_sbrk_buffer+2165422>, var = 0x282110, nvars = 1}
#35 0x0056af47 in Fsetq (args=10661526) at eval.c:528
        args_left = 10661526
        val = 8619034
        sym = 2631072
        lex_binding = 5706639
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2821f8, nvars = 12683554}
#36 0x0056d59d in eval_sub (form=10661518) at eval.c:2108
        numargs = 8
        args_left = 10661526
        i = 2
        maxargs = 8619034
        argvals = {1, 2631072, 2630280, 5384884, 10603281, 8696170, 17705873, 5706639}
        fun = 8087133
        val = 16849873
        original_fun = 8961746
        original_args = 10661526
        funcar = 11226272
        gcpro1 = {next = 0x282288, var = 0x1, nvars = 1}
        gcpro2 = {next = 0xc18922 <bss_sbrk_buffer+4187618>, var = 0xa09191 <bss_sbrk_buffer+2027089>, nvars = 16472977}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10603281}
#37 0x0056ae7b in Fprogn (args=10661558) at eval.c:459
        val = 16849873
        gcpro1 = {next = 0x2822d0, var = 0x282308, nvars = 5}
#38 0x0056addb in Fif (args=10661374) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x282338, nvars = 5}
#39 0x0056d59d in eval_sub (form=10661326) at eval.c:2108
        numargs = 20
        args_left = 10661374
        i = 5
        maxargs = 8619034
        argvals = {10629678, 6371512, 9126609, 12683554, 9126609, 1, 2630776, 5692401}
        fun = 8087013
        val = 20
        original_fun = 8961626
        original_args = 10661374
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x0, nvars = 0}
        gcpro2 = {next = 0x0, var = 0xa09261 <bss_sbrk_buffer+2027297>, nvars = 10603281}
        gcpro3 = {next = 0xab4c60 <bss_sbrk_buffer+2730272>, var = 0x1, nvars = -1}
#40 0x0056ae7b in Fprogn (args=10661742) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x8b42c1 <bss_sbrk_buffer+630657>, var = 0x282448, nvars = 3}
#41 0x0056addb in Fif (args=10661222) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x282478, nvars = 3}
#42 0x0056d59d in eval_sub (form=10661174) at eval.c:2108
        numargs = 12
        args_left = 10661222
        i = 3
        maxargs = 8619034
        argvals = {0, 0, -2147285709, 0, 0, 0, 1, 0}
        fun = 8087013
        val = 8619058
        original_fun = 8961626
        original_args = 10661222
        funcar = 0
        gcpro1 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 2628512}
        gcpro3 = {next = 0x80030533, var = 0x0, nvars = 0}
#43 0x0056ae7b in Fprogn (args=10661750) at eval.c:459
        val = 8619058
        gcpro1 = {next = 0xc, var = 0x2825a8, nvars = 10485120}
#44 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x2825a0
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 196
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2631144}
        gcpro2 = {next = 0x7b6670 <Squote>, var = 0x0, nvars = 3}
        sa_count = 196
        sa_must_free = false
#45 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 18152049, 2631304, 2631288, 5562134, -1, 2631336, 0}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 5
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0x5, var = 0x80057f90, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x2880, nvars = 5}
#46 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x282728, nvars = 3}
#47 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x282758, nvars = 3}
#48 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {14058934, 2631552, 2631608, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2631928
        original_fun = 8961626
        original_args = 10629542
        funcar = 11226144
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x10e2b91 <bss_sbrk_buffer+9209937>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2631656}
#49 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x282888, nvars = 9372320}
#50 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x282880
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 193
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0xd685ce <bss_sbrk_buffer+5563022>, nvars = 2631880}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2828c8, nvars = 1}
        sa_count = 193
        sa_must_free = false
#51 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13897006, 396, -1, 0, 0, 2631984, 3, 8619034}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 11226096
        gcpro1 = {next = 0x2829a8, var = 0x2829b0, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8619034}
        gcpro3 = {next = 0x0, var = 0x282940, nvars = 2}
#52 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x282a18, nvars = 4}
#53 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x55672f <Fcdr+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2632264}
#54 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 13897006, 2632360, 5564423, 10630718, 12, 2632408, 5706639}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x282ad8, var = 0x282ad8, nvars = 5564168}
        gcpro2 = {next = 0x55672f <Fcdr+17>, var = 0xa5d756 <bss_sbrk_buffer+2372630>, nvars = 8087128}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2632408}
#55 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#56 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x282b70
        tem = 14058958
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 189
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x0, nvars = 2632632}
        gcpro2 = {next = 0xa2363e <bss_sbrk_buffer+2134782>, var = 0xd40d2e <bss_sbrk_buffer+5401070>, nvars = 2}
        sa_count = 189
        sa_must_free = false
#57 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 13973382
        argvals = {0, 0, 0, 0, 0, 0, 0, 0}
        fun = 8087325
        val = 13897006
        original_fun = 8961866
        original_args = 10630966
        funcar = 0
        gcpro1 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#58 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13897006
        gcpro1 = {next = 0x0, var = 0x0, nvars = 10485024}
#59 0x0056f1ce in funcall_lambda (fun=10659942, nargs=1, arg_vector=0x282e64) at eval.c:3017
        val = 0
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 185
        i = 1
        optional = true
        rest = false
#60 0x0056ebc5 in Ffuncall (nargs=2, args=0x282e60) at eval.c:2851
        fun = 10659942
        original_fun = 8958194
        funcar = 8689666
        numargs = 1
        lisp_numargs = 2633192
        val = 0
        internal_args = 0x0
        i = 8619034
#61 0x0056dcd1 in Fapply (nargs=2, args=0x282e60) at eval.c:2276
        i = 2633316
        numargs = 1
        spread_arg = 13973382
        funcall_args = 0x0
        fun = 8958194
        retval = 0
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x0, nvars = 0}
        sa_count = 184
        sa_must_free = false
#62 0x0056d716 in eval_sub (form=10868478) at eval.c:2132
        vals = 0x282e60
        argnum = 2
        sa_count = 184
        sa_must_free = false
        numargs = 8
        args_left = 8619034
        i = 2633316
        maxargs = 2634064
        argvals = {8466740, 0, 0, 5534643, 0, 0, 0, 0}
        fun = 8087613
        val = 8466740
        original_fun = 8960098
        original_args = 10868470
        funcar = 8466740
        gcpro1 = {next = 0x282ee8, var = 0x282ee8, nvars = 5564168}
        gcpro2 = {next = 0x547389 <re_match_2_internal+275>, var = 0xc18922 <bss_sbrk_buffer+4187618>, nvars = 13973286}
        gcpro3 = {next = 0x0, var = 0x282e60, nvars = 2}
#63 0x0056ae7b in Fprogn (args=10868454) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x8003050e, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8699480}
#64 0x0056b710 in FletX (args=11363774) at eval.c:848
        varlist = 8619034
        var = 8699482
        val = 8958194
        elt = 10868510
        lexenv = 8619034
        count = 181
        gcpro1 = {next = 0x282fc8, var = 0x57138f <Flength+328>, nvars = 8619034}
        gcpro2 = {next = 0x54e807 <COMPILEDP+25>, var = 0xad65be <bss_sbrk_buffer+2867838>, nvars = 12}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 2633624}
#65 0x0056d59d in eval_sub (form=11363718) at eval.c:2108
        numargs = 8
        args_left = 11363774
        i = 2
        maxargs = 2634064
        argvals = {0, 0, 0, 8979152, 0, 0, 2633816, 5600859}
        fun = 8087301
        val = 0
        original_fun = 8961890
        original_args = 11363774
        funcar = 8979154
        gcpro1 = {next = 0x0, var = 0xd53786 <bss_sbrk_buffer+5477446>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x8902d2 <bss_sbrk_buffer+483218>, var = 0x0, nvars = 0}
#66 0x0056ae7b in Fprogn (args=11363686) at eval.c:459
        val = 8499217
        gcpro1 = {next = 0x0, var = 0x0, nvars = 8979152}
#67 0x0056f1ce in funcall_lambda (fun=11363710, nargs=2, arg_vector=0x283150) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 8979154
        lexenv = 8619034
        count = 178
        i = 2
        optional = false
        rest = false
#68 0x0056edbd in apply_lambda (fun=11363710, args=10883526) at eval.c:2899
        args_left = 8619034
        i = 2
        numargs = 2
        arg_vector = 0x283150
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0x0, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
        tem = 13973382
        sa_count = 178
        sa_must_free = false
#69 0x0056dbba in eval_sub (form=10883534) at eval.c:2235
        fun = 11363710
        val = 0
        original_fun = 12683626
        original_args = 10883526
        funcar = 8689666
        gcpro1 = {next = 0x0, var = 0xab8ed6 <bss_sbrk_buffer+2747286>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0xc18892 <bss_sbrk_buffer+4187474>, var = 0x0, nvars = 0}
#70 0x0056ae7b in Fprogn (args=10883510) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x2832c8, nvars = 3}
#71 0x0056addb in Fif (args=11398870) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2832f8, nvars = 3}
#72 0x0056d59d in eval_sub (form=11398878) at eval.c:2108
        numargs = 12
        args_left = 11398870
        i = 3
        maxargs = 8619034
        argvals = {0, 0, 0, 0, 0, 0, 0, 0}
        fun = 8087013
        val = 0
        original_fun = 8961626
        original_args = 11398870
        funcar = 0
        gcpro1 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x88b0f2 <bss_sbrk_buffer+462258>, nvars = 11243222}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#73 0x0056ae7b in Fprogn (args=11396886) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x283428, nvars = 9567400}
#74 0x0056b9e6 in Flet (args=11396830) at eval.c:918
        temps = 0x283420
        tem = 8619034
        lexenv = 8619034
        elt = 11355214
        varlist = 8619034
        count = 174
        argnum = 2
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2634856}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 2}
        sa_count = 174
        sa_must_free = false
#75 0x0056d59d in eval_sub (form=11396774) at eval.c:2108
        numargs = 8
        args_left = 11396830
        i = 2
        maxargs = 1
        argvals = {0, 0, 0, 0, 0, 0, 0, 0}
        fun = 8087325
        val = 2635144
        original_fun = 8961866
        original_args = 11396830
        funcar = 0
        gcpro1 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#76 0x0056ae7b in Fprogn (args=11396742) at eval.c:459
        val = 8499681
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2835b8, nvars = 8979152}
#77 0x0056f1ce in funcall_lambda (fun=11396766, nargs=2, arg_vector=0x2836c4) at eval.c:3017
        val = 0
        syms_left = 8619034
        next = 8979154
        lexenv = 8619034
        count = 171
        i = 2
        optional = false
        rest = true
#78 0x0056ebc5 in Ffuncall (nargs=3, args=0x2836c0) at eval.c:2851
        fun = 11396766
        original_fun = 12683554
        funcar = 8689666
        numargs = 2
        lisp_numargs = -2147285709
        val = 2635416
        internal_args = 0x2836c8
        i = 10629582
#79 0x0056d716 in eval_sub (form=10629566) at eval.c:2132
        vals = 0x2836c0
        argnum = 3
        sa_count = 170
        sa_must_free = false
        numargs = 12
        args_left = 8619034
        i = 2635464
        maxargs = 8619034
        argvals = {-2147165050, -2147123321, -2147285712, 15, -2147123320, -2147285712, 18, -2147123319}
        fun = 8087781
        val = 2635672
        original_fun = 8694386
        original_args = 10629574
        funcar = 0
        gcpro1 = {next = 0x2, var = 0x80030533, nvars = -1}
        gcpro2 = {next = 0x8003050e, var = 0x80030533, nvars = -1}
        gcpro3 = {next = 0x80030530, var = 0x2836c0, nvars = 3}
#80 0x0056af47 in Fsetq (args=10629558) at eval.c:528
        args_left = 10629558
        val = 8619034
        sym = 2636320
        lex_binding = 5706639
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x0, nvars = -2147123312}
#81 0x0056d59d in eval_sub (form=10629550) at eval.c:2108
        numargs = 16
        args_left = 10629558
        i = 4
        maxargs = 8619034
        argvals = {-2147123312, 0, 0, 0, 2, 2636320, 2635928, 5}
        fun = 8087133
        val = 2635976
        original_fun = 8961746
        original_args = 10629558
        funcar = 5
        gcpro1 = {next = 0x0, var = 0x80057f90, nvars = 5}
        gcpro2 = {next = 0x54561e <re_search+75>, var = 0x814938 <searchbufs+5944>, nvars = 0}
        gcpro3 = {next = 0x5, var = 0x283a20, nvars = 2635928}
#82 0x0056adbe in Fif (args=10629542) at eval.c:409
        cond = 12683554
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2838f8, nvars = 3}
#83 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {0, 2636064, 2636120, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2636440
        original_fun = 8961626
        original_args = 10629542
        funcar = 11225712
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x10e2b91 <bss_sbrk_buffer+9209937>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2636168}
#84 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x283a28, nvars = 9372320}
#85 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x283a20
        tem = 12683554
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 166
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2636392}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x283a68, nvars = 1}
        sa_count = 166
        sa_must_free = false
#86 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 372, -1, 0, 0, 2636496, 3, 13976686}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 5562134
        gcpro1 = {next = 0x283b38, var = 0x8c3154 <bss_sbrk_buffer+691732>, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10630358}
        gcpro3 = {next = 0x53d4d5 <extract_number_and_incr+19>, var = 0x283ae0, nvars = 2}
#87 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x283bb8, nvars = 4}
#88 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x556709 <Fcar+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2636776}
#89 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 0, 2636872, 9280088, 10630438, 2638164, 2636920, 5600859}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x283c78, var = 0x283c78, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 8086984}
        gcpro3 = {next = 0x8d9a5a <bss_sbrk_buffer+784154>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 0}
#90 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#91 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x283d10
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 162
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x80030511, nvars = 2637144}
        gcpro2 = {next = 0xa234fe <bss_sbrk_buffer+2134462>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2}
        sa_count = 162
        sa_must_free = false
#92 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 2637584
        argvals = {0, 0, 0, 10485024, 0, 0, 2637336, 5600859}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 10485026
        gcpro1 = {next = 0x0, var = 0xd5379e <bss_sbrk_buffer+5477470>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x9ffd22 <bss_sbrk_buffer+1989090>, var = 0x0, nvars = 0}
#93 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x0, var = 0x0, nvars = 10485024}
#94 0x0056f1ce in funcall_lambda (fun=10659942, nargs=3, arg_vector=0x283f10) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 158
        i = 3
        optional = true
        rest = false
#95 0x0056edbd in apply_lambda (fun=10659942, args=10660966) at eval.c:2899
        args_left = 8619034
        i = 3
        numargs = 3
        arg_vector = 0x283f10
        gcpro1 = {next = 0x0, var = 0x0, nvars = 3}
        gcpro2 = {next = 0x80030511, var = 0x2, nvars = 0}
        gcpro3 = {next = 0x8004dc84, var = 0x0, nvars = -2147123321}
        tem = 13973406
        sa_count = 158
        sa_must_free = false
#96 0x0056dbba in eval_sub (form=10660958) at eval.c:2235
        fun = 10659942
        val = 2637912
        original_fun = 8958194
        original_args = 10660966
        funcar = 8689666
        gcpro1 = {next = 0x80030533, var = 0x9ffd20 <bss_sbrk_buffer+1989088>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#97 0x0056d77c in eval_sub (form=10660950) at eval.c:2145
        numargs = 4
        args_left = 10660990
        i = 0
        maxargs = 1
        argvals = {2637996, 5562134, 17705873, 2638008, 5562175, 17705873, 2638104, 5708278}
        fun = 6371589
        val = 2638136
        original_fun = 8696218
        original_args = 10660990
        funcar = 8619034
        gcpro1 = {next = 0x2840e8, var = 0x54e807 <COMPILEDP+25>, nvars = 10630046}
        gcpro2 = {next = 0x80057f74, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x10e2b91 <bss_sbrk_buffer+9209937>, var = 0x2840a0, nvars = 0}
#98 0x0056b8b4 in Flet (args=10661014) at eval.c:888
        temps = 0x284150
        tem = 5564423
        lexenv = 2638296
        elt = 10660942
        varlist = 10661006
        count = 156
        argnum = 1
        gcpro1 = {next = 0x80057f74, var = 0x284160, nvars = 2638232}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 1}
        sa_count = 156
        sa_must_free = false
#99 0x0056d59d in eval_sub (form=10660910) at eval.c:2108
        numargs = 12
        args_left = 10661014
        i = 3
        maxargs = 8619034
        argvals = {1, 1, 2638408, 17705873, 17705872, 1, 2638600, 5690304}
        fun = 8087325
        val = 2638568
        original_fun = 8961866
        original_args = 10661014
        funcar = 2638496
        gcpro1 = {next = 0x284288, var = 0x5504ce <make_specified_string+150>, nvars = 17705873}
        gcpro2 = {next = 0x5, var = 0x10e2ba1 <bss_sbrk_buffer+9209953>, nvars = 8619034}
        gcpro3 = {next = 0x9ffd82 <bss_sbrk_buffer+1989186>, var = 0x80057f84, nvars = 17705873}
#100 0x0056ae7b in Fprogn (args=10661150) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x84b13a <bss_sbrk_buffer+200186>, var = 0x2842d8, nvars = 3}
#101 0x0056addb in Fif (args=10630062) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x284308, nvars = 3}
#102 0x0056d59d in eval_sub (form=10630014) at eval.c:2108
        numargs = 12
        args_left = 10630062
        i = 3
        maxargs = 8619034
        argvals = {17705889, 17705873, 1, 0, 0, -2147285709, 0, 0}
        fun = 8087013
        val = 8619034
        original_fun = 8961626
        original_args = 10630062
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x4, nvars = 8696122}
        gcpro2 = {next = 0x0, var = 0x114fe31 <bss_sbrk_buffer+9657073>, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x284350, nvars = 2}
#103 0x0056ad05 in For (args=10661158) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x284418, nvars = 3}
#104 0x0056d59d in eval_sub (form=10629790) at eval.c:2108
        numargs = 12
        args_left = 10629822
        i = 3
        maxargs = 8619034
        argvals = {0, 0, -2147285709, 0, 0, 0, 1, 0}
        fun = 8086965
        val = 17705873
        original_fun = 8961578
        original_args = 10629822
        funcar = 109
        gcpro1 = {next = 0x0, var = 0x2, nvars = 47}
        gcpro2 = {next = 0x2844a8, var = 0x53d4d5 <extract_number_and_incr+19>, nvars = 2636608}
        gcpro3 = {next = 0x80030533, var = 0x0, nvars = 0}
#105 0x0056ae7b in Fprogn (args=10661166) at eval.c:459
        val = 17705873
        gcpro1 = {next = 0xc, var = 0x284548, nvars = 10485120}
#106 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x284540
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 150
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2639240}
        gcpro2 = {next = 0x1030530 <bss_sbrk_buffer+8479216>, var = 0x0, nvars = 3}
        sa_count = 150
        sa_must_free = false
#107 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 18152049, 2639400, 2639384, 5562134, -1, 2639432, 0}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 12
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0xc, var = 0x80057f68, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x4820, nvars = 12}
#108 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x2846c8, nvars = 3}
#109 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2846f8, nvars = 3}
#110 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {0, 2639648, 2639704, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2640024
        original_fun = 8961626
        original_args = 10629542
        funcar = 11225408
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x114fe31 <bss_sbrk_buffer+9657073>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2639752}
#111 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x284828, nvars = 9372320}
#112 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x284820
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 147
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2639976}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x284868, nvars = 1}
        sa_count = 147
        sa_must_free = false
#113 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 376, -1, 0, 0, 2640080, 3, 13976686}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 5562134
        gcpro1 = {next = 0x284938, var = 0x8c3154 <bss_sbrk_buffer+691732>, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10630358}
        gcpro3 = {next = 0x53d4d5 <extract_number_and_incr+19>, var = 0x2848e0, nvars = 2}
#114 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2849b8, nvars = 4}
#115 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x556709 <Fcar+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2640360}
#116 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 0, 2640456, 9280088, 10630438, 2641748, 2640504, 5600859}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x284a78, var = 0x284a78, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 8086984}
        gcpro3 = {next = 0x8d9a5a <bss_sbrk_buffer+784154>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 0}
#117 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#118 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x284b10
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 143
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x80030511, nvars = 2640728}
        gcpro2 = {next = 0xa234fe <bss_sbrk_buffer+2134462>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2}
        sa_count = 143
        sa_must_free = false
#119 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 2641168
        argvals = {0, 0, 0, 10485024, 0, 0, 2640920, 5600859}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 10485026
        gcpro1 = {next = 0x0, var = 0xd5379e <bss_sbrk_buffer+5477470>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x9ffd22 <bss_sbrk_buffer+1989090>, var = 0x0, nvars = 0}
#120 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x0, var = 0x0, nvars = 10485024}
#121 0x0056f1ce in funcall_lambda (fun=10659942, nargs=3, arg_vector=0x284d10) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 139
        i = 3
        optional = true
        rest = false
#122 0x0056edbd in apply_lambda (fun=10659942, args=10660966) at eval.c:2899
        args_left = 8619034
        i = 3
        numargs = 3
        arg_vector = 0x284d10
        gcpro1 = {next = 0x0, var = 0x0, nvars = 3}
        gcpro2 = {next = 0x80030511, var = 0x2, nvars = 0}
        gcpro3 = {next = 0x8004dc84, var = 0x0, nvars = -2147123369}
        tem = 13973406
        sa_count = 139
        sa_must_free = false
#123 0x0056dbba in eval_sub (form=10660958) at eval.c:2235
        fun = 10659942
        val = 2641496
        original_fun = 8958194
        original_args = 10660966
        funcar = 8689666
        gcpro1 = {next = 0x80030533, var = 0x9ffd20 <bss_sbrk_buffer+1989088>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#124 0x0056d77c in eval_sub (form=10660950) at eval.c:2145
        numargs = 4
        args_left = 10660990
        i = 0
        maxargs = 1
        argvals = {2641580, 5562134, 18153009, 2641592, 5562175, 18153009, 2641688, 5708278}
        fun = 6371589
        val = 2641720
        original_fun = 8696218
        original_args = 10660990
        funcar = 8619034
        gcpro1 = {next = 0x284ee8, var = 0x54e807 <COMPILEDP+25>, nvars = 10630046}
        gcpro2 = {next = 0x80057f44, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x114fe31 <bss_sbrk_buffer+9657073>, var = 0x284ea0, nvars = 0}
#125 0x0056b8b4 in Flet (args=10661014) at eval.c:888
        temps = 0x284f50
        tem = 5564423
        lexenv = 2641880
        elt = 10660942
        varlist = 10661006
        count = 137
        argnum = 1
        gcpro1 = {next = 0x80057f44, var = 0x284f60, nvars = 2641816}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 1}
        sa_count = 137
        sa_must_free = false
#126 0x0056d59d in eval_sub (form=10660910) at eval.c:2108
        numargs = 12
        args_left = 10661014
        i = 3
        maxargs = 8619034
        argvals = {1, 1, 2641992, 18153009, 18153008, 1, 2642184, 5690304}
        fun = 8087325
        val = 2642152
        original_fun = 8961866
        original_args = 10661014
        funcar = 2642080
        gcpro1 = {next = 0x285088, var = 0x5504ce <make_specified_string+150>, nvars = 18153009}
        gcpro2 = {next = 0xc, var = 0x114fe51 <bss_sbrk_buffer+9657105>, nvars = 8619034}
        gcpro3 = {next = 0x9ffd82 <bss_sbrk_buffer+1989186>, var = 0x80057f54, nvars = 18153009}
#127 0x0056ae7b in Fprogn (args=10661150) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x84b13a <bss_sbrk_buffer+200186>, var = 0x2850d8, nvars = 3}
#128 0x0056addb in Fif (args=10630062) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x285108, nvars = 3}
#129 0x0056d59d in eval_sub (form=10630014) at eval.c:2108
        numargs = 12
        args_left = 10630062
        i = 3
        maxargs = 8619034
        argvals = {18153041, 18153009, 1, 0, 0, -2147285709, 0, 0}
        fun = 8087013
        val = 8619034
        original_fun = 8961626
        original_args = 10630062
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x4, nvars = 8696122}
        gcpro2 = {next = 0x0, var = 0x114fe81 <bss_sbrk_buffer+9657153>, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x285150, nvars = 2}
#130 0x0056ad05 in For (args=10661158) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x285218, nvars = 3}
#131 0x0056d59d in eval_sub (form=10629790) at eval.c:2108
        numargs = 12
        args_left = 10629822
        i = 3
        maxargs = 8619034
        argvals = {0, 0, -2147285709, 0, 0, 0, 1, 0}
        fun = 8086965
        val = 18153009
        original_fun = 8961578
        original_args = 10629822
        funcar = 109
        gcpro1 = {next = 0x0, var = 0x2, nvars = 47}
        gcpro2 = {next = 0x2852a8, var = 0x53d4d5 <extract_number_and_incr+19>, nvars = 2640192}
        gcpro3 = {next = 0x80030533, var = 0x0, nvars = 0}
#132 0x0056ae7b in Fprogn (args=10661166) at eval.c:459
        val = 18153009
        gcpro1 = {next = 0xc, var = 0x285348, nvars = 10485120}
#133 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x285340
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 131
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2642824}
        gcpro2 = {next = 0x1030530 <bss_sbrk_buffer+8479216>, var = 0x0, nvars = 3}
        sa_count = 131
        sa_must_free = false
#134 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 18152049, 2642984, 2642968, 5562134, -1, 2643016, 0}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 16
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0x10, var = 0x80057f34, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x5620, nvars = 16}
#135 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x2854c8, nvars = 3}
#136 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2854f8, nvars = 3}
#137 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {0, 2643232, 2643288, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2643608
        original_fun = 8961626
        original_args = 10629542
        funcar = 11225104
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x114fe81 <bss_sbrk_buffer+9657153>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2643336}
#138 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x285628, nvars = 9372320}
#139 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x285620
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 128
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2643560}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x285668, nvars = 1}
        sa_count = 128
        sa_must_free = false
#140 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 380, -1, 0, 0, 2643664, 3, 13976686}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 5562134
        gcpro1 = {next = 0x285738, var = 0x8c3154 <bss_sbrk_buffer+691732>, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10630358}
        gcpro3 = {next = 0x53d4d5 <extract_number_and_incr+19>, var = 0x2856e0, nvars = 2}
#141 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2857b8, nvars = 4}
#142 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x556709 <Fcar+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2643944}
#143 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 0, 2644040, 9280088, 10630438, 2645332, 2644088, 5600859}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x285878, var = 0x285878, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 8086984}
        gcpro3 = {next = 0x8d9a5a <bss_sbrk_buffer+784154>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 0}
#144 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#145 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x285910
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 124
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x80030511, nvars = 2644312}
        gcpro2 = {next = 0xa234fe <bss_sbrk_buffer+2134462>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2}
        sa_count = 124
        sa_must_free = false
#146 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 2644752
        argvals = {0, 0, 0, 10485024, 0, 0, 2644504, 5600859}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 10485026
        gcpro1 = {next = 0x0, var = 0xd5379e <bss_sbrk_buffer+5477470>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x9ffd22 <bss_sbrk_buffer+1989090>, var = 0x0, nvars = 0}
#147 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x0, var = 0x0, nvars = 10485024}
#148 0x0056f1ce in funcall_lambda (fun=10659942, nargs=3, arg_vector=0x285b10) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 120
        i = 3
        optional = true
        rest = false
#149 0x0056edbd in apply_lambda (fun=10659942, args=10660966) at eval.c:2899
        args_left = 8619034
        i = 3
        numargs = 3
        arg_vector = 0x285b10
        gcpro1 = {next = 0x0, var = 0x0, nvars = 3}
        gcpro2 = {next = 0x80030511, var = 0x2, nvars = 0}
        gcpro3 = {next = 0x8004dc84, var = 0x0, nvars = -2147123425}
        tem = 13973406
        sa_count = 120
        sa_must_free = false
#150 0x0056dbba in eval_sub (form=10660958) at eval.c:2235
        fun = 10659942
        val = 2645080
        original_fun = 8958194
        original_args = 10660966
        funcar = 8689666
        gcpro1 = {next = 0x80030533, var = 0x9ffd20 <bss_sbrk_buffer+1989088>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#151 0x0056d77c in eval_sub (form=10660950) at eval.c:2145
        numargs = 4
        args_left = 10660990
        i = 0
        maxargs = 1
        argvals = {2645164, 5562134, 18153089, 2645176, 5562175, 18153089, 2645272, 5708278}
        fun = 6371589
        val = 2645304
        original_fun = 8696218
        original_args = 10660990
        funcar = 8619034
        gcpro1 = {next = 0x285ce8, var = 0x54e807 <COMPILEDP+25>, nvars = 10630046}
        gcpro2 = {next = 0x80057f0e, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x114fe81 <bss_sbrk_buffer+9657153>, var = 0x285ca0, nvars = 0}
#152 0x0056b8b4 in Flet (args=10661014) at eval.c:888
        temps = 0x285d50
        tem = 5564423
        lexenv = 2645464
        elt = 10660942
        varlist = 10661006
        count = 118
        argnum = 1
        gcpro1 = {next = 0x80057f0e, var = 0x285d60, nvars = 2645400}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 1}
        sa_count = 118
        sa_must_free = false
#153 0x0056d59d in eval_sub (form=10660910) at eval.c:2108
        numargs = 12
        args_left = 10661014
        i = 3
        maxargs = 8619034
        argvals = {18153088, 1, 16, 18153089, 5562156, 18153137, 2645768, 5690304}
        fun = 8087325
        val = 16
        original_fun = 8961866
        original_args = 10661014
        funcar = 2645612
        gcpro1 = {next = 0x10, var = 0x522d5b <directory_file_name+30>, nvars = 2645648}
        gcpro2 = {next = 0x5504ce <make_specified_string+150>, var = 0x114feb1 <bss_sbrk_buffer+9657201>, nvars = 8619034}
        gcpro3 = {next = 0x9ffd82 <bss_sbrk_buffer+1989186>, var = 0x0, nvars = 2645624}
#154 0x0056ae7b in Fprogn (args=10661150) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x84b13a <bss_sbrk_buffer+200186>, var = 0x285ed8, nvars = 3}
#155 0x0056addb in Fif (args=10630062) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x285f08, nvars = 3}
#156 0x0056d59d in eval_sub (form=10630014) at eval.c:2108
        numargs = 12
        args_left = 10630062
        i = 3
        maxargs = 8619034
        argvals = {18153137, 18153089, 1, 0, 0, -2147285709, 0, 0}
        fun = 8087013
        val = 8619034
        original_fun = 8961626
        original_args = 10630062
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x4, nvars = 8696122}
        gcpro2 = {next = 0x0, var = 0x114fef1 <bss_sbrk_buffer+9657265>, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x285f50, nvars = 2}
#157 0x0056ad05 in For (args=10661158) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x286018, nvars = 3}
#158 0x0056d59d in eval_sub (form=10629790) at eval.c:2108
        numargs = 12
        args_left = 10629822
        i = 3
        maxargs = 8619034
        argvals = {0, 0, -2147285709, 0, 0, 0, 1, 0}
        fun = 8086965
        val = 18153089
        original_fun = 8961578
        original_args = 10629822
        funcar = 109
        gcpro1 = {next = 0x0, var = 0x2, nvars = 47}
        gcpro2 = {next = 0x2860a8, var = 0x53d4d5 <extract_number_and_incr+19>, nvars = 2643776}
        gcpro3 = {next = 0x80030533, var = 0x0, nvars = 0}
#159 0x0056ae7b in Fprogn (args=10661166) at eval.c:459
        val = 18153089
        gcpro1 = {next = 0xc, var = 0x286148, nvars = 10485120}
#160 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x286140
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 112
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2646408}
        gcpro2 = {next = 0x1030530 <bss_sbrk_buffer+8479216>, var = 0x0, nvars = 3}
        sa_count = 112
        sa_must_free = false
#161 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 18152049, 2646568, 2646552, 5562134, -1, 2646600, 0}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 22
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0x16, var = 0x80057ef8, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x6420, nvars = 22}
#162 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x2862c8, nvars = 3}
#163 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2862f8, nvars = 3}
#164 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {0, 2646816, 2646872, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2647192
        original_fun = 8961626
        original_args = 10629542
        funcar = 11224800
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x114fef1 <bss_sbrk_buffer+9657265>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2646920}
#165 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x286428, nvars = 9372320}
#166 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x286420
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 109
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2647144}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x286468, nvars = 1}
        sa_count = 109
        sa_must_free = false
#167 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 384, -1, 0, 0, 2647248, 3, 13976686}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 5562134
        gcpro1 = {next = 0x286538, var = 0x8c3154 <bss_sbrk_buffer+691732>, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10630358}
        gcpro3 = {next = 0x53d4d5 <extract_number_and_incr+19>, var = 0x2864e0, nvars = 2}
#168 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2865b8, nvars = 4}
#169 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x556709 <Fcar+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2647528}
#170 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 0, 2647624, 9280088, 10630438, 2648916, 2647672, 5600859}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x286678, var = 0x286678, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 8086984}
        gcpro3 = {next = 0x8d9a5a <bss_sbrk_buffer+784154>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 0}
#171 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#172 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x286710
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 105
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x80030511, nvars = 2647896}
        gcpro2 = {next = 0xa234fe <bss_sbrk_buffer+2134462>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2}
        sa_count = 105
        sa_must_free = false
#173 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 2648336
        argvals = {0, 0, 0, 10485024, 0, 0, 2648088, 5600859}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 10485026
        gcpro1 = {next = 0x0, var = 0xd5379e <bss_sbrk_buffer+5477470>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x9ffd22 <bss_sbrk_buffer+1989090>, var = 0x0, nvars = 0}
#174 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x0, var = 0x0, nvars = 10485024}
#175 0x0056f1ce in funcall_lambda (fun=10659942, nargs=3, arg_vector=0x286910) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 101
        i = 3
        optional = true
        rest = false
#176 0x0056edbd in apply_lambda (fun=10659942, args=10660966) at eval.c:2899
        args_left = 8619034
        i = 3
        numargs = 3
        arg_vector = 0x286910
        gcpro1 = {next = 0x0, var = 0x0, nvars = 3}
        gcpro2 = {next = 0x80030511, var = 0x2, nvars = 0}
        gcpro3 = {next = 0x8004dc84, var = 0x0, nvars = -2147123489}
        tem = 13973406
        sa_count = 101
        sa_must_free = false
#177 0x0056dbba in eval_sub (form=10660958) at eval.c:2235
        fun = 10659942
        val = 2648664
        original_fun = 8958194
        original_args = 10660966
        funcar = 8689666
        gcpro1 = {next = 0x80030533, var = 0x9ffd20 <bss_sbrk_buffer+1989088>, nvars = 0}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#178 0x0056d77c in eval_sub (form=10660950) at eval.c:2145
        numargs = 4
        args_left = 10660990
        i = 0
        maxargs = 1
        argvals = {2648748, 5562134, 18153201, 2648760, 5562175, 18153201, 2648856, 5708278}
        fun = 6371589
        val = 2648888
        original_fun = 8696218
        original_args = 10660990
        funcar = 8619034
        gcpro1 = {next = 0x286ae8, var = 0x54e807 <COMPILEDP+25>, nvars = 10630046}
        gcpro2 = {next = 0x80057ecf, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x114fef1 <bss_sbrk_buffer+9657265>, var = 0x286aa0, nvars = 0}
#179 0x0056b8b4 in Flet (args=10661014) at eval.c:888
        temps = 0x286b50
        tem = 5564423
        lexenv = 2649048
        elt = 10660942
        varlist = 10661006
        count = 99
        argnum = 1
        gcpro1 = {next = 0x80057ecf, var = 0x286b60, nvars = 2648984}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 1}
        sa_count = 99
        sa_must_free = false
#180 0x0056d59d in eval_sub (form=10660910) at eval.c:2108
        numargs = 12
        args_left = 10661014
        i = 3
        maxargs = 8619034
        argvals = {18153200, 1, 22, 18153201, 5562156, 18153217, 2649352, 5690304}
        fun = 8087325
        val = 22
        original_fun = 8961866
        original_args = 10661014
        funcar = 2649196
        gcpro1 = {next = 0x16, var = 0x522d5b <directory_file_name+30>, nvars = 2649232}
        gcpro2 = {next = 0x5504ce <make_specified_string+150>, var = 0x114ff01 <bss_sbrk_buffer+9657281>, nvars = 8619034}
        gcpro3 = {next = 0x9ffd82 <bss_sbrk_buffer+1989186>, var = 0x0, nvars = 2649208}
#181 0x0056ae7b in Fprogn (args=10661150) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x84b13a <bss_sbrk_buffer+200186>, var = 0x286cd8, nvars = 3}
#182 0x0056addb in Fif (args=10630062) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x286d08, nvars = 3}
#183 0x0056d59d in eval_sub (form=10630014) at eval.c:2108
        numargs = 12
        args_left = 10630062
        i = 3
        maxargs = 8619034
        argvals = {18153217, 18153201, 1, 0, 0, -2147285709, 0, 0}
        fun = 8087013
        val = 8619034
        original_fun = 8961626
        original_args = 10630062
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x4, nvars = 8696122}
        gcpro2 = {next = 0x0, var = 0x114ff41 <bss_sbrk_buffer+9657345>, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x286d50, nvars = 2}
#184 0x0056ad05 in For (args=10661158) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x286e18, nvars = 3}
#185 0x0056d59d in eval_sub (form=10629790) at eval.c:2108
        numargs = 12
        args_left = 10629822
        i = 3
        maxargs = 8619034
        argvals = {0, 0, -2147285709, 0, 0, 0, 1, 0}
        fun = 8086965
        val = 18153201
        original_fun = 8961578
        original_args = 10629822
        funcar = 109
        gcpro1 = {next = 0x0, var = 0x2, nvars = 47}
        gcpro2 = {next = 0x286ea8, var = 0x53d4d5 <extract_number_and_incr+19>, nvars = 2647360}
        gcpro3 = {next = 0x80030533, var = 0x0, nvars = 0}
#186 0x0056ae7b in Fprogn (args=10661166) at eval.c:459
        val = 18153201
        gcpro1 = {next = 0xc, var = 0x286f48, nvars = 10485120}
#187 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x286f40
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 93
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2649992}
        gcpro2 = {next = 0x1030530 <bss_sbrk_buffer+8479216>, var = 0x0, nvars = 3}
        sa_count = 93
        sa_must_free = false
#188 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 18152049, 2650152, 2650136, 5562134, -1, 2650184, 0}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 27
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0x1b, var = 0x80057eb4, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x7220, nvars = 27}
#189 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x2870c8, nvars = 3}
#190 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2870f8, nvars = 3}
#191 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {0, 2650400, 2650456, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2650776
        original_fun = 8961626
        original_args = 10629542
        funcar = 11224496
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x114ff41 <bss_sbrk_buffer+9657345>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2650504}
#192 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x287228, nvars = 9372320}
#193 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x287220
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 90
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2650728}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x287268, nvars = 1}
        sa_count = 90
        sa_must_free = false
#194 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 388, -1, 0, 0, 2650832, 3, 13976686}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 5562134
        gcpro1 = {next = 0x287338, var = 0x8c3154 <bss_sbrk_buffer+691732>, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10630358}
        gcpro3 = {next = 0x53d4d5 <extract_number_and_incr+19>, var = 0x2872e0, nvars = 2}
#195 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2873b8, nvars = 4}
#196 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x556709 <Fcar+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2651112}
#197 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 0, 2651208, 9280088, 10630438, 2652500, 2651256, 5600859}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x287478, var = 0x287478, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x0, nvars = 8086984}
        gcpro3 = {next = 0x8d9a5a <bss_sbrk_buffer+784154>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 0}
#198 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#199 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x287510
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 86
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x80030511, nvars = 2651480}
        gcpro2 = {next = 0xa234fe <bss_sbrk_buffer+2134462>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2}
        sa_count = 86
        sa_must_free = false
#200 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 2651920
        argvals = {0, 0, 2651624, 10485024, 9258342, 8619034, 2651672, 5600859}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 10485026
        gcpro1 = {next = 0x287618, var = 0xd5379e <bss_sbrk_buffer+5477470>, nvars = 1}
        gcpro2 = {next = 0x55672f <Fcdr+17>, var = 0xd4765e <bss_sbrk_buffer+5427998>, nvars = 8083408}
        gcpro3 = {next = 0x9ffd22 <bss_sbrk_buffer+1989090>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2651672}
#201 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x287660, var = 0x1, nvars = 10485024}
#202 0x0056f1ce in funcall_lambda (fun=10659942, nargs=3, arg_vector=0x287710) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 82
        i = 3
        optional = true
        rest = false
#203 0x0056edbd in apply_lambda (fun=10659942, args=10660966) at eval.c:2899
        args_left = 8619034
        i = 3
        numargs = 3
        arg_vector = 0x287710
        gcpro1 = {next = 0x836e00 <bss_sbrk_buffer+117440>, var = 0x815ebc <o_fwd.60737>, nvars = 3}
        gcpro2 = {next = 0x80030511, var = 0x2, nvars = 8478396}
        gcpro3 = {next = 0x8004dc84, var = 0x287818, nvars = -2147123565}
        tem = 13973406
        sa_count = 82
        sa_must_free = false
#204 0x0056dbba in eval_sub (form=10660958) at eval.c:2235
        fun = 10659942
        val = 2652248
        original_fun = 8958194
        original_args = 10660966
        funcar = 8689666
        gcpro1 = {next = 0x80030533, var = 0x9ffd20 <bss_sbrk_buffer+1989088>, nvars = 8619034}
        gcpro2 = {next = 0x54e807 <COMPILEDP+25>, var = 0x0, nvars = 12}
        gcpro3 = {next = 0x8d457e <bss_sbrk_buffer+762430>, var = 0xd467be <bss_sbrk_buffer+5424254>, nvars = 2652152}
#205 0x0056d77c in eval_sub (form=10660950) at eval.c:2145
        numargs = 4
        args_left = 10660990
        i = 0
        maxargs = 1
        argvals = {2652332, 5562134, 18153281, 2652344, 5562175, 18153281, 2652440, 5708278}
        fun = 6371589
        val = 2652472
        original_fun = 8696218
        original_args = 10660990
        funcar = 8619034
        gcpro1 = {next = 0x2878e8, var = 0x54e807 <COMPILEDP+25>, nvars = 10630046}
        gcpro2 = {next = 0x80057e80, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x114ff41 <bss_sbrk_buffer+9657345>, var = 0x2878a0, nvars = 0}
#206 0x0056b8b4 in Flet (args=10661014) at eval.c:888
        temps = 0x287950
        tem = 5564423
        lexenv = 2652632
        elt = 10660942
        varlist = 10661006
        count = 80
        argnum = 1
        gcpro1 = {next = 0x80057e80, var = 0x287960, nvars = 2652568}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 1}
        sa_count = 80
        sa_must_free = false
#207 0x0056d59d in eval_sub (form=10660910) at eval.c:2108
        numargs = 12
        args_left = 10661014
        i = 3
        maxargs = 8619034
        argvals = {18153280, 1, 27, 18153281, 5562156, 18153297, 2652936, 5690304}
        fun = 8087325
        val = 27
        original_fun = 8961866
        original_args = 10661014
        funcar = 2652780
        gcpro1 = {next = 0x1b, var = 0x522d5b <directory_file_name+30>, nvars = 2652816}
        gcpro2 = {next = 0x5504ce <make_specified_string+150>, var = 0x114ff51 <bss_sbrk_buffer+9657361>, nvars = 8619034}
        gcpro3 = {next = 0x9ffd82 <bss_sbrk_buffer+1989186>, var = 0x0, nvars = 2652792}
#208 0x0056ae7b in Fprogn (args=10661150) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x84b13a <bss_sbrk_buffer+200186>, var = 0x287ad8, nvars = 3}
#209 0x0056addb in Fif (args=10630062) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x287b08, nvars = 3}
#210 0x0056d59d in eval_sub (form=10630014) at eval.c:2108
        numargs = 12
        args_left = 10630062
        i = 3
        maxargs = 8619034
        argvals = {18153297, 18153281, 1, 8619034, 8619034, -2147285709, 2653080, 5680763}
        fun = 8087013
        val = 8619034
        original_fun = 8961626
        original_args = 10630062
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x4, nvars = 8696122}
        gcpro2 = {next = 0x556700 <Fcar+8>, var = 0x114ff91 <bss_sbrk_buffer+9657425>, nvars = 12}
        gcpro3 = {next = 0x8d45f6 <bss_sbrk_buffer+762550>, var = 0x287b50, nvars = 2}
#211 0x0056ad05 in For (args=10661158) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x287c18, nvars = 3}
#212 0x0056d59d in eval_sub (form=10629790) at eval.c:2108
        numargs = 12
        args_left = 10629822
        i = 3
        maxargs = 8619034
        argvals = {0, 3, -2147285709, 5690258, 9279730, 13923486, 1, 8698672}
        fun = 8086965
        val = 18153281
        original_fun = 8961578
        original_args = 10629822
        funcar = 109
        gcpro1 = {next = 0x287d78, var = 0x2, nvars = 47}
        gcpro2 = {next = 0x287ca8, var = 0x53d4d5 <extract_number_and_incr+19>, nvars = 2650944}
        gcpro3 = {next = 0x80030533, var = 0x7b5500 <Seq>, nvars = 2653368}
#213 0x0056ae7b in Fprogn (args=10661166) at eval.c:459
        val = 18153281
        gcpro1 = {next = 0xc, var = 0x287d48, nvars = 10485120}
#214 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x287d40
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 74
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2653576}
        gcpro2 = {next = 0x1030530 <bss_sbrk_buffer+8479216>, var = 0x0, nvars = 3}
        sa_count = 74
        sa_must_free = false
#215 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 18152049, 2653736, 2653720, 5562134, -1, 2653768, 0}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 32
        gcpro1 = {next = 0x0, var = 0x0, nvars = 2}
        gcpro2 = {next = 0x20, var = 0x80057e60, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x8020, nvars = 32}
#216 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x287ec8, nvars = 3}
#217 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x287ef8, nvars = 3}
#218 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {9248394, 2653984, 2654040, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2654360
        original_fun = 8961626
        original_args = 10629542
        funcar = 11224192
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x114ff91 <bss_sbrk_buffer+9657425>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2654088}
#219 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x288028, nvars = 9372320}
#220 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x288020
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 71
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2654312}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x288068, nvars = 1}
        sa_count = 71
        sa_must_free = false
#221 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 392, -1, 5683076, 9258806, 2654416, 3, 13976686}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 5562134
        gcpro1 = {next = 0x288138, var = 0x8c3154 <bss_sbrk_buffer+691732>, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 10630358}
        gcpro3 = {next = 0x53d4d5 <extract_number_and_incr+19>, var = 0x2880e0, nvars = 2}
#222 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2881b8, nvars = 4}
#223 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x556709 <Fcar+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2654696}
#224 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 2655452, 2654792, 9280088, 10630438, 2656084, 2654840, 5600859}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x288278, var = 0x288278, nvars = 5564168}
        gcpro2 = {next = 0x3, var = 0x7b65e5 <Sif+5>, nvars = 8086984}
        gcpro3 = {next = 0x8d9a5a <bss_sbrk_buffer+784154>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2654824}
#225 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 8699312}
#226 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x288310
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 67
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x80030511, nvars = 2655064}
        gcpro2 = {next = 0xa234fe <bss_sbrk_buffer+2134462>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2}
        sa_count = 67
        sa_must_free = false
#227 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 2655504
        argvals = {1, 2655444, 2655416, 10485024, 8619034, 1, 2655256, 5600859}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 10485026
        gcpro1 = {next = 0xffffffff, var = 0xd5379e <bss_sbrk_buffer+5477470>, nvars = 9251174}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x8d1e42 <bss_sbrk_buffer+752386>, nvars = 1}
        gcpro3 = {next = 0x9ffd22 <bss_sbrk_buffer+1989090>, var = 0x288aa0, nvars = 2655448}
#228 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x2884dc, var = 0x2884b8, nvars = 10485024}
#229 0x0056f1ce in funcall_lambda (fun=10659942, nargs=3, arg_vector=0x288510) at eval.c:3017
        val = 5596975
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 63
        i = 3
        optional = true
        rest = false
#230 0x0056edbd in apply_lambda (fun=10659942, args=10660966) at eval.c:2899
        args_left = 8619034
        i = 3
        numargs = 3
        arg_vector = 0x288510
        gcpro1 = {next = 0x56dbf1 <eval_sub+2201>, var = 0xab43d0 <bss_sbrk_buffer+2728080>, nvars = 3}
        gcpro2 = {next = 0x80030511, var = 0x2, nvars = 2655784}
        gcpro3 = {next = 0x8004dc84, var = 0x288548, nvars = -2147123653}
        tem = 13973406
        sa_count = 63
        sa_must_free = false
#231 0x0056dbba in eval_sub (form=10660958) at eval.c:2235
        fun = 10659942
        val = 2655832
        original_fun = 8958194
        original_args = 10660966
        funcar = 8689666
        gcpro1 = {next = 0x80030533, var = 0x9ffd20 <bss_sbrk_buffer+1989088>, nvars = 9248322}
        gcpro2 = {next = 0x10, var = 0x0, nvars = 8619034}
        gcpro3 = {next = 0xab43b0 <bss_sbrk_buffer+2728048>, var = 0x8c70aa <bss_sbrk_buffer+707946>, nvars = -1}
#232 0x0056d77c in eval_sub (form=10660950) at eval.c:2145
        numargs = 4
        args_left = 10660990
        i = 0
        maxargs = 1
        argvals = {2655916, 5562134, 18153361, 2655928, 5562175, 18153361, 2656024, 5708278}
        fun = 6371589
        val = 2656056
        original_fun = 8696218
        original_args = 10660990
        funcar = 8619034
        gcpro1 = {next = 0x2886e8, var = 0x54e807 <COMPILEDP+25>, nvars = 10630046}
        gcpro2 = {next = 0x800578a5, var = 0x0, nvars = 0}
        gcpro3 = {next = 0x114ff91 <bss_sbrk_buffer+9657425>, var = 0x2886a0, nvars = 0}
#233 0x0056b8b4 in Flet (args=10661014) at eval.c:888
        temps = 0x288750
        tem = 5564423
        lexenv = 2656216
        elt = 10660942
        varlist = 10661006
        count = 61
        argnum = 1
        gcpro1 = {next = 0x800578a5, var = 0x288760, nvars = 2656152}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 1}
        sa_count = 61
        sa_must_free = false
#234 0x0056d59d in eval_sub (form=10660910) at eval.c:2108
        numargs = 12
        args_left = 10661014
        i = 3
        maxargs = 8619034
        argvals = {33, 5562134, 18153361, 18153361, 2657088, 0, 2656520, 5690304}
        fun = 8087325
        val = 1853321074
        original_fun = 8961866
        original_args = 10661014
        funcar = 5562107
        gcpro1 = {next = 0x288868, var = 0x575100 <Fplist_get+21>, nvars = 2656348}
        gcpro2 = {next = 0x522d5b <directory_file_name+30>, var = 0x114fa31 <bss_sbrk_buffer+9656049>, nvars = 8619034}
        gcpro3 = {next = 0x9ffd82 <bss_sbrk_buffer+1989186>, var = 0x288880, nvars = 32}
#235 0x0056ae7b in Fprogn (args=10661150) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x84b13a <bss_sbrk_buffer+200186>, var = 0x2888d8, nvars = 3}
#236 0x0056addb in Fif (args=10630062) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x288908, nvars = 3}
#237 0x0056d59d in eval_sub (form=10630014) at eval.c:2108
        numargs = 12
        args_left = 10630062
        i = 3
        maxargs = 8619034
        argvals = {18151985, 18153361, 1, 1, 1, -2147285709, 1, 3}
        fun = 8087013
        val = 8619034
        original_fun = 8961626
        original_args = 10630062
        funcar = 0
        gcpro1 = {next = 0x1, var = 0x4, nvars = 8696122}
        gcpro2 = {next = 0x0, var = 0x1150631 <bss_sbrk_buffer+9659121>, nvars = 7629159}
        gcpro3 = {next = 0x7b65e5 <Sif+5>, var = 0x288950, nvars = 2}
#238 0x0056ad05 in For (args=10661158) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x288a18, nvars = 3}
#239 0x0056d59d in eval_sub (form=10629790) at eval.c:2108
        numargs = 12
        args_left = 10629822
        i = 3
        maxargs = 8619034
        argvals = {2, 2659768, -2147285709, 8700144, 9247866, 2657012, 1, 5600859}
        fun = 8086965
        val = 18153361
        original_fun = 8961578
        original_args = 10629822
        funcar = 5562239
        gcpro1 = {next = 0x80057000, var = 0x114fa71 <bss_sbrk_buffer+9656113>, nvars = 1}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0xc, nvars = 18152048}
        gcpro3 = {next = 0x80030533, var = 0xd4535e <bss_sbrk_buffer+5419038>, nvars = -2147123672}
#240 0x0056ae7b in Fprogn (args=10661166) at eval.c:459
        val = 18153361
        gcpro1 = {next = 0xc, var = 0x288b48, nvars = 10485120}
#241 0x0056b9e6 in Flet (args=10629734) at eval.c:918
        temps = 0x288b40
        tem = 8619034
        lexenv = 8619034
        elt = 10485122
        varlist = 8619034
        count = 55
        argnum = 3
        gcpro1 = {next = 0x68, var = 0x3a, nvars = 2657160}
        gcpro2 = {next = 0x17b6670, var = 0x0, nvars = 3}
        sa_count = 55
        sa_must_free = false
#242 0x0056d59d in eval_sub (form=10629646) at eval.c:2108
        numargs = 16
        args_left = 10629734
        i = 4
        maxargs = 8619034
        argvals = {4, 8472888, 2657352, 5465269, 10472225, -1, 8472888, 5707308}
        fun = 8087325
        val = 0
        original_fun = 8961866
        original_args = 10629734
        funcar = 45
        gcpro1 = {next = 0x0, var = 0x0, nvars = 11}
        gcpro2 = {next = 0x2d, var = 0x80057878, nvars = 0}
        gcpro3 = {next = 0x0, var = 0x550c, nvars = 45}
#243 0x0056ae7b in Fprogn (args=10661758) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x288cc8, nvars = 3}
#244 0x0056addb in Fif (args=10629542) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x288cf8, nvars = 3}
#245 0x0056d59d in eval_sub (form=10629534) at eval.c:2108
        numargs = 12
        args_left = 10629542
        i = 3
        maxargs = 8619034
        argvals = {13973406, 2657568, 2657624, 4, 0, 0, 0, 0}
        fun = 8087013
        val = 2657944
        original_fun = 8961626
        original_args = 10629542
        funcar = 11223888
        gcpro1 = {next = 0x2, var = 0x1, nvars = 2}
        gcpro2 = {next = 0x55999f <Flss+32>, var = 0x1150631 <bss_sbrk_buffer+9659121>, nvars = 8958194}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2657672}
#246 0x0056ae7b in Fprogn (args=10661766) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x288e28, nvars = 9372320}
#247 0x0056b9e6 in Flet (args=10629526) at eval.c:918
        temps = 0x288e20
        tem = 8619034
        lexenv = 8619034
        elt = 10629462
        varlist = 8619034
        count = 52
        argnum = 1
        gcpro1 = {next = 0xa2313e <bss_sbrk_buffer+2133502>, var = 0xd5446e <bss_sbrk_buffer+5480750>, nvars = 2657896}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x288e68, nvars = 1}
        sa_count = 52
        sa_must_free = false
#248 0x0056d59d in eval_sub (form=10629454) at eval.c:2108
        numargs = 8
        args_left = 10629526
        i = 2
        maxargs = 8619034
        argvals = {13979198, 396, -1, 2658040, 8689666, 2658000, 3, 8619034}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 10629526
        funcar = 11223840
        gcpro1 = {next = 0x288f48, var = 0x288f50, nvars = 8974914}
        gcpro2 = {next = 0x56d3c0 <eval_sub+104>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8619034}
        gcpro3 = {next = 0x849fda <bss_sbrk_buffer+195738>, var = 0x288ee0, nvars = 2}
#249 0x0056ae7b in Fprogn (args=10661774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x288fb8, nvars = 4}
#250 0x0056ba84 in Fwhile (args=10629286) at eval.c:940
        test = 10629270
        body = 10629350
        gcpro1 = {next = 0x55672f <Fcdr+17>, var = 0xa23696 <bss_sbrk_buffer+2134870>, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2658280}
#251 0x0056d59d in eval_sub (form=10629262) at eval.c:2108
        numargs = 16
        args_left = 10629286
        i = 4
        maxargs = 8619034
        argvals = {8466684, 13979198, 2658376, 5564423, 10630718, 12, 2658424, 5706639}
        fun = 8087349
        val = 8619034
        original_fun = 8961914
        original_args = 10629286
        funcar = 8466684
        gcpro1 = {next = 0x289078, var = 0x289078, nvars = 5564168}
        gcpro2 = {next = 0x557d5a <Fset_default+309>, var = 0x81656c <o_fwd.17941>, nvars = 8087128}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = -1}
#252 0x0056ae7b in Fprogn (args=10661782) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xcef06e <bss_sbrk_buffer+5066030>, nvars = 8699312}
#253 0x0056b9e6 in Flet (args=10630966) at eval.c:918
        temps = 0x289110
        tem = 13976686
        lexenv = 8619034
        elt = 10630782
        varlist = 8619034
        count = 48
        argnum = 2
        gcpro1 = {next = 0xa23526 <bss_sbrk_buffer+2134502>, var = 0x7b65c8 <Sand>, nvars = 2658648}
        gcpro2 = {next = 0xa2363e <bss_sbrk_buffer+2134782>, var = 0xd54e3e <bss_sbrk_buffer+5483262>, nvars = 2}
        sa_count = 48
        sa_must_free = false
#254 0x0056d59d in eval_sub (form=10630766) at eval.c:2108
        numargs = 20
        args_left = 10630966
        i = 5
        maxargs = 8619058
        argvals = {8619034, 13979470, 2658920, 5683733, 38, 9464254, 2658856, 1}
        fun = 8087325
        val = 13979198
        original_fun = 8961866
        original_args = 10630966
        funcar = 8477804
        gcpro1 = {next = 0x815ebc <o_fwd.60737>, var = 0x836e00 <bss_sbrk_buffer+117440>, nvars = 8478396}
        gcpro2 = {next = 0x8, var = 0x88be42 <bss_sbrk_buffer+465666>, nvars = 6}
        gcpro3 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x2, nvars = 608}
#255 0x0056ae7b in Fprogn (args=10661854) at eval.c:459
        val = 13979198
        gcpro1 = {next = 0x5, var = 0x2892d8, nvars = 10485024}
#256 0x0056f1ce in funcall_lambda (fun=10659942, nargs=1, arg_vector=0x2893ac) at eval.c:3017
        val = 5564450
        syms_left = 8619034
        next = 10485026
        lexenv = 8619034
        count = 44
        i = 1
        optional = true
        rest = false
#257 0x0056ebc5 in Ffuncall (nargs=2, args=0x2893a8) at eval.c:2851
        fun = 10659942
        original_fun = 8958194
        funcar = 8689666
        numargs = 1
        lisp_numargs = 8613376
        val = 2659224
        internal_args = 0x83841a <bss_sbrk_buffer+123098>
        i = 8619058
#258 0x0056e429 in call1 (fn=8958194, arg1=18155057) at eval.c:2589
        ret_ungc_val = 8961528
        gcpro1 = {next = 0x80057878, var = 0x8002d200, nvars = 2}
        args = {8958194, 18155057}
#259 0x005916f5 in readevalloop (readcharfun=-2147298811, stream=0x0, sourcename=18155057, printflag=false, unibyte=8619034, readfun=8619034, start=8619034, end=8619034) at lread.c:1777
        c = 8619034
        val = 8619034
        count = 39
        gcpro1 = {next = 0x289448, var = 0x56f670 <specbind+573>, nvars = 8957954}
        gcpro2 = {next = 0x88b000 <bss_sbrk_buffer+462016>, var = 0x1, nvars = 11223664}
        gcpro3 = {next = 0x834620 <bss_sbrk_buffer+107232>, var = 0x5, nvars = 8646430}
        gcpro4 = {next = 0x5, var = 0x289418, nvars = 5302084}
        b = 0x8002d200
        continue_reading_p = false
        lex_bound = 8619034
        whole_buffer = false
        first_sexp = true
        macroexpand = 9053642
#260 0x00591ccf in Feval_buffer (buffer=-2147298811, printflag=8619034, filename=18155057, unibyte=8619034, do_allow_print=8619058) at lread.c:1934
        count = 35
        tem = 8619034
        buf = -2147298811
#261 0x0056d8fc in eval_sub (form=9464094) at eval.c:2174
        numargs = 20
        args_left = 8619034
        i = 8619034
        maxargs = 8619058
        argvals = {-2147298811, 8619034, 18155057, 8619034, 8619058, -2147125128, 2659608, 5600833}
        fun = 8091365
        val = 8619034
        original_fun = 8710362
        original_args = 9464086
        funcar = 8961122
        gcpro1 = {next = 0x289518, var = 0x289518, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x54e708 <BUFFER_OBJFWDP+17>, nvars = 8478396}
        gcpro3 = {next = 0x815c6c <o_fwd.65045>, var = 0x2894d0, nvars = 5}
#262 0x0056ae7b in Fprogn (args=9464014) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8699480}
#263 0x0056b9e6 in Flet (args=9464374) at eval.c:918
        temps = 0x2895b0
        tem = 8619034
        lexenv = 8619034
        elt = 9464398
        varlist = 8619034
        count = 31
        argnum = 3
        gcpro1 = {next = 0xd42b3e <bss_sbrk_buffer+5408766>, var = 0xc, nvars = 2659832}
        gcpro2 = {next = 0xd4236e <bss_sbrk_buffer+5406766>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 3}
        sa_count = 31
        sa_must_free = false
#264 0x0056d59d in eval_sub (form=9464454) at eval.c:2108
        numargs = 12
        args_left = 9464374
        i = 3
        maxargs = -2147125128
        argvals = {9464526, 12, 2660008, 2660000, 8619034, 5833170, 2660088, 5693408}
        fun = 8087325
        val = 2660104
        original_fun = 8961866
        original_args = 9464374
        funcar = 8480108
        gcpro1 = {next = 0x2896e8, var = 0x557d5a <Fset_default+309>, nvars = 8480108}
        gcpro2 = {next = 0x2896a8, var = 0x54de23 <XSETCDR+17>, nvars = 9464526}
        gcpro3 = {next = 0x3, var = 0x2896a0, nvars = 8}
#265 0x0056be0a in Funwind_protect (args=9464006) at eval.c:1150
        val = 2660152
        count = 29
#266 0x0056d59d in eval_sub (form=9464462) at eval.c:2108
        numargs = 8
        args_left = 9464006
        i = 2
        maxargs = -2147125128
        argvals = {8479980, 1, 2660296, 4783953, 18155057, 10228834, 8619058, 14}
        fun = 8087445
        val = 8619034
        original_fun = 8962010
        original_args = 9464006
        funcar = 8961122
        gcpro1 = {next = 0x2897c8, var = 0x2897c8, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x8f37a1 <bss_sbrk_buffer+889953>, nvars = 5562134}
        gcpro3 = {next = 0x0, var = 0x0, nvars = 0}
#267 0x0056ae7b in Fprogn (args=9463934) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xe, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8980104}
#268 0x0056b710 in FletX (args=9464654) at eval.c:848
        varlist = 8619034
        var = 8980106
        val = 168
        elt = 9464718
        lexenv = 8619034
        count = 25
        gcpro1 = {next = 0x2898a8, var = 0x57138f <Flength+328>, nvars = 8619034}
        gcpro2 = {next = 0x54e807 <COMPILEDP+25>, var = 0x906b4e <bss_sbrk_buffer+968718>, nvars = 12}
        gcpro3 = {next = 0x0, var = 0x289840, nvars = 2660472}
#269 0x0056d59d in eval_sub (form=9464862) at eval.c:2108
        numargs = 28
        args_left = 9464654
        i = 7
        maxargs = -2147125128
        argvals = {8470704, 0, 0, 2660985, 427, 373, 0, 427}
        fun = 8087301
        val = 0
        original_fun = 8961890
        original_args = 9464654
        funcar = 14
        gcpro1 = {next = 0x7779fc2a <ntdll!ZwSetInformationFile+18>, var = 0x610375db <fhandler_base::lseek(long long, int)+315>, nvars = 824}
        gcpro2 = {next = 0x0, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 5562134}
        gcpro3 = {next = 0x3b, var = 0xdc28a5 <bss_sbrk_buffer+5932389>, nvars = 8470740}
#270 0x0056ae7b in Fprogn (args=9461582) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x0, var = 0x2899b8, nvars = 3}
#271 0x0056addb in Fif (args=9464982) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x2899e8, nvars = 3}
#272 0x0056d59d in eval_sub (form=9465022) at eval.c:2108
        numargs = 12
        args_left = 9464982
        i = 3
        maxargs = -2147125128
        argvals = {8478396, 539831584, 1953720684, 543584032, 1296647500, 1766598688, 1918988898, 1718558841}
        fun = 8087013
        val = 8478396
        original_fun = 8961626
        original_args = 9464982
        funcar = 8478396
        gcpro1 = {next = 0x289a78, var = 0x289a78, nvars = 5564168}
        gcpro2 = {next = 0x74654d20, var = 0x29646f68, nvars = 757738784}
        gcpro3 = {next = 0x616d4520, var = 0x49207363, nvars = 1953853550}
#273 0x0056ae7b in Fprogn (args=9461470) at eval.c:459
        val = 9396529
        gcpro1 = {next = 0xb097eb0d, var = 0xd38c26 <bss_sbrk_buffer+5368038>, nvars = 8961528}
#274 0x0056f1ce in funcall_lambda (fun=9461374, nargs=4, arg_vector=0x289c10) at eval.c:3017
        val = 1967658040
        syms_left = 8619034
        next = 9565522
        lexenv = 8619034
        count = 18
        i = 4
        optional = true
        rest = false
#275 0x0056ebc5 in Ffuncall (nargs=5, args=0x289c0c) at eval.c:2851
        fun = 9461374
        original_fun = 9565450
        funcar = 8689666
        numargs = 4
        lisp_numargs = 0
        val = 5
        internal_args = 0x1150631 <bss_sbrk_buffer+9659121>
        i = 5
#276 0x0056e4e9 in call4 (fn=9565450, arg1=18155057, arg2=18155057, arg3=8619058, arg4=8619058) at eval.c:2638
        ret_ungc_val = 0
        gcpro1 = {next = 0x656d2065, var = 0x200, nvars = 5}
        args = {9565450, 18155057, 18155057, 8619058, 8619058}
#277 0x005908bb in Fload (file=18155073, noerror=8619058, nomessage=8619058, nosuffix=8619058, must_suffix=8619034) at lread.c:1284
        val = 8665885
        stream = 0x80057878
        fd = 18155057
        count = 13
        gcpro1 = {next = 0x843b18 <bss_sbrk_buffer+169944>, var = 0x843b18 <bss_sbrk_buffer+169944>, nvars = 11136830}
        gcpro2 = {next = 0x54dfb8 <SBYTES+25>, var = 0x1, nvars = 188}
        gcpro3 = {next = 0x289d10, var = 0x2, nvars = 100}
        found = 18155057
        efound = 5562697
        hist_file_name = 18155057
        newer = false
        compiled = false
        handler = 2661800
        safe_p = true
        fmode = 0x7d1614 <DEFAULT_REHASH_SIZE+204> "r"
        tmp = {1, 5562602}
        version = 0
#278 0x0056d8fc in eval_sub (form=11136846) at eval.c:2174
        numargs = 16
        args_left = 8619034
        i = 8619058
        maxargs = 8619034
        argvals = {18155073, 8619058, 8619058, 8619058, 8619034, 8665885, 8467308, 0}
        fun = 8091317
        val = 8465628
        original_fun = 8710338
        original_args = 11136822
        funcar = 8465628
        gcpro1 = {next = 0x289e38, var = 0x289e38, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x22, nvars = 8467272}
        gcpro3 = {next = 0x289e1c, var = 0x289df0, nvars = 5}
#279 0x0056ae7b in Fprogn (args=11136790) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0x1156171 <bss_sbrk_buffer+9682481>, nvars = 8962384}
#280 0x0056b9e6 in Flet (args=11136854) at eval.c:918
        temps = 0x289ed0
        tem = 18009249
        lexenv = 13863974
        elt = 11136878
        varlist = 8619034
        count = 11
        argnum = 1
        gcpro1 = {next = 0x836e00 <bss_sbrk_buffer+117440>, var = 0x849b02 <bss_sbrk_buffer+194498>, nvars = 2662168}
        gcpro2 = {next = 0xa9efae <bss_sbrk_buffer+2641006>, var = 0xffffffff, nvars = 1}
        sa_count = 11
        sa_must_free = false
#281 0x0056d59d in eval_sub (form=11136886) at eval.c:2108
        numargs = 8
        args_left = 11136854
        i = 2
        maxargs = 8619034
        argvals = {18155137, 18009249, 8619034, 5680763, 10896430, 18009249, 2662344, 5596975}
        fun = 8087325
        val = 8619034
        original_fun = 8961866
        original_args = 11136854
        funcar = 18009249
        gcpro1 = {next = 0x28a058, var = 0x56ba15 <Flet+746>, nvars = 10}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0xa6443e <bss_sbrk_buffer+2400510>, nvars = 8619034}
        gcpro3 = {next = 0x1156171 <bss_sbrk_buffer+9682481>, var = 0x289f90, nvars = 3}
#282 0x0056ad05 in For (args=11136782) at eval.c:359
        val = 8619034
        gcpro1 = {next = 0x7b65b0 <Sor>, var = 0x28a058, nvars = 2}
#283 0x0056d59d in eval_sub (form=11136966) at eval.c:2108
        numargs = 8
        args_left = 11136894
        i = 2
        maxargs = 8619034
        argvals = {10851906, 10472225, 9947014, 8619034, -1, 8619034, 8619034, 8619034}
        fun = 8086965
        val = 8619034
        original_fun = 8961578
        original_args = 11136894
        funcar = 1634559279
        gcpro1 = {next = 0x20, var = 0x0, nvars = 1836017711}
        gcpro2 = {next = 0x5239d6 <Fexpand_file_name+2113>, var = 0x1150731 <bss_sbrk_buffer+9659377>, nvars = 8696074}
        gcpro3 = {next = 0x54df2c <SSDATA+17>, var = 0x20, nvars = 2662872}
#284 0x0056ae7b in Fprogn (args=11136774) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0x707369 <pure+995465>, var = 0x0, nvars = 5}
#285 0x0056ba84 in Fwhile (args=10896526) at eval.c:940
        test = 9248418
        body = 10896478
        gcpro1 = {next = 0x0, var = 0x0, nvars = 8087344}
        gcpro2 = {next = 0x83841a <bss_sbrk_buffer+123098>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 2662688}
#286 0x0056d59d in eval_sub (form=10896534) at eval.c:2108
        numargs = 20
        args_left = 10896526
        i = 5
        maxargs = 8619034
        argvals = {8478396, 13864070, 2662952, 5572657, 13864070, 8619034, 2662952, 4}
        fun = 8087349
        val = 8478396
        original_fun = 8961914
        original_args = 10896526
        funcar = 8478396
        gcpro1 = {next = 0x28a238, var = 0x28a238, nvars = 5564168}
        gcpro2 = {next = 0x0, var = 0x8c7d31 <bss_sbrk_buffer+711153>, nvars = 18009729}
        gcpro3 = {next = 0x84a272 <bss_sbrk_buffer+196402>, var = 0xa557a6 <bss_sbrk_buffer+2339942>, nvars = 8619034}
#287 0x0056ae7b in Fprogn (args=11136718) at eval.c:459
        val = 8619034
        gcpro1 = {next = 0xc, var = 0xa557a6 <bss_sbrk_buffer+2339942>, nvars = 8961528}
#288 0x0056b9e6 in Flet (args=10896542) at eval.c:918
        temps = 0x28a2d0
        tem = 8619034
        lexenv = 13863974
        elt = 9053666
        varlist = 8619034
        count = 7
        argnum = 3
        gcpro1 = {next = 0xa646b6 <bss_sbrk_buffer+2401142>, var = 0x838432 <bss_sbrk_buffer+123122>, nvars = 2663192}
        gcpro2 = {next = 0xd38c86 <bss_sbrk_buffer+5368134>, var = 0x28a348, nvars = 3}
        sa_count = 7
        sa_must_free = false
#289 0x0056d59d in eval_sub (form=10896630) at eval.c:2108
        numargs = 8
        args_left = 10896542
        i = 2
        maxargs = 2663952
        argvals = {8968674, 9725026, 13864070, 2663792, 0, 31653888, 3473465, 31653888}
        fun = 8087325
        val = 13864070
        original_fun = 8961866
        original_args = 10896542
        funcar = 31653888
        gcpro1 = {next = 0x0, var = 0x28a3fc, nvars = 2005206902}
        gcpro2 = {next = 0xfeeefeee, var = 0x1e30000, nvars = 31775352}
        gcpro3 = {next = 0x7780a5fb <ntdll!RtlUlonglongByteSwap+53675>, var = 0x28a390, nvars = 3}
#290 0x0056ae7b in Fprogn (args=11091854) at eval.c:459
        val = 13864070
        gcpro1 = {next = 0x850fde <bss_sbrk_buffer+224414>, var = 0x28a458, nvars = 11}
#291 0x0056addb in Fif (args=11222926) at eval.c:410
        cond = 8619034
        gcpro1 = {next = 0x7b65e0 <Sif>, var = 0x28a488, nvars = 11}
#292 0x0056d59d in eval_sub (form=11222934) at eval.c:2108
        numargs = 44
        args_left = 11222926
        i = 11
        maxargs = 2663952
        argvals = {8478396, 2664848, 2663572, 4, 2664096, 2004840917, 396544381, 1996909470}
        fun = 8087013
        val = 8478396
        original_fun = 8961626
        original_args = 11222926
        funcar = 8478396
        gcpro1 = {next = 0x28a518, var = 0x28a518, nvars = 5564168}
        gcpro2 = {next = 0x18a4, var = 0x28a6b0, nvars = 2004484189}
        gcpro3 = {next = 0x7707ef9d <KERNELBASE!CheckTokenMembership+2167>, var = 0x32c, nvars = 6952}
#293 0x0056ae7b in Fprogn (args=10953926) at eval.c:459
        val = 9129921
        gcpro1 = {next = 0x10003, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8961528}
#294 0x0056f1ce in funcall_lambda (fun=10953766, nargs=0, arg_vector=0x28a610) at eval.c:3017
        val = 5706672
        syms_left = 8619034
        next = 2664304
        lexenv = 10835878
        count = 4
        i = 0
        optional = false
        rest = false
#295 0x0056edbd in apply_lambda (fun=10953758, args=8619034) at eval.c:2899
        args_left = 8619034
        i = 0
        numargs = 0
        arg_vector = 0x28a610
        gcpro1 = {next = 0x5ecee1 <calloc+59>, var = 0x8004dd40, nvars = 0}
        gcpro2 = {next = 0x1e4d638, var = 0x1, nvars = 2664040}
        gcpro3 = {next = 0xffe5f000, var = 0x0, nvars = 0}
        tem = 2665344
        sa_count = 4
        sa_must_free = false
#296 0x0056dbba in eval_sub (form=9944750) at eval.c:2235
        fun = 10953758
        val = 8619034
        original_fun = 11281130
        original_args = 8619034
        funcar = 8961290
        gcpro1 = {next = 0x28a718, var = 0x836e01 <bss_sbrk_buffer+117441>, nvars = 5}
        gcpro2 = {next = 0x61004d43 <cygthread::create()@4+403>, var = 0x28ab80, nvars = 0}
        gcpro3 = {next = 0x815ebc <o_fwd.60737>, var = 0x83841a <bss_sbrk_buffer+123098>, nvars = 8613376}
#297 0x0056d202 in Feval (form=9944750, lexical=8619034) at eval.c:1993
        count = 2
#298 0x004f03b7 in top_level_2 () at keyboard.c:1173
No locals.
#299 0x0056c136 in internal_condition_case (bfun=0x4f039a <top_level_2>, handlers=8689762, hfun=0x4effff <cmd_error>) at eval.c:1289
        val = 0
        c = {tag = 8619034, val = 8619034, next = 0x28a908, gcpro = 0x0, jmp = {2664404, 2665344, 32, 11223088, 0, 1, 2664648, 2664352, 5685457, 5439531, 2818091, 2686740, 2677272, 2818091, 2686740, 2664796, -2147164704, 2664744, 0, 14, 0, 0, 2664908, -2147171666, 2664500, 2, 1629103712, 0, 1, 2664792, 1628480791, 1629103712, 0, 2664848, 2664832, 2686740, -2147164672, 2664632, 982645838, -2147171666, 2664564, 1629103712, 0, 0, 0, 1, 2664792, 2664528, 1628480743, 5439531, 2818091, 2686740}, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
        h = {handler = 8689762, var = 8619034, chosen_clause = 2686740, tag = 0x28a7c4, next = 0x0}
#300 0x004f03eb in top_level_1 (ignore=8619034) at keyboard.c:1181
No locals.
#301 0x0056bc9c in internal_catch (tag=8687834, func=0x4f03b9 <top_level_1>, arg=8619034) at eval.c:1063
        c = {tag = 8687834, val = 8619034, next = 0x0, gcpro = 0x0, jmp = {2664728, 2665344, 32, 11223088, 0, 1, 2664968, 2664688, 5684365, 5439531, 2818091, 2686740, 2677272, 0, -2147289248, 0, 2664888, 1628481649, 1629103712, 0, 2664888, 5599614, 8237784, 1, 0, 6214653, 0, 0, 0, 0, 0, 0, 2, 0, -2147283968, 686215800, 2664888, 2664888, 5564168, 11223072, 2664968, 5601931, 8237784, 8619034, 8613376, 5996542, 2665344, 0, 2664968, 8613377, 5, 5}, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
#302 0x004f031f in command_loop () at keyboard.c:1142
No locals.
#303 0x004efc7b in recursive_edit_1 () at keyboard.c:776
        count = 1
        val = 2665112
#304 0x004efdb7 in Frecursive_edit () at keyboard.c:840
        count = 0
        buffer = 8619034
#305 0x004ee375 in main (argc=11, argv=0x28ab80) at emacs.c:1550
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = false
        dumping = false
        skip_args = 2
        rlim = {rlim_cur = 2097082, rlim_max = 2097152}
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x28ab98 ".\254("
[Thread 6952.0x186c exited with code 3221225477]
[Thread 6952.0x1574 exited with code 3221225477]
[Thread 6952.0x1bd4 exited with code 3221225477]
[Thread 6952.0x174c exited with code 3221225477]
[Inferior 1 (process 6952) exited with code 030000000005]

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 16:24:02 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: jan.h.d@swipnet.se, 14569@debbugs.gnu.org,
>         Paul Eggert <eggert@cs.ucla.edu>
> 
> After that there were many compile failures with errors like those that 
> others have reported:
> 
> Compiling gnus/gnus-cache.el
> GLib (gthread-posix.c): Unexpected error from C library during 
> 'pthread_setspecific': Invalid argument.  Aborting.
> Makefile:254: recipe for target `gnus/gnus-cache.elc' failed
> 
> But these compilations didn't invoke gdb, apparently because they 
> involved Makefile targets other than compile-onefile.

No, I think these failures didn't go through 'abort', that's why you
didn't get the backtrace.  You need to look at the pthread sources in
the file mentioned, and find out where to put the breakpoint to catch
that error.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/19/2013 10:45 PM, Eli Zaretskii wrote:
>> Date: Wed, 19 Jun 2013 16:24:02 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: jan.h.d@swipnet.se, 14569@debbugs.gnu.org,
>>          Paul Eggert <eggert@cs.ucla.edu>
>>
>> After that there were many compile failures with errors like those that
>> others have reported:
>>
>> Compiling gnus/gnus-cache.el
>> GLib (gthread-posix.c): Unexpected error from C library during
>> 'pthread_setspecific': Invalid argument.  Aborting.
>> Makefile:254: recipe for target `gnus/gnus-cache.elc' failed
>>
>> But these compilations didn't invoke gdb, apparently because they
>> involved Makefile targets other than compile-onefile.
>
> No, I think these failures didn't go through 'abort', that's why you
> didn't get the backtrace.  You need to look at the pthread sources in
> the file mentioned, and find out where to put the breakpoint to catch
> that error.

The error message comes from 'g_thread_abort', which calls 'abort'.  The 
reason there was no backtrace is exactly what I said.  I know that's the 
case because I removed the "@" at the beginning of the Makefile rule so 
that the command would get echoed, but it didn't get echoed in the 
compilation above (and others like it).  On the other hand, it did get 
echoed in the SIGSEGV examples that I mentioned in my previous mail.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 23:00:36 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: jan.h.d@swipnet.se, 14569@debbugs.gnu.org, eggert@cs.ucla.edu
> 
> On 6/19/2013 10:45 PM, Eli Zaretskii wrote:
> >> Date: Wed, 19 Jun 2013 16:24:02 -0400
> >> From: Ken Brown <kbrown@cornell.edu>
> >> CC: jan.h.d@swipnet.se, 14569@debbugs.gnu.org,
> >>          Paul Eggert <eggert@cs.ucla.edu>
> >>
> >> After that there were many compile failures with errors like those that
> >> others have reported:
> >>
> >> Compiling gnus/gnus-cache.el
> >> GLib (gthread-posix.c): Unexpected error from C library during
> >> 'pthread_setspecific': Invalid argument.  Aborting.
> >> Makefile:254: recipe for target `gnus/gnus-cache.elc' failed
> >>
> >> But these compilations didn't invoke gdb, apparently because they
> >> involved Makefile targets other than compile-onefile.
> >
> > No, I think these failures didn't go through 'abort', that's why you
> > didn't get the backtrace.  You need to look at the pthread sources in
> > the file mentioned, and find out where to put the breakpoint to catch
> > that error.
> 
> The error message comes from 'g_thread_abort', which calls 'abort'.  The 
> reason there was no backtrace is exactly what I said.  I know that's the 
> case because I removed the "@" at the beginning of the Makefile rule so 
> that the command would get echoed, but it didn't get echoed in the 
> compilation above (and others like it).  On the other hand, it did get 
> echoed in the SIGSEGV examples that I mentioned in my previous mail.

Sorry, I forgot that there's one more rule:

  # An old-fashioned suffix rule, which, according to the GNU Make manual,
  # cannot have prerequisites.
  .el.elc:
	  @echo Compiling $<
	  @# The BIG_STACK_OPTS are only needed to byte-compile the byte-compiler
	  @# files, which is normally done in compile-first, but may also be
	  @# recompiled via this rule.
	  @$(emacs) $(BYTE_COMPILE_FLAGS) \
		  -f batch-byte-compile $<

Instrument it in the same way, and you should be able to catch the
other problems as well.

Thanks.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

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

On 6/20/2013 11:54 AM, Eli Zaretskii wrote:
> Sorry, I forgot that there's one more rule:
>
>    # An old-fashioned suffix rule, which, according to the GNU Make manual,
>    # cannot have prerequisites.
>    .el.elc:
> 	  @echo Compiling $<
> 	  @# The BIG_STACK_OPTS are only needed to byte-compile the byte-compiler
> 	  @# files, which is normally done in compile-first, but may also be
> 	  @# recompiled via this rule.
> 	  @$(emacs) $(BYTE_COMPILE_FLAGS) \
> 		  -f batch-byte-compile $<
>
> Instrument it in the same way, and you should be able to catch the
> other problems as well.

Thanks.  I've now got some further backtraces, this time involving glib. 
  I'm using glib-2.34.3, which I compiled without optimization.  There 
are two kinds of problems, in addition to the gmalloc.c crashes that I 
mentioned earlier.

1. When the 'abort' breakpoint is hit, the backtrace (abbreviated) looks 
like this:

#0  0x6acdb0f8 in abort from /usr/bin/cygglib-2.0-0.dll
#1  0x6acd6eb0 in g_thread_abort at gthread-posix.c:76
#2  0x6acd7758 in g_private_set at gthread-posix.c:1026
#3  0x6acb9fc2 in g_thread_self at gthread.c:1003
#4  0x6ac93ee3 in g_main_context_iteration at gmain.c:3351
#5  0x6ac956ea in glib_worker_main at gmain.c:5028
#6  0x6acb9d29 in g_thread_proxy at gthread.c:797
#7  0x610ffe1a in pthread::thread_init_wrapper(void*)@4 at 
cygwin/thread.cc:1947
#8  0x6108974c in thread_wrapper at cygwin/miscfuncs.cc:600

A full backtrace of all threads is attached.

2. There is sometimes a SIGSEGV in g_slist_remove (in the main thread), 
with an abbreviated backtrace like this:

#0  0x6acb06dc in g_slist_remove at gslist.c:418
#1  0x6ac951f8 in g_child_watch_finalize at gmain.c:4580
#2  0x6ac928fa in g_source_unref_internal at gmain.c:1825
#3  0x6ac929fc in g_source_unref at gmain.c:1870
#4  0x005b371e in init_process_emacs at process.c:7100
#5  0x004ee1fc in main at emacs.c:1471

Again, a full backtrace of all threads is attached.

I don't know enough about glib to do much with this.  Jan or Paul, can 
you help?  Jan, if you want to install my unoptimized build of glib with 
debugging symbols, you can get it from my personal Cygwin repository:

   http://sanibeltranquility.com/cygwin/

There are instructions on that page.  You would need to install 
glib2.0-debuginfo, libglib2.0-devel, and libglib2.0_0.  You also need 
cygwin-debuginfo (from a regular Cygwin mirror).

Ken

[-- Attachment #2: backtrace_abort.txt --]
[-- Type: text/plain, Size: 7090 bytes --]

Compiling gnus/mml-sec.el
EMACSLOADPATH=/home/kbrown/src/emacs/test/lisp LC_ALL=C gdb --batch --return-child-result -ex 'b abort' -ex run -ex 'thread apply all bt full' -ex cont --args /home/kbrown/src/emacs/test/src/emacs -batch --no-site-file --no-site-lisp   \
	-f batch-byte-compile gnus/mml-sec.el
Breakpoint 1 at 0x60f738
[New Thread 8556.0x1f98]
[New Thread 8556.0x1f90]
[New Thread 8556.0x3f0]
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.
[New Thread 8556.0x17b0]
[Switching to Thread 8556.0x17b0]

Breakpoint 1, 0x6acdb0f8 in abort () from /usr/bin/cygglib-2.0-0.dll

Thread 4 (Thread 8556.0x17b0):
#0  0x6acdb0f8 in abort () from /usr/bin/cygglib-2.0-0.dll
No symbol table info available.
#1  0x6acd6eb0 in g_thread_abort (status=22, function=0x6ad2e165 <__PRETTY_FUNCTION__.9527+350> "pthread_setspecific") at /usr/src/debug/glib2.0-2.34.3-2/glib/gthread-posix.c:76
No locals.
#2  0x6acd7758 in g_private_set (key=0x6acdc258 <g_thread_specific_private>, value=0x8002e7a0) at /usr/src/debug/glib2.0-2.34.3-2/glib/gthread-posix.c:1026
        status = 22
#3  0x6acb9fc2 in g_thread_self () at /usr/src/debug/glib2.0-2.34.3-2/glib/gthread.c:1003
        thread = 0x8002e7a0
#4  0x6ac93ee3 in g_main_context_iteration (context=0x80030c00, may_block=1) at /usr/src/debug/glib2.0-2.34.3-2/glib/gmain.c:3351
        retval = 0
#5  0x6ac956ea in glib_worker_main (data=0x0) at /usr/src/debug/glib2.0-2.34.3-2/glib/gmain.c:5028
No locals.
#6  0x6acb9d29 in g_thread_proxy (data=0x8005ce00) at /usr/src/debug/glib2.0-2.34.3-2/glib/gthread.c:797
        thread = 0x8005ce00
        __PRETTY_FUNCTION__ = "g_thread_proxy"
#7  0x610ffe1a in pthread::thread_init_wrapper(void*)@4 (arg=0x8001b700) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/thread.cc:1947
        thread = 0x8001b700
        __PRETTY_FUNCTION__ = "static DWORD pthread::thread_init_wrapper(void*)"
        ret = <optimized out>
#8  0x6108974c in thread_wrapper (arg=0x0) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/miscfuncs.cc:600
        dealloc_addr = <optimized out>
        count = <optimized out>
        wrapper_arg = {func = 0x0, arg = 0x0, stackaddr = 0x0, stackbase = 0x0, stacklimit = 0x0}
        old_start = 0x0
#9  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 8556.0x3f0):
#0  0x7727013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7727013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x772a2f51 in ntdll!RtlMoveMemory () from /c/windows/system32/ntdll.dll
No symbol table info available.
#3  0x00000001 in ?? ()
No symbol table info available.
#4  0x00000001 in ?? ()
No symbol table info available.
#5  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 8556.0x1f90):
#0  0x7726f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7726f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x7518dd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000090 in ?? ()
No symbol table info available.
#4  0x751e3f07 in ReadFile () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#5  0x00000090 in ?? ()
No symbol table info available.
#6  0x610de6be in wait_sig () at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/sigproc.cc:1229
        nb = 0
        q = <optimized out>
        pack = {si = {si_signo = 0, si_code = 0, si_pid = 0, si_uid = 0, si_errno = 0, {__pad = {0 <repeats 32 times>}, _si_commune = {_si_code = 0, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {_si_fd = 0, _si_pipe_fhandler = 0x0, _si_str = 0x0}}, {{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0, sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0, si_stime = 0}, si_addr = 0x0, {__pad2 = {0 <repeats 31 times>}, si_cyg = 0x0}}}, pid = 0, sigtls = 0x0, mask = 0x0, {wakeup = 0x0, thread_handle = 0x0, next = 0x0}}
        dummy_mask = 0
        clearwait = <optimized out>
        sig_held = false
        __PRETTY_FUNCTION__ = "void wait_sig(void*)"
#7  0x61004a05 in cygthread::callfunc(bool)@8 (this=0x6118d880 <threads>, issimplestub=<optimized out>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:51
        pass_arg = 0x6118d880 <threads>
#8  0x61004f8f in cygthread::stub(void*)@4 (arg=0x6118d880 <threads>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:93
        notify = <optimized out>
        info = 0x6118d880 <threads>
        __PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#9  0x61005d1d in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*)@16 (this=<optimized out>, func=0x61004f40 <cygthread::stub(void*)@4>, arg=0x6118d880 <threads>, buf=0x61005ebb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#10 0x053aff88 in ?? ()
No symbol table info available.
#11 0x751e33aa in KERNEL32!BaseThreadInitThunk () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#12 0x77289ef2 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#13 0x77289ec5 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 8556.0x1f98):
#0  SYMBOL_NAME (sym=13705938) at lisp.h:1502
No locals.
#1  0x00595657 in oblookup (obarray=8744973, ptr=0x7d384c <DEFAULT_REHASH_SIZE+1044> ":keepalive", size=10, size_byte=10) at lread.c:3905
        hash = 362
        obsize = 1511
        tail = 13705938
        bucket = 13705938
        tem = 5562448
#2  0x005951bc in intern_c_string_1 (str=0x7d384c <DEFAULT_REHASH_SIZE+1044> ":keepalive", len=10) at lread.c:3715
        obarray = 8744973
        tem = 2730680
#3  0x0054efc2 in intern_c_string (str=0x7d384c <DEFAULT_REHASH_SIZE+1044> ":keepalive") at lisp.h:3675
No locals.
#4  0x005b3a9c in init_process_emacs () at process.c:7171
        subfeatures = 7320166
        sopt = 0x7d38a8 <socket_options+40>
        i = 64
#5  0x004ee1fc in main (argc=7, argv=0x29abf0) at emacs.c:1471
        dummy = 1
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = false
        dumping = false
        skip_args = 2
        rlim = {rlim_cur = 2097082, rlim_max = 2097152}
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x772801e2 <ntdll!LdrGetProcedureAddress+24> "]\302\020"

Breakpoint 1, abort () at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/signal.cc:362
362	{
error return /netrel/src/gdb-7.6.50-2/gdb/windows-nat.c:1289 was 5
error return /netrel/src/gdb-7.6.50-2/gdb/windows-nat.c:1289 was 5
Makefile:253: recipe for target `gnus/mml-sec.elc' failed
make[2]: *** [gnus/mml-sec.elc] Error 255

[-- Attachment #3: backtrace_segv.txt --]
[-- Type: text/plain, Size: 7285 bytes --]

EMACSLOADPATH=/home/kbrown/src/emacs/test/lisp LC_ALL=C gdb --batch --return-child-result -ex 'b abort' -ex run -ex 'thread apply all bt full' -ex cont --args /home/kbrown/src/emacs/test/src/emacs -batch --no-site-file --no-site-lisp   \
	-f batch-byte-compile org/org-agenda.el
[New Thread 5832.0x17ac]

Program received signal SIGSEGV, Segmentation fault.
0x6acb06dc in g_slist_remove (list=0x80050c30, data=0x8005cf00) at /usr/src/debug/glib2.0-2.34.3-2/glib/gslist.c:418
418	      if (tmp->data == data)

Thread 4 (Thread 5832.0x17ac):
#0  dtable::select_read (this=0x61274c14, fd=3, ss=0xfff4cb08) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/dtable.cc:788
No locals.
#1  0x610d40f1 in select_stuff::test_and_set (this=0xfff4cb08, i=3, readfds=0xfff4cc30, writefds=0xfff4cc10, exceptfds=0xfff4cbf0) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:319
        s = 0x8005cdc0
#2  0x610d4947 in select (maxfds=4, readfds=0xfff4cc30, writefds=0xfff4cc10, exceptfds=0xfff4cbf0, ms=4294967295) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:153
        i = <optimized out>
        start_time = <optimized out>
        w = 0xfff4ca80
        e = 0xfff4ca60
        __PRETTY_FUNCTION__ = "int select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, DWORD)"
        res = <optimized out>
        sel = {return_on_signal = false, always_ready = false, windows_used = false, start = {fd = 0, h = 0x0, fh = 0x0, thread_errno = 0, windows_handle = false, read_ready = false, write_ready = false, except_ready = false, read_selected = false, write_selected = false, except_selected = false, except_on_write = false, startup = 0x2, peek = 0x0, verify = 0xfff4cac4, cleanup = 0x8002e780, next = 0x8005cdc0}, device_specific_pipe = 0x0, device_specific_socket = 0x0, device_specific_serial = 0x0, device_specific_mailslot = 0x0}
        r = 0xfff4caa0
#3  0x610d501f in cygwin_select (maxfds=4, readfds=0xfff4cc30, writefds=0xfff4cc10, exceptfds=0xfff4cbf0, to=0x0) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/select.cc:122
        ms = <optimized out>
        __PRETTY_FUNCTION__ = "int cygwin_select(int, _types_fd_set*, _types_fd_set*, _types_fd_set*, timeval*)"
        res = <optimized out>
#4  0x610b5b37 in poll (fds=0x80050c30, nfds=1, timeout=-1) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/poll.cc:85
        invalid_fds = <optimized out>
        read_fds = 0xfff4cc30
        write_fds = 0xfff4cc10
        tv = {tv_sec = 0, tv_usec = -1000}
        ret = <optimized out>
        max_fd = <optimized out>
        except_fds = 0xfff4cbf0
        fds_size = <optimized out>
#5  0x610d9285 in _sigfe () from /usr/bin/cygwin1.dll
No symbol table info available.
#6  0xffffffff in ?? ()
No symbol table info available.
#7  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 5832.0x23d8):
#0  0x7727013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7727013d in ntdll!ZwWaitForMultipleObjects () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x772a2f51 in ntdll!RtlMoveMemory () from /c/windows/system32/ntdll.dll
No symbol table info available.
#3  0x00000001 in ?? ()
No symbol table info available.
#4  0x00000001 in ?? ()
No symbol table info available.
#5  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 5832.0x22d4):
#0  0x7726f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#1  0x7726f8e5 in ntdll!ZwReadFile () from /c/windows/system32/ntdll.dll
No symbol table info available.
#2  0x7518dd54 in ReadFile () from /c/windows/syswow64/KERNELBASE.dll
No symbol table info available.
#3  0x00000090 in ?? ()
No symbol table info available.
#4  0x751e3f07 in ReadFile () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#5  0x00000090 in ?? ()
No symbol table info available.
#6  0x610de6be in wait_sig () at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/sigproc.cc:1229
        nb = 0
        q = <optimized out>
        pack = {si = {si_signo = 0, si_code = 0, si_pid = 0, si_uid = 0, si_errno = 0, {__pad = {0 <repeats 32 times>}, _si_commune = {_si_code = 0, _si_read_handle = 0x0, _si_write_handle = 0x0, _si_process_handle = 0x0, {_si_fd = 0, _si_pipe_fhandler = 0x0, _si_str = 0x0}}, {{si_sigval = {sival_int = 0, sival_ptr = 0x0}, si_value = {sival_int = 0, sival_ptr = 0x0}}, {si_tid = 0, si_overrun = 0}}, {si_status = 0, si_utime = 0, si_stime = 0}, si_addr = 0x0, {__pad2 = {0 <repeats 31 times>}, si_cyg = 0x0}}}, pid = 0, sigtls = 0x0, mask = 0x0, {wakeup = 0x0, thread_handle = 0x0, next = 0x0}}
        dummy_mask = 0
        clearwait = <optimized out>
        sig_held = false
        __PRETTY_FUNCTION__ = "void wait_sig(void*)"
#7  0x61004a05 in cygthread::callfunc(bool)@8 (this=0x6118d880 <threads>, issimplestub=<optimized out>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:51
        pass_arg = 0x6118d880 <threads>
#8  0x61004f8f in cygthread::stub(void*)@4 (arg=0x6118d880 <threads>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygthread.cc:93
        notify = <optimized out>
        info = 0x6118d880 <threads>
        __PRETTY_FUNCTION__ = "static DWORD cygthread::stub(void*)"
#9  0x61005d1d in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*)@16 (this=<optimized out>, func=0x61004f40 <cygthread::stub(void*)@4>, arg=0x6118d880 <threads>, buf=0x61005ebb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/cygtls.cc:99
        res = <optimized out>
#10 0x0535ff88 in ?? ()
No symbol table info available.
#11 0x751e33aa in KERNEL32!BaseThreadInitThunk () from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#12 0x77289ef2 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#13 0x77289ec5 in ntdll!RtlInitializeExceptionChain () from /c/windows/system32/ntdll.dll
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 5832.0x22f8):
#0  0x6acb06dc in g_slist_remove (list=0x80050c30, data=0x8005cf00) at /usr/src/debug/glib2.0-2.34.3-2/glib/gslist.c:418
        tmp = 0x1
        prev = 0x80050c30
#1  0x6ac951f8 in g_child_watch_finalize (source=0x8005cf00) at /usr/src/debug/glib2.0-2.34.3-2/glib/gmain.c:4580
No locals.
#2  0x6ac928fa in g_source_unref_internal (source=0x8005cf00, context=0x0, have_lock=0) at /usr/src/debug/glib2.0-2.34.3-2/glib/gmain.c:1825
        old_cb_data = 0x0
        old_cb_funcs = 0x0
        __PRETTY_FUNCTION__ = "g_source_unref_internal"
#3  0x6ac929fc in g_source_unref (source=0x8005cf00) at /usr/src/debug/glib2.0-2.34.3-2/glib/gmain.c:1870
        __PRETTY_FUNCTION__ = "g_source_unref"
#4  0x005b371e in init_process_emacs () at process.c:7100
        i = 2730992
#5  0x004ee1fc in main (argc=7, argv=0x29abf0) at emacs.c:1471
        dummy = 1
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = false
        dumping = false
        skip_args = 2
        rlim = {rlim_cur = 2097082, rlim_max = 2097152}
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x772801e2 <ntdll!LdrGetProcedureAddress+24> "]\302\020"

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/22/13 08:13, Ken Brown wrote:
> Jan or Paul, can you help?

The second trace suggests there's a race condition bug in Cygwin glib,
which I've tried to work around in trunk bzr 113138.  Does that help?
(At least, does it make Emacs crash more reliably?....)

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Paul Eggert wrote:
> The second trace suggests there's a race condition bug in Cygwin glib,
> which I've tried to work around in trunk bzr 113138.  Does that help?

No.

> (At least, does it make Emacs crash more reliably?....)

No.


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/22/2013 3:04 PM, Paul Eggert wrote:
> On 06/22/13 08:13, Ken Brown wrote:
>> Jan or Paul, can you help?
>
> The second trace suggests there's a race condition bug in Cygwin glib,
> which I've tried to work around in trunk bzr 113138.  Does that help?
> (At least, does it make Emacs crash more reliably?....)

As Angelo said, the answer to both questions is "No".  But there's 
actually a big difference.  First, the 'abort' breakpoint is never hit. 
  Second, there are no more SEGVs reported in glib.  There are lots of 
SEGVs in _malloc_internal_nolock, and some further SEGVs that gdb can't 
pinpoint.  I think all of the crashes in _malloc_internal_nolock are 
coming when it's called by special_realloc.  Maybe the latter needs to 
be calling _malloc_internal instead of _malloc_inernal_nolock.  I don't 
have any more time right now, but I'll try that later.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Sun, 23 Jun 2013 11:56:13 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, jan.h.d@swipnet.se, 14569@debbugs.gnu.org
> 
> As Angelo said, the answer to both questions is "No".  But there's 
> actually a big difference.  First, the 'abort' breakpoint is never hit. 
>   Second, there are no more SEGVs reported in glib.  There are lots of 
> SEGVs in _malloc_internal_nolock, and some further SEGVs that gdb can't 
> pinpoint.  I think all of the crashes in _malloc_internal_nolock are 
> coming when it's called by special_realloc.  Maybe the latter needs to 
> be calling _malloc_internal instead of _malloc_inernal_nolock.  I don't 
> have any more time right now, but I'll try that later.

If the crashes in gmalloc don't happen unless glib is linked in, then
it's possible that its memory management conflicts in some way with
gmalloc (and possibly ralloc, if Cygwin uses that as well).

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/23/2013 09:13 AM, Eli Zaretskii wrote:
> If the crashes in gmalloc don't happen unless glib is linked in, then
> it's possible that its memory management conflicts in some way with
> gmalloc (and possibly ralloc, if Cygwin uses that as well).

Thanks, I think that's the problem: the new code invokes glib
primitives before the memory allocator is set up on Cygwin, which is a
no-no.  I moved the glib SIGCHLD tickling to later, in trunk bzr 113142;
does that help?

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Paul Eggert wrote:
> On 06/23/2013 09:13 AM, Eli Zaretskii wrote:
>> If the crashes in gmalloc don't happen unless glib is linked in, then
>> it's possible that its memory management conflicts in some way with
>> gmalloc (and possibly ralloc, if Cygwin uses that as well).
>
> Thanks, I think that's the problem: the new code invokes glib
> primitives before the memory allocator is set up on Cygwin, which is a
> no-no.  I moved the glib SIGCHLD tickling to later, in trunk bzr 113142;
> does that help?

No. Rev. 113146 fails in similar manner:

GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Makefile:232: recipe for target `compile-onefile' failed
make[3]: *** [compile-onefile] Aborted


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 23/06/2013 21.49, Angelo Graziosi ha scritto:
> Paul Eggert wrote:
>> On 06/23/2013 09:13 AM, Eli Zaretskii wrote:
>>> If the crashes in gmalloc don't happen unless glib is linked in, then
>>> it's possible that its memory management conflicts in some way with
>>> gmalloc (and possibly ralloc, if Cygwin uses that as well).
>>
>> Thanks, I think that's the problem: the new code invokes glib
>> primitives before the memory allocator is set up on Cygwin, which is a
>> no-no.  I moved the glib SIGCHLD tickling to later, in trunk bzr 113142;
>> does that help?
>
> No. Rev. 113146 fails in similar manner:
>
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_setspecific': Invalid argument.  Aborting.
> Makefile:232: recipe for target `compile-onefile' failed
> make[3]: *** [compile-onefile] Aborted

Sometimes the bootstrap hangs:

[...]
make[3]: ingresso nella directory "work/emacs/Work/lisp"
Compiling work/emacs/src/../lisp/emacs-lisp/map-ynp.el
make[3]: uscita dalla directory "work/emacs/Work/lisp"
make[3]: ingresso nella directory "work/emacs/Work/lisp"
Compiling work/emacs/src/../lisp/cus-start.el
WAIT WAIT WAIT...
IT HANGS

and I cannot break it with CTRL-C. To kill the "bootstrap-emacs" process 
I need to kill it with Windows task manager. The Cygwin "kill -9..." 
command doesn't help... it helps only to kill some "make" processes...

    Angelo

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/23/2013 12:49 PM, Angelo Graziosi wrote:
> No. Rev. 113146 fails in similar manner:

I tried something more-conservative, as trunk bzr 113148;
can you please give it a try?  If it doesn't work, please
try commenting out this line in src/process.c.

    g_source_unref (source);

And if that doesn't work, please try commenting out
the previous line as well:

    GSource *source = g_child_watch_source_new (getpid ());

Thanks.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Eli Zaretskii]

> Date: Sun, 23 Jun 2013 22:47:23 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: eggert@cs.ucla.edu, 14569@debbugs.gnu.org
> 
> make[3]: ingresso nella directory "work/emacs/Work/lisp"
> Compiling work/emacs/src/../lisp/emacs-lisp/map-ynp.el
> make[3]: uscita dalla directory "work/emacs/Work/lisp"
> make[3]: ingresso nella directory "work/emacs/Work/lisp"
> Compiling work/emacs/src/../lisp/cus-start.el
> WAIT WAIT WAIT...
> IT HANGS
> 
> and I cannot break it with CTRL-C. To kill the "bootstrap-emacs" process 
> I need to kill it with Windows task manager. The Cygwin "kill -9..." 
> command doesn't help... it helps only to kill some "make" processes...

When it hangs, try attaching GDB to Emacs, and if that succeeds, show
a backtrace from all the threads ("thread apply all bt").

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/23/2013 8:34 PM, Paul Eggert wrote:
> I tried something more-conservative, as trunk bzr 113148;
> can you please give it a try?

That fixed it for me.  I just ran two consecutive bootstraps without a 
problem.  Angelo, can you confirm?

Thanks, Paul.

One question: Can you explain why you think there's a race condition bug 
in Cygwin glib?  I should probably report this to the Cygwin glib 
maintainer, but I need to understand it first.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/24/2013 04:02 AM, Ken Brown wrote:
> Can you explain why you think there's a race condition bug in Cygwin glib?

It clearly has that feel.  The problem is that if one does this:

  g_source_unref (g_child_watch_source_new (getpid ());

at the obvious spot in Emacs startup, just as glib is
spinning worker threads that do stuff, Emacs goes
kaflooey.  But if one waits until the worker threads
have stabilized (which is what the latest patch does),
it's OK.

It could be a bug in Emacs too.  Emacs's memory allocator
isn't thread-safe, right?  And glib uses threads.  Which
memory allocator is the Cygwin port using, exactly?  If
it's using Emacs's allocator (i.e., compiling gmalloc.c),
that's a bug in Emacs.  If it's using Cygwin's, it's more
likely a bug either in the Cygwin allocator or in glib.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/24/2013 10:34 AM, Paul Eggert wrote:
> On 06/24/2013 04:02 AM, Ken Brown wrote:
>> Can you explain why you think there's a race condition bug in Cygwin glib?
>
> It clearly has that feel.  The problem is that if one does this:
>
>    g_source_unref (g_child_watch_source_new (getpid ());
>
> at the obvious spot in Emacs startup, just as glib is
> spinning worker threads that do stuff, Emacs goes
> kaflooey.  But if one waits until the worker threads
> have stabilized (which is what the latest patch does),
> it's OK.
>
> It could be a bug in Emacs too.  Emacs's memory allocator
> isn't thread-safe, right?  And glib uses threads.  Which
> memory allocator is the Cygwin port using, exactly?  If
> it's using Emacs's allocator (i.e., compiling gmalloc.c),
> that's a bug in Emacs.  If it's using Cygwin's, it's more
> likely a bug either in the Cygwin allocator or in glib.

The Cygwin port uses Emacs's allocator.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/24/13 08:51, Ken Brown wrote:
> The Cygwin port uses Emacs's allocator.

I just looked at Emacs's allocator, and I was wrong:
it tries to be thread-safe, if HAVE_PTHREAD is defined.
Is it defined on Cygwin?  If not, that's a bug; if so,
possibly there is still an incompatibility between
Cygwin threading and Emacs's allocator, but it'll
require some Cygwin expertise to debug.

At any rate *this* bug is now fixed, so I'm marking it
as done.  If the Cygwin port has strange memory-related
problems in the future, you might try the following patch (not
that it's necessarily the right thing...).

=== modified file 'configure.ac'
--- configure.ac	2013-06-24 14:27:25 +0000
+++ configure.ac	2013-06-24 16:53:54 +0000
@@ -1805,7 +1805,7 @@ dnl See comments in aix4-2.h about maybe
 system_malloc=no
 case "$opsys" in
   ## darwin ld insists on the use of malloc routines in the System framework.
-  darwin|sol2-10) system_malloc=yes ;;
+  cygwin|darwin|sol2-10) system_malloc=yes ;;
 esac
 
 if test "${system_malloc}" = "yes"; then

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/24/2013 12:55 PM, Paul Eggert wrote:
> On 06/24/13 08:51, Ken Brown wrote:
>> The Cygwin port uses Emacs's allocator.
>
> I just looked at Emacs's allocator, and I was wrong:
> it tries to be thread-safe, if HAVE_PTHREAD is defined.
> Is it defined on Cygwin?  If not, that's a bug; if so,
> possibly there is still an incompatibility between
> Cygwin threading and Emacs's allocator, but it'll
> require some Cygwin expertise to debug.

Yes, HAVE_PTHREAD is defined on Cygwin.

> At any rate *this* bug is now fixed, so I'm marking it
> as done.  If the Cygwin port has strange memory-related
> problems in the future, you might try the following patch (not
> that it's necessarily the right thing...).
>
> === modified file 'configure.ac'
> --- configure.ac	2013-06-24 14:27:25 +0000
> +++ configure.ac	2013-06-24 16:53:54 +0000
> @@ -1805,7 +1805,7 @@ dnl See comments in aix4-2.h about maybe
>   system_malloc=no
>   case "$opsys" in
>     ## darwin ld insists on the use of malloc routines in the System framework.
> -  darwin|sol2-10) system_malloc=yes ;;
> +  cygwin|darwin|sol2-10) system_malloc=yes ;;
>   esac
>
>   if test "${system_malloc}" = "yes"; then

I've tried this, but it doesn't work.  I would be glad to switch to 
Cygwin's malloc if I could, but I haven't been able to figure out how.  See

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11519#71

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 24/06/2013 13.02, Ken Brown ha scritto:
> On 6/23/2013 8:34 PM, Paul Eggert wrote:
>> I tried something more-conservative, as trunk bzr 113148;
>> can you please give it a try?
>
> That fixed it for me.  I just ran two consecutive bootstraps without a
> problem.  Angelo, can you confirm?

I would say: No.

3 times the build was completed and the last it failed.

In each case, the build log shows errors.

A short summary.

1. Build with cygwin snapshot 20130619 and GCC 4.5.3 without parallel 
build (make bootstrap). The build is completed but the log shows:
================================================================

[...]
Compiling /work/emacs/lisp/org/ob-comint.el
       2 [main] emacs 2692 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - WFSO timed out after longjmp
     354 [main] emacs 2692 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump
Wrote /work/emacs/lisp/org/ob-comint.elc
Compiling /work/emacs/lisp/org/ob-css.el
Wrote /work/emacs/lisp/org/ob-css.elc
Compiling /work/emacs/lisp/org/ob-ditaa.el
Wrote /work/emacs/lisp/org/ob-ditaa.elc
Compiling /work/emacs/lisp/org/ob-dot.el
       2 [main] emacs 2408 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - WFSO timed out after longjmp
     318 [main] emacs 2408 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump
Wrote /work/emacs/lisp/org/ob-dot.elc
Compiling /work/emacs/lisp/org/ob-emacs-lisp.el
Wrote /work/emacs/lisp/org/ob-emacs-lisp.elc
[...]


2. Build with cygwin 1.17.20 and clang-3.1 with parallel build (make -j3 
bootstrap). The build is completed but the log shows:
================================================================

[...]
GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Makefile:251: recipe for target `erc/erc-imenu.elc' failed
make[3]: *** [erc/erc-imenu.elc] Aborted
make[3]: *** Attesa per i processi non terminati....
Wrote /work/emacs/lisp/erc/erc-identd.elc
Wrote /work/emacs/lisp/erc/erc-join.elc

(Notice: the GLib error and the completed build)


3. Build with cygwin 1.17.20 and GCC 4.5.3 without parallel build (make 
bootstrap). The build is completed but the log shows:
================================================================

[...]
Compiling /work/emacs/lisp/cedet/semantic/decorate/mode.el
       3 [main] emacs 1136 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - WFSO timed out after longjmp
     402 [main] emacs 1136 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump

In end of data:
../../lisp/cedet/semantic/decorate/mode.el:560:1:Warning: the following
[...]
Compiling /work/emacs/lisp/net/soap-client.el
       3 [main] emacs 1136 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
Wrote /work/emacs/lisp/net/soap-client.elc
[...]
Compiling /work/emacs/lisp/net/tramp-sh.el
       3 [main] emacs 2512 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
       3 [main] emacs 1516 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
       3 [main] emacs 3572 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
       3 [main] emacs 2828 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
       3 [main] emacs 1520 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
Wrote /work/emacs/lisp/net/tramp-sh.elc
Compiling /work/emacs/lisp/net/tramp-smb.el
[...]


4. Build with cygwin 1.17.20 and GCC 4.5.3 with parallel build (make -j3 
bootstrap). The build failed:
================================================================

[...]
No MH variant found on the system
Wrote /work/emacs/lisp/gnus/gnus-logic.elc
       2 [main] emacs 2436 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
Compiling /work/emacs/lisp/gnus/gnus-mlspl.el
       2 [main] emacs 1320 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
       2 [main] emacs 2356 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
Wrote /work/emacs/lisp/gnus/gnus-mh.elc
Compiling /work/emacs/lisp/gnus/gnus-msg.el
       2 [main] emacs 3032 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - pthread_mutex::_fixup_after_fork () doesn't 
understand PROCESS_SHARED mutex's
Wrote /work/emacs/lisp/gnus/gnus-mlspl.elc
[...]
Wrote /work/emacs/lisp/mail/uce.elc
Compiling /work/emacs/lisp/mail/uudecode.el
     590 [main] emacs 820 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - WFSO timed out after longjmp
     928 [main] emacs 820 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump
Wrote /work/emacs/lisp/mail/unrmail.elc
[...]
Wrote /work/emacs/lisp/org/org-indent.elc
Compiling /work/emacs/lisp/org/org-inlinetask.el
Compiling /work/emacs/lisp/org/org-irc.el
       2 [main] emacs 340 
C:\cygwin-2\home\angelo\work\emacs\Work\src\emacs.exe: *** fatal error 
in forked process - WFSO timed out after longjmp
     349 [main] emacs 340 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump
Wrote /work/emacs/lisp/org/org-info.elc
[...]
Compiling /work/emacs/lisp/progmodes/pascal.el
Wrote /work/emacs/lisp/progmodes/opascal.elc
GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Makefile:251: recipe for target `progmodes/octave.elc' failed
make[3]: *** [progmodes/octave.elc] Aborted (creato dump del core)
make[3]: *** Attesa per i processi non terminati....
Wrote /work/emacs/lisp/progmodes/pascal.elc
[...]
Wrote /work/emacs/lisp/textmodes/flyspell.elc
Compiling /work/emacs/lisp/textmodes/page-ext.el
GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_setspecific': Invalid argument.  Aborting.
Wrote /work/emacs/lisp/textmodes/nroff-mode.elc
Makefile:251: recipe for target `textmodes/makeinfo.elc' failed
make[3]: *** [textmodes/makeinfo.elc] Aborted (creato dump del core)
make[3]: *** Attesa per i processi non terminati....
Wrote /work/emacs/lisp/textmodes/page-ext.elc
make[3]: uscita dalla directory "/work/emacs/Work/lisp"
Makefile:279: recipe for target `compile-main' failed
make[2]: *** [compile-main] Error 2
make[2]: uscita dalla directory "/work/emacs/Work/lisp"
Makefile:367: recipe for target `lisp' failed
make[1]: *** [lisp] Error 2
make[1]: uscita dalla directory "/work/emacs/Work"
Makefile:1002: recipe for target `bootstrap' failed
make: *** [bootstrap] Error 2


I don't know if we can say that the bug is fixed...

(Here is on Win XP 32 SP3, Athlon 64 X2)

Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/24/2013 10:50 AM, Angelo Graziosi wrote:
> I would say: No.

Ouch.  As it happens I didn't successfully mark the
bug as "done", as I thought, so it's still live.

Please try commenting out this line in src/process.c.

    g_source_unref (source);

And if that doesn't work, please try commenting out
the previous line as well:

    GSource *source = g_child_watch_source_new (getpid ());

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 24/06/2013 23.05, Paul Eggert ha scritto:
> On 06/24/2013 10:50 AM, Angelo Graziosi wrote:
>> I would say: No.
>
> Ouch.  As it happens I didn't successfully mark the
> bug as "done", as I thought, so it's still live.
>
> Please try commenting out this line in src/process.c.
>
>      g_source_unref (source);
>
> And if that doesn't work, please try commenting out
> the previous line as well:
>
>      GSource *source = g_child_watch_source_new (getpid ());
>

Only after applying this 2nd solution, i.e. the patch

$ cat process.c.patch
--- emacs-trunk/src/process.c	2013-06-24 12:28:49.562500000 +0200
+++ emacs/src/process.c	2013-06-25 01:11:52.890625000 +0200
@@ -7085,8 +7085,8 @@
       Do this here, rather than early in Emacs initialization where it
       might make more sense, to try to avoid bugs in Cygwin glib 
(Bug#14569).  */
    {
-    GSource *source = g_child_watch_source_new (getpid ());
-    g_source_unref (source);
+    /*GSource *source = g_child_watch_source_new (getpid ());
+      g_source_unref (source);*/
    }
  #endif

the bootstrap completed *without* errors! (With just the first, the same 
errors shows up in the build log...)

My suggestion is to wait few days before declaring this bug FIXED, so 
that we can do more tests.

Anyway, as you prefer.


Ciao... oops, Good Night,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/24/2013 7:50 PM, Angelo Graziosi wrote:
> Only after applying this 2nd solution, i.e. the patch
>
> $ cat process.c.patch
> --- emacs-trunk/src/process.c    2013-06-24 12:28:49.562500000 +0200
> +++ emacs/src/process.c    2013-06-25 01:11:52.890625000 +0200
> @@ -7085,8 +7085,8 @@
>        Do this here, rather than early in Emacs initialization where it
>        might make more sense, to try to avoid bugs in Cygwin glib
> (Bug#14569).  */
>     {
> -    GSource *source = g_child_watch_source_new (getpid ());
> -    g_source_unref (source);
> +    /*GSource *source = g_child_watch_source_new (getpid ());
> +      g_source_unref (source);*/
>     }
>   #endif
>
> the bootstrap completed *without* errors! (With just the first, the same
> errors shows up in the build log...)

My experience is the same.  Thanks for the reminder that it's necessary 
to check the build log for error messages, even when the build appears 
to complete successfully.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/25/2013 9:34 AM, Ken Brown wrote:
> On 6/24/2013 7:50 PM, Angelo Graziosi wrote:
>> Only after applying this 2nd solution, i.e. the patch
>>
>> $ cat process.c.patch
>> --- emacs-trunk/src/process.c    2013-06-24 12:28:49.562500000 +0200
>> +++ emacs/src/process.c    2013-06-25 01:11:52.890625000 +0200
>> @@ -7085,8 +7085,8 @@
>>        Do this here, rather than early in Emacs initialization where it
>>        might make more sense, to try to avoid bugs in Cygwin glib
>> (Bug#14569).  */
>>     {
>> -    GSource *source = g_child_watch_source_new (getpid ());
>> -    g_source_unref (source);
>> +    /*GSource *source = g_child_watch_source_new (getpid ());
>> +      g_source_unref (source);*/
>>     }
>>   #endif
>>
>> the bootstrap completed *without* errors! (With just the first, the same
>> errors shows up in the build log...)
>
> My experience is the same.  Thanks for the reminder that it's necessary
> to check the build log for error messages, even when the build appears
> to complete successfully.

Question for Paul: I'm trying to understand the code that led to this 
problem in the first place, and I'm puzzled by the asymmetry between 
block_child_signal and unblock_child_signal.  The first blocks SIGCHLD, 
while the second unblocks *all* signals.  Why is this the right thing to do?

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/25/2013 06:55 AM, Ken Brown wrote:
> I'm puzzled by the asymmetry between block_child_signal and unblock_child_signal.  The first blocks SIGCHLD, while the second unblocks *all* signals.  Why is this the right thing to do?
> 
> Ken

I didn't write that code, but here's my guess.
Emacs normally runs with all signals unblocked.
Unblocking everything is the right thing to do,
if there's a bug elsewhere in Emacs that inadvertently
leaves signals blocked.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/25/2013 10:51 AM, Paul Eggert wrote:
> On 06/25/2013 06:55 AM, Ken Brown wrote:
>> I'm puzzled by the asymmetry between block_child_signal and unblock_child_signal.  The first blocks SIGCHLD, while the second unblocks *all* signals.  Why is this the right thing to do?
>>
>> Ken
>
> I didn't write that code, but here's my guess.

According to 'bzr log', you introduced those two functions in rev 111081.

> Emacs normally runs with all signals unblocked.
> Unblocking everything is the right thing to do,
> if there's a bug elsewhere in Emacs that inadvertently
> leaves signals blocked.

I still don't get the asymmetry.  By your reasoning, it would seem that 
block_child_signal should set the mask so that only SIGCHLD is blocked. 
  And can unblock_child_signal really be sure that there's no good 
reason for a signal to be blocked?

But I don't want to belabor this.  You know much more about this than I 
do, so if you're sure the existing code is right, I'll drop it.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/25/2013 08:51 AM, Ken Brown wrote:
> you introduced those two functions in rev 111081.

Yes, but if I recall correctly they refactored existing
code.  Existing practice in Emacs is inconsistent: sometimes it
unblocks everything, sometimes it reestablishes
the old mask.  As far as I know the difference
never matters, so either is "right".

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/24/2013 04:50 PM, Angelo Graziosi wrote:
> the bootstrap completed *without* errors!

OK, thanks, as trunk bzr 113206 I installed a change
to skip the gnulib tickling on Cygwin.

Although this should fix the bootstrap failure, I expect that
this reintroduces a bug into Cygwin Emacs, namely,
Emacs can sometimes lose track of subprocesses and/or kill off
unrelated processes; see Bug#12980 and Bug#8855.
Fixing this will require someone with access to Cygwin
and knowledge of how to debug threads under Cygwin,
neither of which I have.  Since the issue appears only
under Cygwin it could well be a Cygwin bug rather than an
Emacs or glib bug.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 27/06/2013 16.56, Paul Eggert ha scritto:
> On 06/24/2013 04:50 PM, Angelo Graziosi wrote:
>> the bootstrap completed *without* errors!
>
> OK, thanks, as trunk bzr 113206 I installed a change
> to skip the gnulib tickling on Cygwin.

Now Emacs trunk build OB... :)

>
> Although this should fix the bootstrap failure, I expect that
> this reintroduces a bug into Cygwin Emacs, namely,
> Emacs can sometimes lose track of subprocesses and/or kill off
> unrelated processes; see Bug#12980 and Bug#8855.

In more than six months, only one or two times Emacs, from trunk, closed 
unexpectedly. Usually it is enough stable.

> Fixing this will require someone with access to Cygwin
> and knowledge of how to debug threads under Cygwin,
> neither of which I have.  Since the issue appears only
> under Cygwin it could well be a Cygwin bug rather than an
> Emacs or glib bug.
>

perhaps... Cygwin "Creators" can help... ;-)


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 27/06/2013 18.44, Angelo Graziosi ha scritto:
> Il 27/06/2013 16.56, Paul Eggert ha scritto:
>> On 06/24/2013 04:50 PM, Angelo Graziosi wrote:
>>> the bootstrap completed *without* errors!
>>
>> OK, thanks, as trunk bzr 113206 I installed a change
>> to skip the gnulib tickling on Cygwin.
>
> Now Emacs trunk build OB... :)
>
>>
>> Although this should fix the bootstrap failure, I expect that
>> this reintroduces a bug into Cygwin Emacs, namely,
>> Emacs can sometimes lose track of subprocesses and/or kill off
>> unrelated processes; see Bug#12980 and Bug#8855.
>
> In more than six months, only one or two times Emacs, from trunk, closed
> unexpectedly. Usually it is enough stable.
>
>> Fixing this will require someone with access to Cygwin
>> and knowledge of how to debug threads under Cygwin,
>> neither of which I have.  Since the issue appears only
>> under Cygwin it could well be a Cygwin bug rather than an
>> Emacs or glib bug.
>>
>
> perhaps... Cygwin "Creators" can help... ;-)
>

Just a note I forgot before...


I think the best way to start in fixing/clarifying this issue is to 
reproduce it with a simple test case in plain C.

In that case, Cygwin guys will know how to fix it or could clarify what 
is wrong etc.

>
> Ciao,
>   Angelo.
>

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/27/2013 10:56 AM, Paul Eggert wrote:
> On 06/24/2013 04:50 PM, Angelo Graziosi wrote:
>> the bootstrap completed *without* errors!
>
> OK, thanks, as trunk bzr 113206 I installed a change
> to skip the gnulib tickling on Cygwin.
>
> Although this should fix the bootstrap failure, I expect that
> this reintroduces a bug into Cygwin Emacs, namely,
> Emacs can sometimes lose track of subprocesses and/or kill off
> unrelated processes; see Bug#12980 and Bug#8855.
> Fixing this will require someone with access to Cygwin
> and knowledge of how to debug threads under Cygwin,
> neither of which I have.  Since the issue appears only
> under Cygwin it could well be a Cygwin bug rather than an
> Emacs or glib bug.

Another alternative is to replace

     if (! noninteractive || initialized)

by

     if (! noninteractive)

at least on Cygwin.  That allows the bootstrap to complete without 
errors.  Assuming this doesn't cause other problems, we wouldn't have to 
worry about reintroducing bugs into (interactive) Cygwin Emacs.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/27/2013 09:44 AM, Angelo Graziosi wrote:
> In more than six months, only one or two times Emacs, from trunk,
> closed unexpectedly. Usually it is enough stable.

The remaining bug won't cause Cygwin Emacs to close unexpectedly.
What it'll do, is cause Cygwin Emacs to lose track of
its child processes -- it'll think they've finished,
when they haven't, or vice versa.  And it can cause
Cygwin Emacs to kill innocent-bystander processes.
These problems are rare, but I expect they can occur
under Cygwin, just as they used to occur under
POSIXish sytems before we redid child process handling.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/27/2013 3:32 PM, Ken Brown wrote:
> On 6/27/2013 10:56 AM, Paul Eggert wrote:
>> On 06/24/2013 04:50 PM, Angelo Graziosi wrote:
>>> the bootstrap completed *without* errors!
>>
>> OK, thanks, as trunk bzr 113206 I installed a change
>> to skip the gnulib tickling on Cygwin.
>>
>> Although this should fix the bootstrap failure, I expect that
>> this reintroduces a bug into Cygwin Emacs, namely,
>> Emacs can sometimes lose track of subprocesses and/or kill off
>> unrelated processes; see Bug#12980 and Bug#8855.
>> Fixing this will require someone with access to Cygwin
>> and knowledge of how to debug threads under Cygwin,
>> neither of which I have.  Since the issue appears only
>> under Cygwin it could well be a Cygwin bug rather than an
>> Emacs or glib bug.
> 
> Another alternative is to replace
> 
>      if (! noninteractive || initialized)
> 
> by
> 
>      if (! noninteractive)
> 
> at least on Cygwin.  That allows the bootstrap to complete without 
> errors.  Assuming this doesn't cause other problems, we wouldn't have to 
> worry about reintroducing bugs into (interactive) Cygwin Emacs.

Just to be clear, here's what I'm proposing:

=== modified file 'src/process.c'
--- src/process.c       2013-06-27 14:47:52 +0000
+++ src/process.c       2013-06-28 11:30:42 +0000
@@ -7092,18 +7092,23 @@
   inhibit_sentinels = 0;

 #ifndef CANNOT_DUMP
+#ifdef CYGWIN
+  if (! noninteractive)
+#else
   if (! noninteractive || initialized)
 #endif
+#endif
     {
-#if defined HAVE_GLIB && !defined WINDOWSNT && !defined CYGWIN
+#if defined HAVE_GLIB && !defined WINDOWSNT
       /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
         this should always fail, but is enough to initialize glib's
         private SIGCHLD handler, allowing the code below to copy it into
         LIB_CHILD_HANDLER.

-        For some reason tickling causes Cygwin bootstrap to fail, so it's
-        skipped under Cygwin.  FIXME: Skipping the tickling likely causes
-        bugs in subprocess handling under Cygwin (Bug#14569).  */
+        For some reason tickling causes Cygwin bootstrap to fail, so
+        it's done under Cygwin only in the interactive case.  FIXME:
+        Skipping the tickling may cause bugs in subprocess handling
+        under Cygwin in the noninteractive case (Bug#14569).  */
       g_source_unref (g_child_watch_source_new (getpid ()));
 #endif
       catch_child_signal ();


Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 06/28/2013 05:20 AM, Ken Brown wrote:

>  #ifndef CANNOT_DUMP
> +#ifdef CYGWIN
> +  if (! noninteractive)
> +#else
>    if (! noninteractive || initialized)
>  #endif
> +#endif

I'm dubious about this proposal.

If there's an obscure race-condition bug during bootstrapping
that makes Emacs crash, why isn't it plausible that a similar
bug could occur during normal operation?  Bootstrapping is
a more-intense activity that could well be more likely to
trigger races, but isn't it more plausible that the races
could occur at any time?

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/28/2013 10:50 AM, Paul Eggert wrote:
> On 06/28/2013 05:20 AM, Ken Brown wrote:
>
>>   #ifndef CANNOT_DUMP
>> +#ifdef CYGWIN
>> +  if (! noninteractive)
>> +#else
>>     if (! noninteractive || initialized)
>>   #endif
>> +#endif
>
> I'm dubious about this proposal.
>
> If there's an obscure race-condition bug during bootstrapping
> that makes Emacs crash, why isn't it plausible that a similar
> bug could occur during normal operation?  Bootstrapping is
> a more-intense activity that could well be more likely to
> trigger races, but isn't it more plausible that the races
> could occur at any time?

I don't know, because I don't know when the race during bootstrapping 
was happening.  If it was happening when emacs was doing the tickling 
(in init_process_emacs), then my suggested change could conceivably 
cause emacs to crash immediately after startup.  Assuming this doesn't 
happen often, I think it's better than having bugs in subprocess handling.

On the other hand, if the race happens when emacs *executes* the glib 
handler (stored in lib_child_handler), then I agree with you that my 
proposal is unacceptable.

I would suggest that we try my proposal but leave the bug open while we 
see how it works.  If people start seeing random crashes, then we'll 
know it was a bad idea and we can revert it.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 28/06/2013 17.29, Ken Brown ha scritto:
> On 6/28/2013 10:50 AM, Paul Eggert wrote:
>> On 06/28/2013 05:20 AM, Ken Brown wrote:
>>
>>>   #ifndef CANNOT_DUMP
>>> +#ifdef CYGWIN
>>> +  if (! noninteractive)
>>> +#else
>>>     if (! noninteractive || initialized)
>>>   #endif
>>> +#endif
>>
>> I'm dubious about this proposal.
>>
>> If there's an obscure race-condition bug during bootstrapping
>> that makes Emacs crash, why isn't it plausible that a similar
>> bug could occur during normal operation?  Bootstrapping is
>> a more-intense activity that could well be more likely to
>> trigger races, but isn't it more plausible that the races
>> could occur at any time?
>
> I don't know, because I don't know when the race during bootstrapping
> was happening.  If it was happening when emacs was doing the tickling
> (in init_process_emacs), then my suggested change could conceivably
> cause emacs to crash immediately after startup.  Assuming this doesn't
> happen often, I think it's better than having bugs in subprocess handling.
>
> On the other hand, if the race happens when emacs *executes* the glib
> handler (stored in lib_child_handler), then I agree with you that my
> proposal is unacceptable.
>
> I would suggest that we try my proposal but leave the bug open while we
> see how it works.  If people start seeing random crashes, then we'll
> know it was a bad idea and we can revert it.

Just for completeness...

I have bootstrapped r. 113214 with Ken's patch. Emacs has been build 
fine, no errors. I have installed it and after 3 hours it is still 
running...

I would adopt Ken's idea and ping people to use/bootstrap trunk... Let's 
see if we can catch Mobydick...


Ciao,
  Angelo.

(PS. Why Thunderbird refuses 14569@debbugs.gnu.org address in my replay? 
I have always to change manually it in bug-gnu-emacs@gnu.org...)

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/28/2013 11:29 AM, Ken Brown wrote:
> I don't know, because I don't know when the race during bootstrapping 
> was happening.  If it was happening when emacs was doing the tickling 
> (in init_process_emacs), then my suggested change could conceivably 
> cause emacs to crash immediately after startup.  Assuming this doesn't 
> happen often, I think it's better than having bugs in subprocess handling.
> 
> On the other hand, if the race happens when emacs *executes* the glib 
> handler (stored in lib_child_handler), then I agree with you that my 
> proposal is unacceptable.

I've done some further testing [*] and determined that the bootstrap failures always occur as a result of the tickling, as I had hoped.  This should mean that, if my patch is applied, the only problem will be a possible random crash right after emacs is started.  The only question is how often this will happen in practice.  I think we can only determine this by applying the patch and asking users to test it.

Ken

[*] I tested this by applying the following patch and then bootstrapping:

=== modified file 'src/process.c'
--- src/process.c       2013-06-27 14:47:52 +0000
+++ src/process.c       2013-06-28 21:30:27 +0000
@@ -7095,7 +7095,7 @@
   if (! noninteractive || initialized)
 #endif
     {
-#if defined HAVE_GLIB && !defined WINDOWSNT && !defined CYGWIN
+#if defined HAVE_GLIB && !defined WINDOWSNT
       /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
         this should always fail, but is enough to initialize glib's
         private SIGCHLD handler, allowing the code below to copy it into
@@ -7105,6 +7105,9 @@
         skipped under Cygwin.  FIXME: Skipping the tickling likely causes
         bugs in subprocess handling under Cygwin (Bug#14569).  */
       g_source_unref (g_child_watch_source_new (getpid ()));
+      fprintf (stderr, "Glib has been tickled.\n");
+      sleep (1);
+      fprintf (stderr, "Calling catch_child_signal.\n");
 #endif
       catch_child_signal ();
     }

Every error that occurred was like the following:

Compiling obsolete/pgg.el
Glib has been tickled.
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.
Makefile:251: recipe for target `obsolete/pgg.elc' failed
make[2]: *** [obsolete/pgg.elc] Aborted

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 6/28/2013 5:40 PM, Ken Brown wrote:
> I've done some further testing [*] and determined that the bootstrap failures always occur as a result of the tickling, as I had hoped.  This should mean that, if my patch is applied, the only problem will be a possible random crash right after emacs is started.  The only question is how often this will happen in practice.  I think we can only determine this by applying the patch and asking users to test it.

Last night I began running a loop in which emacs (patched as I proposed) 
repeatedly starts and then exits after 15 seconds [*].  So far there 
hasn't been a single failure after more than 1300 iterations.  I don't 
know what's different about bootstrapping, but it seems that tickling 
Glib doesn't cause problems on Cygwin in ordinary interactive use of 
Emacs.  (Keep in mind that my previous test, quoted above, showed that 
the failure during bootstrapping always occurred within 1 second after 
Glib got tickled.)

If no one objects, I'll go ahead and apply my patch later today.

Ken

[*] I'm running the following script:

#! /bin/bash
count=0
while true
do
     count=$((count + 1))
     echo "Try $count; starting Emacs."
     if emacs -l test_emacs.el
     then
	echo "Emacs exited normally."
     else
	echo "Emacs exited abnormally."
     fi
     sleep 1
done

test_emacs.el contains the following:

(sit-for 15)
(kill-emacs)

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 01/07/2013 13.21, Ken Brown ha scritto:

> Last night I began running a loop in which emacs (patched as I proposed)
> repeatedly starts and then exits after 15 seconds [*].  So far there
> hasn't been a single failure after more than 1300 iterations.  I don't
> know what's different about bootstrapping, but it seems that tickling
> Glib doesn't cause problems on Cygwin in ordinary interactive use of
> Emacs.  (Keep in mind that my previous test, quoted above, showed that
> the failure during bootstrapping always occurred within 1 second after
> Glib got tickled.)
>
> If no one objects, I'll go ahead and apply my patch later today.

+1

Regarding this:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-06/msg00963.html


shouldn't it flagged, in some manner, to Cygwin ("Creators") list? For 
example,

"Bootstrapping Emacs with this patch fails on Cygwin so and so... but 
not on GNU/Linux... Have you some idea?..."

After all, trying to bootstrap Emacs trunk is not so much work... The 
big work, perhaps, is in understanding the failure, I think..


Ciao
Angelo

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 7/1/2013 8:28 AM, Angelo Graziosi wrote:
> Il 01/07/2013 13.21, Ken Brown ha scritto:
>
>> Last night I began running a loop in which emacs (patched as I proposed)
>> repeatedly starts and then exits after 15 seconds [*].  So far there
>> hasn't been a single failure after more than 1300 iterations.  I don't
>> know what's different about bootstrapping, but it seems that tickling
>> Glib doesn't cause problems on Cygwin in ordinary interactive use of
>> Emacs.  (Keep in mind that my previous test, quoted above, showed that
>> the failure during bootstrapping always occurred within 1 second after
>> Glib got tickled.)
>>
>> If no one objects, I'll go ahead and apply my patch later today.
>
> +1
>
> Regarding this:
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-06/msg00963.html
>
>
> shouldn't it flagged, in some manner, to Cygwin ("Creators") list? For
> example,
>
> "Bootstrapping Emacs with this patch fails on Cygwin so and so... but
> not on GNU/Linux... Have you some idea?..."
>
> After all, trying to bootstrap Emacs trunk is not so much work... The
> big work, perhaps, is in understanding the failure, I think..

Yes, I agree in principle, but I'm not yet sure it's a Cygwin bug, and I 
haven't been able to come up with a simple test case that exhibits the 
problem.  My naive attempt didn't work:

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 7/1/2013 9:51 AM, Ken Brown wrote:
> On 7/1/2013 8:28 AM, Angelo Graziosi wrote:
>> Il 01/07/2013 13.21, Ken Brown ha scritto:
>>
>>> Last night I began running a loop in which emacs (patched as I proposed)
>>> repeatedly starts and then exits after 15 seconds [*].  So far there
>>> hasn't been a single failure after more than 1300 iterations.  I don't
>>> know what's different about bootstrapping, but it seems that tickling
>>> Glib doesn't cause problems on Cygwin in ordinary interactive use of
>>> Emacs.  (Keep in mind that my previous test, quoted above, showed that
>>> the failure during bootstrapping always occurred within 1 second after
>>> Glib got tickled.)
>>>
>>> If no one objects, I'll go ahead and apply my patch later today.
>>
>> +1
>>
>> Regarding this:
>>
>> http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-06/msg00963.html
>>
>>
>> shouldn't it flagged, in some manner, to Cygwin ("Creators") list? For
>> example,
>>
>> "Bootstrapping Emacs with this patch fails on Cygwin so and so... but
>> not on GNU/Linux... Have you some idea?..."
>>
>> After all, trying to bootstrap Emacs trunk is not so much work... The
>> big work, perhaps, is in understanding the failure, I think..

[Sorry, I accidentally sent an unfinished reply.  I'll restart.]

Yes, I agree in principle, but I'm not yet sure it's a Cygwin bug, and I 
haven't been able to come up with a simple test case that exhibits the 
problem.  My naive attempt didn't work: I wrote a little C program that 
tickled Glib exactly as in process.c.  I ran it thousands of times 
without an error.  So I have to try to figure out what's different 
during bootstrapping.  And Emacs's gmalloc.c may be part or all of the 
problem too.  That's not compiled on GNU/Linux.

I'd like to keep trying to track this down for a while before asking on 
the Cygwin list.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 07/01/2013 04:21 AM, Ken Brown wrote:
> 
> Last night I began running a loop in which emacs (patched as I proposed) repeatedly starts and then
> exits after 15 seconds [*].  So far there hasn't been a single failure after more than 1300 iterations.

I wouldn't expect your test case to exercise the bug.
The bug occurs when Gtk or Glib activity is occurring
in some other thread at the same time that Emacs is
running.  To reproduce the bug, one must have a
race condition like that.  In your test case Emacs
is idle, so it's unlikely to exhibit the bug.

A couple more things.  Since the bug comes into play
only when glib is tickled, shouldn't the Cygwin case
suppress only the tickling, not the catching of child
signals?

Also, wouldn't it be better to give Cygwin maintainers
an easy way to reproduce the bug, say by compiling
with a special flag?

So, how about the following patch instead?

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2013-06-30 22:29:23 +0000
+++ src/ChangeLog	2013-07-01 14:17:45 +0000
@@ -1,3 +1,10 @@
+2013-07-01  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Tickle glib when debugging under Cygwin (Bug#14569).
+	* process.c (init_process_emacs) [CYGWIN && TICKLE_GLIB_BUGFIX]:
+	Tickle glib in this case, too, so that Cygwin maintainers
+	can reproduce the bug more easily.
+
 2013-06-30  Michal Nazarewicz  <mina86@mina86.com>
 
 	* buffer.c (FKill_buffer): Run `kill-buffer-query-functions'

=== modified file 'src/process.c'
--- src/process.c	2013-06-27 14:47:52 +0000
+++ src/process.c	2013-07-01 14:12:31 +0000
@@ -7095,16 +7095,24 @@
   if (! noninteractive || initialized)
 #endif
     {
-#if defined HAVE_GLIB && !defined WINDOWSNT && !defined CYGWIN
+#if defined HAVE_GLIB && !defined WINDOWSNT
       /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
 	 this should always fail, but is enough to initialize glib's
 	 private SIGCHLD handler, allowing the code below to copy it into
 	 LIB_CHILD_HANDLER.
 
-	 For some reason tickling causes Cygwin bootstrap to fail, so it's
-	 skipped under Cygwin.  FIXME: Skipping the tickling likely causes
-	 bugs in subprocess handling under Cygwin (Bug#14569).  */
-      g_source_unref (g_child_watch_source_new (getpid ()));
+	 Under Cygwin as of July 2013, tickling causes bootstrap to fail,
+	 so do it only when Emacs is compiled with -DTICKLE_GLIB_BUGFIX;
+	 this is to help Cygwin maintainers reproduce the bug.
+	 FIXME: Skipping the tickling likely causes bugs in subprocess
+	 handling under Cygwin (Bug#14569).  */
+# if defined CYGWIN && !defined TICKLE_GLIB_BUGFIX
+      bool tickle_glib = 0;
+# else
+      bool tickle_glib = 1;
+# endif
+      if (tickle_glib)
+	g_source_unref (g_child_watch_source_new (getpid ()));
 #endif
       catch_child_signal ();
     }

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 7/1/2013 10:19 AM, Paul Eggert wrote:
> On 07/01/2013 04:21 AM, Ken Brown wrote:
>>
>> Last night I began running a loop in which emacs (patched as I proposed) repeatedly starts and then
>> exits after 15 seconds [*].  So far there hasn't been a single failure after more than 1300 iterations.
>
> I wouldn't expect your test case to exercise the bug.
> The bug occurs when Gtk or Glib activity is occurring
> in some other thread at the same time that Emacs is
> running.  To reproduce the bug, one must have a
> race condition like that.  In your test case Emacs
> is idle, so it's unlikely to exhibit the bug.
>
> A couple more things.  Since the bug comes into play
> only when glib is tickled, shouldn't the Cygwin case
> suppress only the tickling, not the catching of child
> signals?
>
> Also, wouldn't it be better to give Cygwin maintainers
> an easy way to reproduce the bug, say by compiling
> with a special flag?
>
> So, how about the following patch instead?
>
> === modified file 'src/ChangeLog'
> --- src/ChangeLog	2013-06-30 22:29:23 +0000
> +++ src/ChangeLog	2013-07-01 14:17:45 +0000
> @@ -1,3 +1,10 @@
> +2013-07-01  Paul Eggert  <eggert@cs.ucla.edu>
> +
> +	Tickle glib when debugging under Cygwin (Bug#14569).
> +	* process.c (init_process_emacs) [CYGWIN && TICKLE_GLIB_BUGFIX]:
> +	Tickle glib in this case, too, so that Cygwin maintainers
> +	can reproduce the bug more easily.
> +
>   2013-06-30  Michal Nazarewicz  <mina86@mina86.com>
>
>   	* buffer.c (FKill_buffer): Run `kill-buffer-query-functions'
>
> === modified file 'src/process.c'
> --- src/process.c	2013-06-27 14:47:52 +0000
> +++ src/process.c	2013-07-01 14:12:31 +0000
> @@ -7095,16 +7095,24 @@
>     if (! noninteractive || initialized)
>   #endif
>       {
> -#if defined HAVE_GLIB && !defined WINDOWSNT && !defined CYGWIN
> +#if defined HAVE_GLIB && !defined WINDOWSNT
>         /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
>   	 this should always fail, but is enough to initialize glib's
>   	 private SIGCHLD handler, allowing the code below to copy it into
>   	 LIB_CHILD_HANDLER.
>
> -	 For some reason tickling causes Cygwin bootstrap to fail, so it's
> -	 skipped under Cygwin.  FIXME: Skipping the tickling likely causes
> -	 bugs in subprocess handling under Cygwin (Bug#14569).  */
> -      g_source_unref (g_child_watch_source_new (getpid ()));
> +	 Under Cygwin as of July 2013, tickling causes bootstrap to fail,
> +	 so do it only when Emacs is compiled with -DTICKLE_GLIB_BUGFIX;
> +	 this is to help Cygwin maintainers reproduce the bug.
> +	 FIXME: Skipping the tickling likely causes bugs in subprocess
> +	 handling under Cygwin (Bug#14569).  */
> +# if defined CYGWIN && !defined TICKLE_GLIB_BUGFIX
> +      bool tickle_glib = 0;
> +# else
> +      bool tickle_glib = 1;
> +# endif
> +      if (tickle_glib)
> +	g_source_unref (g_child_watch_source_new (getpid ()));
>   #endif
>         catch_child_signal ();
>       }

Yes, this looks good.  Please go ahead and apply it.

If it turns out that this really is a Cygwin/Glib bug (and not, say, a 
bug in gmalloc.c), it will be much easier to find the problem if I can 
provide the Cygwin maintainers with a test case in C, independent of 
Emacs.  Is there a simple way to simulate the kind of race condition 
that you think is going on here?

Thanks.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 01/07/2013 16.19, Paul Eggert ha scritto:
> On 07/01/2013 04:21 AM, Ken Brown wrote:
>>
>> Last night I began running a loop in which emacs (patched as I proposed) repeatedly starts and then
>> exits after 15 seconds [*].  So far there hasn't been a single failure after more than 1300 iterations.
>
> I wouldn't expect your test case to exercise the bug.
> The bug occurs when Gtk or Glib activity is occurring
> in some other thread at the same time that Emacs is
> running.  To reproduce the bug, one must have a
> race condition like that.  In your test case Emacs
> is idle, so it's unlikely to exhibit the bug.
>
> A couple more things.  Since the bug comes into play
> only when glib is tickled, shouldn't the Cygwin case
> suppress only the tickling, not the catching of child
> signals?
>
> Also, wouldn't it be better to give Cygwin maintainers
> an easy way to reproduce the bug, say by compiling
> with a special flag?
>
> So, how about the following patch instead?
>
> === modified file 'src/ChangeLog'
> --- src/ChangeLog	2013-06-30 22:29:23 +0000
> +++ src/ChangeLog	2013-07-01 14:17:45 +0000
> @@ -1,3 +1,10 @@
> +2013-07-01  Paul Eggert  <eggert@cs.ucla.edu>
> +
> +	Tickle glib when debugging under Cygwin (Bug#14569).
> +	* process.c (init_process_emacs) [CYGWIN && TICKLE_GLIB_BUGFIX]:
> +	Tickle glib in this case, too, so that Cygwin maintainers
> +	can reproduce the bug more easily.
> +
>   2013-06-30  Michal Nazarewicz  <mina86@mina86.com>
>
>   	* buffer.c (FKill_buffer): Run `kill-buffer-query-functions'
>
> === modified file 'src/process.c'
> --- src/process.c	2013-06-27 14:47:52 +0000
> +++ src/process.c	2013-07-01 14:12:31 +0000
> @@ -7095,16 +7095,24 @@
>     if (! noninteractive || initialized)
>   #endif
>       {
> -#if defined HAVE_GLIB && !defined WINDOWSNT && !defined CYGWIN
> +#if defined HAVE_GLIB && !defined WINDOWSNT
>         /* Tickle glib's child-handling code.  Ask glib to wait for Emacs itself;
>   	 this should always fail, but is enough to initialize glib's
>   	 private SIGCHLD handler, allowing the code below to copy it into
>   	 LIB_CHILD_HANDLER.
>
> -	 For some reason tickling causes Cygwin bootstrap to fail, so it's
> -	 skipped under Cygwin.  FIXME: Skipping the tickling likely causes
> -	 bugs in subprocess handling under Cygwin (Bug#14569).  */
> -      g_source_unref (g_child_watch_source_new (getpid ()));
> +	 Under Cygwin as of July 2013, tickling causes bootstrap to fail,
> +	 so do it only when Emacs is compiled with -DTICKLE_GLIB_BUGFIX;
> +	 this is to help Cygwin maintainers reproduce the bug.
> +	 FIXME: Skipping the tickling likely causes bugs in subprocess
> +	 handling under Cygwin (Bug#14569).  */
> +# if defined CYGWIN && !defined TICKLE_GLIB_BUGFIX
> +      bool tickle_glib = 0;
> +# else
> +      bool tickle_glib = 1;
> +# endif
> +      if (tickle_glib)
> +	g_source_unref (g_child_watch_source_new (getpid ()));
>   #endif
>         catch_child_signal ();
>       }


It looks a nice solution. I have applied the patch and bootstrapped with

   CFLAGS=-DTICKLE_GLIB_BUGFIX ./my_build.sh

and it fails as expected. Instead the bootstrap

   ./my_build.sh

is completed just fine.

This way Cygwin gurus have a possibility to catch Mobydick, if it exists...


Ciao,
  Angelo.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

I found the bug.  It's that malloc_enable_thread doesn't get called in 
batch mode, because of the following in emacs.c:

#if defined (HAVE_PTHREAD) && !defined (SYSTEM_MALLOC) && !defined 
(DOUG_LEA_MALLOC)
   if (! noninteractive)
     {
       extern void malloc_enable_thread (void);

       malloc_enable_thread ();
     }
#endif

Removing " if (! noninteractive)" solves the problem.  Will it break 
something else?  I have no idea why malloc_enable_thread was only being 
called in the interactive case.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Paul Eggert]

On 07/01/2013 11:40 AM, Ken Brown wrote:
> Removing " if (! noninteractive)" solves the problem.  Will it break something else?

I don't see why it would.  I installed that as part of trunk bzr 113247,
and thanks for finding the underlying fault.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Angelo Graziosi]

Il 01/07/2013 23.07, Paul Eggert ha scritto:
> On 07/01/2013 11:40 AM, Ken Brown wrote:
>> Removing " if (! noninteractive)" solves the problem.  Will it break something else?
>
> I don't see why it would.  I installed that as part of trunk bzr 113247,
> and thanks for finding the underlying fault.
>

It seems that Mobydick has been catched! Rev. 113247 bootstraps OB... :-)

Many many thanks!

Ciao
Angelo

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 7/1/2013 5:47 PM, Angelo Graziosi wrote:
> Il 01/07/2013 23.07, Paul Eggert ha scritto:
>> On 07/01/2013 11:40 AM, Ken Brown wrote:
>>> Removing " if (! noninteractive)" solves the problem.  Will it break
>>> something else?
>>
>> I don't see why it would.  I installed that as part of trunk bzr 113247,
>> and thanks for finding the underlying fault.
>>
>
> It seems that Mobydick has been catched! Rev. 113247 bootstraps OB... :-)
>
> Many many thanks!

Thanks for confirming.  I'm closing the bug.

Ken

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Katsumi Yamaoka]

Ken Brown wrote:
> On 7/1/2013 5:47 PM, Angelo Graziosi wrote:
>> Il 01/07/2013 23.07, Paul Eggert ha scritto:
>>> On 07/01/2013 11:40 AM, Ken Brown wrote:
>>>> Removing " if (! noninteractive)" solves the problem.  Will it break
>>>> something else?
>>>
>>> I don't see why it would.  I installed that as part of trunk bzr 113247,
>>> and thanks for finding the underlying fault.
>>>
>>
>> It seems that Mobydick has been catched! Rev. 113247 bootstraps OB... :-)
>>
>> Many many thanks!

> Thanks for confirming.  I'm closing the bug.

Many many thanks, too!

However, there is still a problem that got to arise recently.
Though I feel like the frequency got decreased.  That is that
Cygwin Emacs sometimes freezes for a couple of ten seconds
unexpectedly.  It happens irregularly while I'm writing something.
I'm not sure it is concerned to, but some asynchronous processes
are running at that time; though I don't believe that my keystroke
for self-insert-command triggers a communication with one of them.
Those are display-time (a timer) and ispell (and ndtp and Sj3).

In addition, how about Bug#14553 ?
<http://thread.gmane.org/gmane.emacs.bugs/74799/focus=74799>

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> However, there is still a problem that got to arise recently.
> Though I feel like the frequency got decreased.  That is that
> Cygwin Emacs sometimes freezes for a couple of ten seconds
> unexpectedly.  It happens irregularly while I'm writing something.

Also this sometimes happens:

Memory exhausted--use C-x s then exit and restart Emacs
Error running timer `display-time-event-handler': (error "Memory exhausted--use C-x s then exit and restart Emacs")
Memory exhausted--use C-x s then exit and restart Emacs [3 times]

At that time I can do neither `C-x s' nor exit; what I can do
then is only to kill the Emacs process (so I transcribed the above
messages by hand).  AFAICR, it didn't happen until Jun 2013.

> In addition, how about Bug#14553 ?
> <http://thread.gmane.org/gmane.emacs.bugs/74799/focus=74799>

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Ken Brown]

On 7/2/2013 1:23 AM, Katsumi Yamaoka wrote:
> Katsumi Yamaoka wrote:
>> However, there is still a problem that got to arise recently.
>> Though I feel like the frequency got decreased.  That is that
>> Cygwin Emacs sometimes freezes for a couple of ten seconds
>> unexpectedly.  It happens irregularly while I'm writing something.
>
> Also this sometimes happens:
>
> Memory exhausted--use C-x s then exit and restart Emacs
> Error running timer `display-time-event-handler': (error "Memory exhausted--use C-x s then exit and restart Emacs")
> Memory exhausted--use C-x s then exit and restart Emacs [3 times]
>
> At that time I can do neither `C-x s' nor exit; what I can do
> then is only to kill the Emacs process (so I transcribed the above
> messages by hand).  AFAICR, it didn't happen until Jun 2013.

Please make a new bug report about this problem.  AFAIK, it has nothing 
to do with the present bug.  And it would help greatly if you could find 
the first bzr revision that exhibits the problem.

>> In addition, how about Bug#14553 ?
>> <http://thread.gmane.org/gmane.emacs.bugs/74799/focus=74799>

I'll take a look when I get a chance.

Ken

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

Hi,

This sometimes happens on Cygwin since the beginning of Jun
concurrently with Bug#14569 (bootstrap fails on Cygwin):

Memory exhausted--use C-x s then exit and restart Emacs
Error running timer `display-time-event-handler': (error "Memory exhausted--use C-x s then exit and restart Emacs")
Memory exhausted--use C-x s then exit and restart Emacs [3 times]

At that time I can do neither `C-x s' nor exit; what I can do
then is only to kill the Emacs process (so I transcribed the above
messages by hand).

Thanks.

bug#14569: 24.3.50; bootstrap fails on Cygwin

[Katsumi Yamaoka]

Ken Brown <kbrown@cornell.edu> wrote:
> On 7/2/2013 1:23 AM, Katsumi Yamaoka wrote:
[...]
>> Memory exhausted--use C-x s then exit and restart Emacs
>> Error running timer `display-time-event-handler': (error "Memory
>> exhausted--use C-x s then exit and restart Emacs")
>> Memory exhausted--use C-x s then exit and restart Emacs [3 times]

> Please make a new bug report about this problem.  AFAIK, it has
> nothing to do with the present bug.  And it would help greatly if you
> could find the first bzr revision that exhibits the problem.

I did so.  Thanks.

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Angelo Graziosi]

Katsumi Yamaoka wrote:
> This sometimes happens on Cygwin since the beginning of Jun
> concurrently with Bug#14569 (bootstrap fails on Cygwin):
>
> Memory exhausted--use C-x s then exit and restart Emacs
> Error running timer `display-time-event-handler': (error "Memory exhausted--use
> C-x s then exit and restart Emacs")
> Memory exhausted--use C-x s then exit and restart Emacs [3 times]
>
> At that time I can do neither `C-x s' nor exit; what I can do
> then is only to kill the Emacs process (so I transcribed the above
> messages by hand).

Hmm.. I never have seen that..

Where you see those messages? May you give a recipe to reproduce them?

Here Emacs trunk works... Usaually I start it with at least 11 buffers, 
a single frame and 3 windows.. it runs for hours with no problem.


Ciao,
Angelo.

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Ken Brown]

On 7/2/2013 9:57 AM, Katsumi Yamaoka wrote:
> Hi,
>
> This sometimes happens on Cygwin since the beginning of Jun
> concurrently with Bug#14569 (bootstrap fails on Cygwin):

We've since found the cause of that bug, and it affected only 
noninteractive uses of emacs.  So I don't think there's any connection 
between that bug and this one.

Angelo already asked for a recipe to reproduce the problem.  I realize 
that may be difficult if the problem is intermittent.  If you can't do 
that, then it would really help if you could pin down the exact bzr 
revision at which the problem first occurred.

Ken

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

Ken Brown wrote:
> , then it would really help if you could pin down the exact bzr
> revision at which the problem first occurred.

It (bug#14569) started in the morning of 06 June, 2013 (in Japan).
I'm building bzr Emacs every morning of week days, so the suspected
revision will possibly be one of these:

revno: 112865
timestamp: Wed 2013-06-05 23:45:34 +0300 (Thu Jun  6 05:45:34 2013 +0900)
revno: 112859
timestamp: Wed 2013-06-05 10:04:13 -0700 (Thu Jun  6 02:04:13 2013 +0900)
revno: 112854
timestamp: Wed 2013-06-05 14:17:02 +0200 (Wed Jun  5 21:17:02 2013 +0900)
revno: 112851
timestamp: Tue 2013-06-04 21:58:43 -0400 (Wed Jun  5 10:58:43 2013 +0900)

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

Angelo Graziosi wrote:
> Katsumi Yamaoka wrote:
>> This sometimes happens on Cygwin since the beginning of Jun
>> concurrently with Bug#14569 (bootstrap fails on Cygwin):
>>
>> Memory exhausted--use C-x s then exit and restart Emacs
>> Error running timer `display-time-event-handler': (error "Memory
>> exhausted--use
>> C-x s then exit and restart Emacs")
>> Memory exhausted--use C-x s then exit and restart Emacs [3 times]
>>
>> At that time I can do neither `C-x s' nor exit; what I can do
>> then is only to kill the Emacs process (so I transcribed the above
>> messages by hand).

> Hmm.. I never have seen that..

I suspected it might be due to display-time-interval that was too
short (1), and turned back it to the default (60) about a month ago.
It didn't help after all, though.  Here is my Emacs clock setting:

(setq display-time-default-load-average nil
      display-time-24hr-format t)
;;(setq display-time-interval 1
;;      display-time-format "%H:%M:%S")
(display-time-mode 1)

> Where you see those messages? May you give a recipe to reproduce them?

It happens unexpectedly when I do something on Emacs, so I cannot
show a reproducible recipe.  But the frequency of this is much
less than the following:

Message-ID: <b4mfvvx66ut.fsf@jpl.org>
> Cygwin Emacs sometimes freezes for a couple of ten seconds
> unexpectedly.  It happens irregularly while I'm writing something.

Actually while I was writing this mail, "Memory exhausted" happened
only once, but the freezing happened for over ten times. :<

> Here Emacs trunk works... Usaually I start it with at least 11
> buffers, a single frame and 3 windows.. it runs for hours with no
> problem.

I'm encouraged with you and the active users anyway.  Thanks.

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Ken Brown]

On 7/2/2013 10:30 PM, Katsumi Yamaoka wrote:
> Ken Brown wrote:
>> , then it would really help if you could pin down the exact bzr
>> revision at which the problem first occurred.
>
> It (bug#14569) started in the morning of 06 June, 2013 (in Japan).
> I'm building bzr Emacs every morning of week days, so the suspected
> revision will possibly be one of these:
>
> revno: 112865
> timestamp: Wed 2013-06-05 23:45:34 +0300 (Thu Jun  6 05:45:34 2013 +0900)
> revno: 112859
> timestamp: Wed 2013-06-05 10:04:13 -0700 (Thu Jun  6 02:04:13 2013 +0900)
> revno: 112854
> timestamp: Wed 2013-06-05 14:17:02 +0200 (Wed Jun  5 21:17:02 2013 +0900)
> revno: 112851
> timestamp: Tue 2013-06-04 21:58:43 -0400 (Wed Jun  5 10:58:43 2013 +0900)

In a different bug report you mentioned that you configure with the 
following options:

--with-x-toolkit=lucid --without-imagemagick --without-dbus 
--without-gconf --without-gsettings

Superficially it would seem that there's no reason for your build to 
link with glib.  But obviously it does link with glib, or else bug#14569 
wouldn't have affected you.  My guess is that revno 112830 on June 3, 
which introduced gfilenotify, is what caused your build to link with 
glib.  Is it possible that gfilenotify doesn't work well with the lucid 
toolkit?  Or perhaps the tickling of glib causes problems when the lucid 
toolkit is used?

Michael and Paul, do you have any ideas here?

Ken

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Paul Eggert]

On 07/02/2013 08:24 PM, Ken Brown wrote:
> Is it possible that gfilenotify doesn't work well with the lucid toolkit?
> Or perhaps the tickling of glib causes problems when the lucid toolkit is used?

It's possible, but lucid isn't multithreaded.

What happens if you append --without-file-notification
to the 'configure' options?  I expect that's what's
dragging in glib.

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Michael Albinus]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> It (bug#14569) started in the morning of 06 June, 2013 (in Japan).

Do you use autorevert? This would trigger gfilenotify, which has been
added June 3rd.

Best regards, Michael.

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

Paul Eggert wrote:
> On 07/02/2013 08:24 PM, Ken Brown wrote:
>> Is it possible that gfilenotify doesn't work well with the lucid toolkit?
>> Or perhaps the tickling of glib causes problems when the lucid
>> toolkit is used?

> It's possible, but lucid isn't multithreaded.

> What happens if you append --without-file-notification
> to the 'configure' options?  I expect that's what's
> dragging in glib.

I tried --without-file-notification.  AFAICT no difference presents,
if anything, I feel like the frequency of the freezing is increased.
Emacs links cygglib-2.0-0.dll .

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

Michael Albinus wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> It (bug#14569) started in the morning of 06 June, 2013 (in Japan).

> Do you use autorevert? This would trigger gfilenotify, which has been
> added June 3rd.

I don't use auto-revert.

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Ken Brown]

On 7/3/2013 6:01 AM, Katsumi Yamaoka wrote:
> Paul Eggert wrote:
>> On 07/02/2013 08:24 PM, Ken Brown wrote:
>>> Is it possible that gfilenotify doesn't work well with the lucid toolkit?
>>> Or perhaps the tickling of glib causes problems when the lucid
>>> toolkit is used?
>
>> It's possible, but lucid isn't multithreaded.
>
>> What happens if you append --without-file-notification
>> to the 'configure' options?  I expect that's what's
>> dragging in glib.
>
> I tried --without-file-notification.  AFAICT no difference presents,
> if anything, I feel like the frequency of the freezing is increased.
> Emacs links cygglib-2.0-0.dll .

What if you also add --without-rsvg?

Ken

bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

Ken Brown wrote:
> On 7/3/2013 6:01 AM, Katsumi Yamaoka wrote:
>> Paul Eggert wrote:
>>> On 07/02/2013 08:24 PM, Ken Brown wrote:
>>>> Is it possible that gfilenotify doesn't work well with the lucid toolkit?
>>>> Or perhaps the tickling of glib causes problems when the lucid
>>>> toolkit is used?
>>
>>> It's possible, but lucid isn't multithreaded.
>>
>>> What happens if you append --without-file-notification
>>> to the 'configure' options?  I expect that's what's
>>> dragging in glib.
>>
>> I tried --without-file-notification.  AFAICT no difference presents,
>> if anything, I feel like the frequency of the freezing is increased.
>> Emacs links cygglib-2.0-0.dll .

> What if you also add --without-rsvg?

Oh, Emacs was built without glib.  It still sometimes freezes,
though I haven't seen "Memory exhausted" yet so far.  I'll keep
trying it.  Thanks.

Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Ashish SHUKLA]

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

Hi,

I tried bzr revision r113270 on my FreeBSD 9.1-RELEASE (amd64), and it
segfaulted during bootstrap process, (the compilation of files in "lisp"
directory). It generated a core-file lisp/bootstrap-emacs.core which has more
than 3-million (that's when I lost patience) recurring stack frames like
following:

#v+
#3367385 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#3367386 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
#3367387 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
#3367388 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
#3367389 0x00000008080764bd in ?? () from /lib/libthr.so.3
#3367390 0x0000000808076d5b in ?? () from /lib/libthr.so.3
#3367391 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#3367392 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
#3367393 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
#3367394 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
#3367395 0x00000008080764bd in ?? () from /lib/libthr.so.3
#3367396 0x0000000808076d5b in ?? () from /lib/libthr.so.3
#3367397 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#3367398 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
#3367399 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
#3367400 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
#3367401 0x00000008080764bd in ?? () from /lib/libthr.so.3
#v-

Following is the configure line I used:

./configure --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-m17n-flt --with-libotf --with-imagemagick --with-gsettings --with-gconf --with-xim --with-sound --with-dbus --with-xml2 --with-gnutls --with-acl --with-file-notification=gfile --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.1

Please let me know if you need more information from the core file.

Thanks
-- 
Ashish SHUKLA

”The only things certain in life are death, taxes, and accidentally deleted
data.” (bazza)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Paul Eggert]

I think this is fallout from Bug#14569, and
I'll reply there.

bug#14569: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Paul Eggert]

[CC'ing to 14569@debbugs.gnu.org as I think it's related
to that bug....]

On 07/03/2013 09:00 AM, Ashish SHUKLA wrote:

> I tried bzr revision r113270 on my FreeBSD 9.1-RELEASE (amd64), and it
> segfaulted during bootstrap process...
> #v+
> #3367385 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
> #3367386 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
> #3367387 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
> #3367388 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
> #3367389 0x00000008080764bd in ?? () from /lib/libthr.so.3
> #3367390 0x0000000808076d5b in ?? () from /lib/libthr.so.3
> #3367391 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
> #3367392 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
> #3367393 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
> #3367394 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
...

This is no doubt fallout from trunk bzr 113247, needed for
Cygwin.  I installed what I hope fixes the problem for
FreeBSD, without reintroducing the Cygwin bug, as trunk
bzr 113275; please give it a try.

I don't use either Cygwin or FreeBSD, so I'm afraid
I have to rely on others to check these fixes.

bug#14569: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Ken Brown]

On 7/3/2013 8:58 PM, Paul Eggert wrote:
> This is no doubt fallout from trunk bzr 113247, needed for
> Cygwin.  I installed what I hope fixes the problem for
> FreeBSD, without reintroducing the Cygwin bug, as trunk
> bzr 113275; please give it a try.
>
> I don't use either Cygwin or FreeBSD, so I'm afraid
> I have to rely on others to check these fixes.

Cygwin still bootstraps OK after this change.

Ken

bug#14569: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[wahjava.ml]

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

On Wed, 03 Jul 2013 17:58:10 -0700, Paul Eggert <eggert@cs.ucla.edu> said:
> [CC'ing to 14569@debbugs.gnu.org as I think it's related
> to that bug....]

> On 07/03/2013 09:00 AM, Ashish SHUKLA wrote:

>> I tried bzr revision r113270 on my FreeBSD 9.1-RELEASE (amd64), and it
>> segfaulted during bootstrap process...
>> #v+
>> #3367385 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
>> #3367386 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
>> #3367387 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
>> #3367388 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
>> #3367389 0x00000008080764bd in ?? () from /lib/libthr.so.3
>> #3367390 0x0000000808076d5b in ?? () from /lib/libthr.so.3
>> #3367391 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
>> #3367392 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
>> #3367393 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
>> #3367394 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
> ...

> This is no doubt fallout from trunk bzr 113247, needed for
> Cygwin.  I installed what I hope fixes the problem for
> FreeBSD, without reintroducing the Cygwin bug, as trunk
> bzr 113275; please give it a try.

> I don't use either Cygwin or FreeBSD, so I'm afraid
> I have to rely on others to check these fixes.

It didn't fix for me. And this time I ran compilation with "memoryuse" limit set
to 128M and "vmemorysize" limit set to 512M, and back trace is not so helpful:

#v+
#1528 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#1529 0x000000000066d852 in _malloc_internal (size=1016) at gmalloc.c:901
#1530 0x000000000066d8cd in malloc (size=1016) at gmalloc.c:925
#1531 0x000000000066ec3c in calloc (nmemb=1, size=1016) at gmalloc.c:1492
#1532 0x00000008080764bd in ?? () from /lib/libthr.so.3
#1533 0x0000000808076d5b in ?? () from /lib/libthr.so.3
#1534 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#1535 0x000000000066d852 in _malloc_internal (size=1016) at gmalloc.c:901
#1536 0x000000000066d8cd in malloc (size=1016) at gmalloc.c:925
#1537 0x0000000000000000 in ?? ()
#v-

HTH
-- 
Ashish SHUKLA

“We are not an endangered species ourselves yet, but this is not for lack of
trying.” (Douglas Adams, "Last Chance to See", 1991)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[wahjava.ml]

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

On Wed, 03 Jul 2013 17:58:10 -0700, Paul Eggert <eggert@cs.ucla.edu> said:
> [CC'ing to 14569@debbugs.gnu.org as I think it's related
> to that bug....]

> On 07/03/2013 09:00 AM, Ashish SHUKLA wrote:

>> I tried bzr revision r113270 on my FreeBSD 9.1-RELEASE (amd64), and it
>> segfaulted during bootstrap process...
>> #v+
>> #3367385 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
>> #3367386 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
>> #3367387 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
>> #3367388 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
>> #3367389 0x00000008080764bd in ?? () from /lib/libthr.so.3
>> #3367390 0x0000000808076d5b in ?? () from /lib/libthr.so.3
>> #3367391 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
>> #3367392 0x000000000066d846 in _malloc_internal (size=1016) at gmalloc.c:901
>> #3367393 0x000000000066d8c1 in malloc (size=1016) at gmalloc.c:925
>> #3367394 0x000000000066ec30 in calloc (nmemb=1, size=1016) at gmalloc.c:1492
> ...

> This is no doubt fallout from trunk bzr 113247, needed for
> Cygwin.  I installed what I hope fixes the problem for
> FreeBSD, without reintroducing the Cygwin bug, as trunk
> bzr 113275; please give it a try.

> I don't use either Cygwin or FreeBSD, so I'm afraid
> I have to rely on others to check these fixes.

It didn't fix for me. And this time I ran compilation with "memoryuse" limit set
to 128M and "vmemorysize" limit set to 512M, and back trace is not so helpful:

#v+
#1528 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#1529 0x000000000066d852 in _malloc_internal (size=1016) at gmalloc.c:901
#1530 0x000000000066d8cd in malloc (size=1016) at gmalloc.c:925
#1531 0x000000000066ec3c in calloc (nmemb=1, size=1016) at gmalloc.c:1492
#1532 0x00000008080764bd in ?? () from /lib/libthr.so.3
#1533 0x0000000808076d5b in ?? () from /lib/libthr.so.3
#1534 0x00000008080742c6 in pthread_mutex_lock () from /lib/libthr.so.3
#1535 0x000000000066d852 in _malloc_internal (size=1016) at gmalloc.c:901
#1536 0x000000000066d8cd in malloc (size=1016) at gmalloc.c:925
#1537 0x0000000000000000 in ?? ()
#v-

HTH
-- 
Ashish SHUKLA

“We are not an endangered species ourselves yet, but this is not for lack of
trying.” (Douglas Adams, "Last Chance to See", 1991)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#14569: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Paul Eggert]

On 07/03/2013 07:27 PM, wahjava.ml@gmail.com wrote:
> It didn't fix for me.

OK, please try again, with trunk bzr 113278.
Again, I can't easily test this on either Cygwin or FreeBSD.

Also, please don't CC: to emacs-devel@gnu.org, as this
is just a bug and is not worth bothering all Emacs developers
about.  CC:ing to 14569@debbugs.gnu.org should suffice.

bug#14569: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Ken Brown]

On 7/4/2013 2:23 AM, Paul Eggert wrote:
> On 07/03/2013 07:27 PM, wahjava.ml@gmail.com wrote:
>> It didn't fix for me.
>
> OK, please try again, with trunk bzr 113278.
> Again, I can't easily test this on either Cygwin or FreeBSD.

Still OK on Cygwin.

Ken

Re: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Giorgos Keramidas]

On Wed, 03 Jul 2013 17:54:25 -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:
> I think this is fallout from Bug#14569, and
> I'll reply there.

Thanks Paul!

The emacs-24 branch builds correctly on FreeBSD 10.0-CURRENT here.  So I
just pulled your commit from the trunk ofr the Git repository and tried
a local build again from this revision:

  $ git ll -1
  5da8d1b - (HEAD, origin/trunk, trunk) Try again to fix FreeBSD bug re multithreaded memory alloc. (3 hours ago) <Paul Eggert>

with the following options:

    ./configure --prefix=/opt/gnu --without-x

This compiled Emacs successfully on FreeBSD, and resulted in the
following output from configure:

   Configured for `amd64-unknown-freebsd10.0'.

     Where should the build process find the source code?    /git/emacs
     What compiler should emacs be built with?               cc -g3 -O2
     Should Emacs use the GNU version of malloc?             yes
     Should Emacs use a relocating allocator for buffers?    no
     Should Emacs use mmap(2) for buffer allocation?         yes
     What window system should Emacs use?                    none
     What toolkit should Emacs use?                          none
     Where do we find X Windows header files?                NONE
     Where do we find X Windows libraries?                   NONE
     Does Emacs use -lXaw3d?                                 no
     Does Emacs use -lXpm?                                   no
     Does Emacs use -ljpeg?                                  no
     Does Emacs use -ltiff?                                  no
     Does Emacs use a gif library?                           no
     Does Emacs use -lpng?                                   no
     Does Emacs use -lrsvg-2?                                no
     Does Emacs use imagemagick?                             no
     Does Emacs use -lgpm?                                   no
     Does Emacs use -ldbus?                                  no
     Does Emacs use -lgconf?                                 no
     Does Emacs use GSettings?                               no
     Does Emacs use a file notification library?             no
     Does Emacs use access control lists?                    yes
     Does Emacs use -lselinux?                               no
     Does Emacs use -lgnutls?                                no
     Does Emacs use -lxml2?                                  yes
     Does Emacs use -lfreetype?                              no
     Does Emacs use -lm17n-flt?                              no
     Does Emacs use -lotf?                                   no
     Does Emacs use -lxft?                                   no
     Does Emacs use toolkit scroll bars?                     no

bug#14569: Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation.

[Ashish SHUKLA]

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

On Wed, 03 Jul 2013 23:23:50 -0700, Paul Eggert <eggert@cs.ucla.edu> said:
> On 07/03/2013 07:27 PM, wahjava.ml@gmail.com wrote:
>> It didn't fix for me.

> OK, please try again, with trunk bzr 113278.
> Again, I can't easily test this on either Cygwin or FreeBSD.

r113278 compiles fine on 9.1-RELEASE (amd64), and sending this email from
r113284.

> Also, please don't CC: to emacs-devel@gnu.org, as this
> is just a bug and is not worth bothering all Emacs developers
> about.  CC:ing to 14569@debbugs.gnu.org should suffice.

Sorry.

Thanks
-- 
Ashish SHUKLA

“It has been said that a careful reading of Anna Karenina, if it teaches you
nothing else, will teach you how to make strawberry jam.” (Julian Mitchell,
"Radio Times", 30 October 1976)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#14569: bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

[Katsumi Yamaoka]

I'm closing these two bugs:

bug#14569: 24.3.50; bootstrap fails on Cygwin
bug#14766: 24.3.50; sometimes "Memory exhausted" on Cygwin

Katsumi Yamaoka wrote:
> Ken Brown wrote:
>> On 7/3/2013 6:01 AM, Katsumi Yamaoka wrote:
>>> Paul Eggert wrote:
>>>> On 07/02/2013 08:24 PM, Ken Brown wrote:
>>>>> Is it possible that gfilenotify doesn't work well with the lucid toolkit?
>>>>> Or perhaps the tickling of glib causes problems when the lucid
>>>>> toolkit is used?
>>>
>>>> It's possible, but lucid isn't multithreaded.
>>>
>>>> What happens if you append --without-file-notification
>>>> to the 'configure' options?  I expect that's what's
>>>> dragging in glib.
>>>
>>> I tried --without-file-notification.  AFAICT no difference presents,
>>> if anything, I feel like the frequency of the freezing is increased.
>>> Emacs links cygglib-2.0-0.dll .

>> What if you also add --without-rsvg?

> Oh, Emacs was built without glib.  It still sometimes freezes,
> though I haven't seen "Memory exhausted" yet so far.  I'll keep
> trying it.  Thanks.

I don't know why, sorry, but Emacs on Cygwin doesn't make the memory
exhausted, it doesn't freeze, and it bootstraps smoothly these days.
`system-configuration-options' I use now is:
	"--verbose --with-x-toolkit=lucid --without-imagemagick\
	--without-dbus --without-gconf --without-gsettings"
I.e., Emacs is built with glib.

Thanks.

As for the derived bug
"Emacs segfaulting on FreeBSD 9.1-RELEASE (amd64) during memory allocation."
that is labeled with bug#14569 (the same), I believe it's been solved:

http://thread.gmane.org/gmane.emacs.devel/161494/focus=75909