Stak dump with tar.[bz2/gz] files (Cygwin)

Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

I want to flag that current CVS 23.0.60 of Emacs stack dumps when
loading tar.[bz2/gz] files, on Cygwin.

This happens with simple file like this

$ cat hello.c
/* hello.c */
#include <stdio.h>

int main()
{
    printf("Hello World\n");
}

$ tar -cjf hello.tar.bz2 hello.c

$ emacs -Q&
C-x C-f /tmp/hello.tar.bz2 RET

and after bunzipping it stack dumps

$
[2]+  Aborted                 (core dumped) emacs -Q


If the file is a simple .tar (hello.tar):

$ emacs -Q&
C-x C-f /tmp/hello.tar RET

the file is loaded BUT...

...BUT closing it (click on the 'x' of the tool-bar) and reloading

C-x C-f /tmp/hello.tar RET

still aborts:

$
[1]+  Aborted                 (core dumped) emacs -Q


The last useful CVS which works fine with tar files is that

cvs ... -D "27 May 2008 12:00"

Instead, the first which does NOT work is -D "28 May 2008 12:00".

I haven't searched between these two dates (hours).

 From the lisp/ChangeLog I see  that about May 27 there was several 
changes to tar mode.


Cheers,
    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Stefan Monnier]

> I want to flag that current CVS 23.0.60 of Emacs stack dumps when
> loading tar.[bz2/gz] files, on Cygwin.

> This happens with simple file like this

> $ cat hello.c
> /* hello.c */
> #include <stdio.h>

> int main()
> {
>    printf("Hello World\n");
> }

> $ tar -cjf hello.tar.bz2 hello.c

> $ emacs -Q&
> C-x C-f /tmp/hello.tar.bz2 RET

> and after bunzipping it stack dumps

Can you try and run it in a debugger to give us a backtrace?
Also, try to recompile with -DENABLE_CHECKING so as to hopefully catch
the bug earlier.


        Stefan

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Stefan Monnier ha scritto:
 >
> Can you try and run it in a debugger to give us a backtrace?
> Also, try to recompile with -DENABLE_CHECKING so as to hopefully catch
> the bug earlier.

As I have written (more times) in this list, I am not expert of gdb...

In any case, with my original build:

============================================
$ gdb /usr/local/emacs/bin/emacs.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run -Q
Starting program: /usr/local/emacs/bin/emacs.exe -Q
[New thread 4060.0xb4]
[New thread 4060.0xcc]
[New thread 4060.0x648]
[New thread 4060.0xc0]
[New thread 4060.0x100]
[New thread 4060.0x104]
[New thread 4060.0x67c]

C-x C-f /tmp/hello1.tar.bz2

[New thread 4060.0xb8]
[New thread 4060.0x2fc]
       3 [sig] emacs 4060 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump

Program exited with code 0103000.
(gdb) bt
No stack.
(gdb)
============================================

Rebuilding with -DENABLE_CHECKING, the only difference is that starting 
Emacs (run -Q), it prints the warning:

'Warning (initialization): Building Emacs overflowed pure space.  (See 
the node Pure Storage in the Lisp manual for details.)'


Cheers,
    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Stefan Monnier]

> As I have written (more times) in this list, I am not expert of gdb...

"C'est en forgeant que l'on devient forgeron".
I.e. the more you use it, the better you'll be at using it.

> (gdb) run -Q
> Starting program: /usr/local/emacs/bin/emacs.exe -Q
> [New thread 4060.0xb4]
> [New thread 4060.0xcc]
> [New thread 4060.0x648]
> [New thread 4060.0xc0]
> [New thread 4060.0x100]
> [New thread 4060.0x104]
> [New thread 4060.0x67c]

> C-x C-f /tmp/hello1.tar.bz2

> [New thread 4060.0xb8]
> [New thread 4060.0x2fc]
>       3 [sig] emacs 4060 open_stackdumpfile: Dumping stack trace to
> emacs.exe.stackdump

> Program exited with code 0103000.
> (gdb) bt
> No stack.

Hmm... you'll have to ask Cygwin people how to get a backtrace, then.


        Stefan

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Stefan Monnier ha scritto:

> 
> Hmm... you'll have to ask Cygwin people how to get a backtrace, then.

In the past there were similar situations and asking we haven't gained 
much. So this time I will not try. Sorry.

The gdb usage I posted was wrong?

For the sake of completeness, when Emacs stack dumps, it creates this file:

$ cat emacs.exe.stackdump
Stack trace:
Frame     Function  Args
0022B188  7C802542  (000004C0, 0000EA60, 000000A4, 0022B1D0)
0022B2A8  61097F34  (00000000, 00000000, 00000000, 00000000)
0022B398  61095ACB  (00000000, 003B0023, 00230000, 0022CE68)
0022B3F8  61095FAB  (0022B410, 00000000, 00000094, 004CF656)
0022B4B8  61096162  (000000C8, 00000006, 0070D801, FFFEFEFF)
0022B4E8  61093588  (00000006, 60030000, 0022B618, 61098028)
0022B5D8  61017BE0  (000004C0, 0000EA60, 000000A4, 0022B620)
0022B6F8  61098028  (00000000, 00000003, 0022B808, 00000009)
0022B7E8  61095ACB  (00000000, 01165539, 00000002, 00000000)
0022B848  61095FAB  (0022B860, 00000000, 00000094, 011A8D43)
0022B908  61096162  (000000C8, 00000006, 0022B938, 0056A345)
0022B918  61093588  (0000002F, 018F3000, 0070D801, 0107BC00)
0022B938  0056A345  (0107BC08, 00000859, 0070D801, 007201B3)
0022B958  004C7C6F  (0107BC00, 00000844, 00000000, 00000000)
0022B988  004D188C  (00000074, 00000001, 00000000, 011DB073)
0022B9C8  004D2850  (00000088, 00000088, 00000000, 00000000)
End of stack trace (more stack frames may be present)


Cheers,
   Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Stefan Monnier]

>> Hmm... you'll have to ask Cygwin people how to get a backtrace, then.

> In the past there were similar situations and asking we haven't gained
> much. So this time I will not try. Sorry.

> The gdb usage I posted was wrong?

Not that I could tell, which is why I need help from
Cygwin-knowledgeable people.

> For the sake of completeness, when Emacs stack dumps, it creates this file:

It's at least as meaningless to me as it is to you :-(


        Stefan

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Thu, 12 Jun 2008 22:00:42 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: emacs-devel@gnu.org
> 
> C-x C-f /tmp/hello1.tar.bz2
> 
> [New thread 4060.0xb8]
> [New thread 4060.0x2fc]
>        3 [sig] emacs 4060 open_stackdumpfile: Dumping stack trace to 
> emacs.exe.stackdump
> 
> Program exited with code 0103000.

This is not helpful.  For some reason, GDB didn't catch the signal.
(Is that "3" the signal number or something else?)

Apart of asking on the Cygwin list what does this all mean, I'd
suggest to do this, once you are inside GDB, but _before_ the "run -Q"
command:

 (gdb) handle all print

Beware: this will cause GDB to catch the SIGINT signal generated when
you press C-g in Emacs, so try to avoid using C-g in this session.

Also, I think the two new threads above are spawned to handle the
signal.  Maybe you can set a breakpoint in open_stackdumpfile, and
then, when that breakpoint is hit, see where the main thread caught
the signal.

> GNU gdb 6.8.0.20080328-cvs (cygwin-special)

If the above doesn't help, perhaps try using a stable release of GDB
instead of a CVS snapshot, to avoid being hit by some regression
introduced into the development code.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Thu, 12 Jun 2008 23:56:09 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: emacs-devel@gnu.org
> 
> $ cat emacs.exe.stackdump
> Stack trace:
> Frame     Function  Args
> 0022B188  7C802542  (000004C0, 0000EA60, 000000A4, 0022B1D0)
> 0022B2A8  61097F34  (00000000, 00000000, 00000000, 00000000)
> 0022B398  61095ACB  (00000000, 003B0023, 00230000, 0022CE68)
> 0022B3F8  61095FAB  (0022B410, 00000000, 00000094, 004CF656)
> 0022B4B8  61096162  (000000C8, 00000006, 0070D801, FFFEFEFF)
> 0022B4E8  61093588  (00000006, 60030000, 0022B618, 61098028)
> 0022B5D8  61017BE0  (000004C0, 0000EA60, 000000A4, 0022B620)
> 0022B6F8  61098028  (00000000, 00000003, 0022B808, 00000009)
> 0022B7E8  61095ACB  (00000000, 01165539, 00000002, 00000000)
> 0022B848  61095FAB  (0022B860, 00000000, 00000094, 011A8D43)
> 0022B908  61096162  (000000C8, 00000006, 0022B938, 0056A345)
> 0022B918  61093588  (0000002F, 018F3000, 0070D801, 0107BC00)
> 0022B938  0056A345  (0107BC08, 00000859, 0070D801, 007201B3)
> 0022B958  004C7C6F  (0107BC00, 00000844, 00000000, 00000000)
> 0022B988  004D188C  (00000074, 00000001, 00000000, 011DB073)
> 0022B9C8  004D2850  (00000088, 00000088, 00000000, 00000000)
> End of stack trace (more stack frames may be present)

Inside GDB, type "info symbol 0xNNNNNNNN" for each of the above lines,
where NNNNNNNN is the number in the "Function" column.  This should
display the name of each function in the stack dump.  Also, you can
type "list *0xNNNNNNNN" (note the asterisk: it's important), which
will show the source around the addresses in the stack dump.  That, at
least, will glean some useful information from this gobbledygook.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:

> once you are inside GDB, but _before_ the "run -Q"
> command:
> 
>  (gdb) handle all print
>

It prints a long list like this:

(gdb) handle all print
Signal        Stop      Print   Pass to program Description
SIGHUP        Yes       Yes     Yes             Hangup
SIGQUIT       Yes       Yes     Yes             Quit
SIGILL        Yes       Yes     Yes             Illegal instruction
SIGABRT       Yes       Yes     Yes             Aborted
SIGEMT        Yes       Yes     Yes             Emulation trap
SIGFPE        Yes       Yes     Yes             Arithmetic exception
SIGKILL       Yes       Yes     Yes             Killed
SIGBUS        Yes       Yes     Yes             Bus error
SIGSEGV       Yes       Yes     Yes             Segmentation fault
SIGSYS        Yes       Yes     Yes             Bad system call
[...]

the rest as before.

> Also, I think the two new threads above are spawned to handle the
> signal.  Maybe you can set a breakpoint in open_stackdumpfile, and
> then, when that breakpoint is hit, see where the main thread caught
> the signal.

Where is open_stackdumpfile? I think it belongs to Cygwin sources...

> 
>> GNU gdb 6.8.0.20080328-cvs (cygwin-special)
> 
> If the above doesn't help, perhaps try using a stable release of GDB
> instead of a CVS snapshot, to avoid being hit by some regression
> introduced into the development code.

That is the official version which comes with Cygwin, not my choose...

    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:

> Inside GDB, type "info symbol 0xNNNNNNNN" for each of the above lines,
> where NNNNNNNN is the number in the "Function" column.  This should
> display the name of each function in the stack dump.  

Some results:

[...]
       3 [sig] emacs 3908 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump

Program exited with code 0103000.
(gdb) info symbol 0x7C802542
WaitForSingleObject + 18 in section .text
(gdb) info symbol 0x61097F34
sig_send(_pinfo*, siginfo_t&, _cygtls*) + 2788 in section .text
(gdb) info symbol 0x61095ACB
_pinfo::kill(siginfo_t&) + 235 in section .text
(gdb) info symbol 0x61095FAB
kill0(int, siginfo_t&) + 107 in section .text
(gdb) info symbol 0x61096162
kill + 66 in section .text
(gdb) info symbol 0x61093588
_sigbe in section .text
(gdb) info symbol 0x61017BE0
_cygtls::call_signal_handler() + 144 in section .text
(gdb) info symbol 0x61098028
sig_send(_pinfo*, siginfo_t&, _cygtls*) + 3032 in section .text
(gdb) info symbol 0x61095ACB
_pinfo::kill(siginfo_t&) + 235 in section .text
(gdb) info symbol 0x61095FAB
kill0(int, siginfo_t&) + 107 in section .text
(gdb) info symbol 0x61096162
kill + 66 in section .text
(gdb) info symbol 0x61093588
_sigbe in section .text
(gdb) info symbol 0x0056A345
r_re_alloc + 149 in section .text
(gdb) info symbol 0x004C7C6F
enlarge_buffer_text + 47 in section .text
(gdb) info symbol 0x004D188C
make_gap_larger + 60 in section .text
(gdb) info symbol 0x004D2850
insert_from_string_1 + 544 in section .text


> Also, you can
> type "list *0xNNNNNNNN" (note the asterisk: it's important), which
> will show the source around the addresses in the stack dump.  That, at
> least, will glean some useful information from this gobbledygook.

idem:

(gdb) list *0x7C802542
No source file for address 0x7c802542.
(gdb) list *0x61097F34
No source file for address 0x61097f34.
(gdb) list *0x61095ACB
No source file for address 0x61095acb.
(gdb) list *0x61095FAB
No source file for address 0x61095fab.
(gdb) list *0x61096162
No source file for address 0x61096162.
(gdb) list *0x61093588
No source file for address 0x61093588.
(gdb) list *0x61017BE0
No source file for address 0x61017be0.
(gdb) list *0x61098028
No source file for address 0x61098028.
(gdb) list *0x61095ACB
No source file for address 0x61095acb.
(gdb) list *0x61095FAB
No source file for address 0x61095fab.
(gdb) list *0x61096162
No source file for address 0x61096162.
(gdb) list *0x61093588
No source file for address 0x61093588.
(gdb) list *0x0056A345
0x56a345 is in r_re_alloc (/work/emacs-23.0.60/src/ralloc.c:1016).
1011         SIZE size;
1012    {
1013      register bloc_ptr bloc;
1014
1015      if (! r_alloc_initialized)
1016        r_alloc_init ();
1017
1018      if (!*ptr)
1019        return r_alloc (ptr, size);
1020      if (!size)
(gdb) list *0x004C7C6F
0x4c7c6f is in enlarge_buffer_text (/work/emacs-23.0.60/src/buffer.c:5056).
5051      p = r_re_alloc ((POINTER_TYPE **) &b->text->beg, nbytes);
5052    #else
5053      p = xrealloc (b->text->beg, nbytes);
5054    #endif
5055
5056      if (p == NULL)
5057        {
5058          UNBLOCK_INPUT;
5059          memory_full ();
5060        }
(gdb) list *0x004D188C
0x4d188c is in make_gap_larger (/work/emacs-23.0.60/src/insdel.c:529).
524         error ("Buffer exceeds maximum size");
525
526       enlarge_buffer_text (current_buffer, nbytes_added);
527
528       /* Prevent quitting in move_gap.  */
529       tem = Vinhibit_quit;
530       Vinhibit_quit = Qt;
531
532       real_gap_loc = GPT;
533       real_gap_loc_byte = GPT_BYTE;
(gdb) list *0x004D2850
0x4d2850 is in insert_from_string_1 (/work/emacs-23.0.60/src/insdel.c:1107).
1102      prepare_to_modify_buffer (PT, PT, NULL);
1103
1104      if (PT != GPT)
1105        move_gap_both (PT, PT_BYTE);
1106      if (GAP_SIZE < outgoing_nbytes)
1107        make_gap (outgoing_nbytes - GAP_SIZE);
1108      UNGCPRO;
1109
1110      /* Copy the string text into the buffer, perhaps converting
1111         between single-byte and multibyte.  */

If the above infos are useful, we are very fortunate...

Cheers,
    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Fri, 13 Jun 2008 17:45:23 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: emacs-devel@gnu.org
> 
> > Also, I think the two new threads above are spawned to handle the
> > signal.  Maybe you can set a breakpoint in open_stackdumpfile, and
> > then, when that breakpoint is hit, see where the main thread caught
> > the signal.
> 
> Where is open_stackdumpfile? I think it belongs to Cygwin sources...

So?  You can put a breakpoint on a function even if its sources are
not available.

The idea was to stop Emacs when it is about to dump core, and then see
what happens in the application thread.

> >> GNU gdb 6.8.0.20080328-cvs (cygwin-special)
> > 
> > If the above doesn't help, perhaps try using a stable release of GDB
> > instead of a CVS snapshot, to avoid being hit by some regression
> > introduced into the development code.
> 
> That is the official version which comes with Cygwin, not my choose...

Sigh.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Fri, 13 Jun 2008 17:53:40 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> _sigbe in section .text
> (gdb) info symbol 0x0056A345
> r_re_alloc + 149 in section .text
> (gdb) info symbol 0x004C7C6F
> enlarge_buffer_text + 47 in section .text
> (gdb) info symbol 0x004D188C
> make_gap_larger + 60 in section .text
> (gdb) info symbol 0x004D2850
> insert_from_string_1 + 544 in section .text

Looks like memory allocation problem is back.  Perhaps fiddle with
SHEAP again?

> If the above infos are useful, we are very fortunate...

Why "fortunate"?  What I suggested is a standard method of using GDB
commands to translate addresses into symbols and source code listing.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:

> You can put a breakpoint on a function even if its sources are
> not available.

How?

   Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Sat, 14 Jun 2008 01:29:02 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii ha scritto:
> 
> > You can put a breakpoint on a function even if its sources are
> > not available.
> 
> How?

Like with any other function:

  (gdb) break open_stackdumpfile

The argument to the "break" command can be:

  . a line number ("break 123")
  . an offset ("break +10" or "break "-20")
  . a function name ("break func") -- this is your case
  . a file name and line number ("break foo.c:123")
  . a file name and a function name ("break foo.c:func")
  . an address ("break *0x12345678" or "break &expr")

See the node "Specify Location" in the GDB manual for more info.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:

> Also, I think the two new threads above are spawned to handle the
> signal.  Maybe you can set a breakpoint in open_stackdumpfile, and
> then, when that breakpoint is hit, see where the main thread caught
> the signal.

Here some results:

$ gdb /usr/local/emacs/bin/emacs.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break open_stackdumpfile
Function "open_stackdumpfile" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (open_stackdumpfile) pending.
(gdb) run -Q
Starting program: /usr/local/emacs/bin/emacs.exe -Q
[New thread 3956.0xda8]
[New thread 3956.0xadc]
[New thread 3956.0x478]
[New thread 3956.0xedc]
[New thread 3956.0x178]
[New thread 3956.0xf80]
[New thread 3956.0x9f4]
[New thread 3956.0xde8]
[New thread 3956.0x1a0]
[Switching to thread 3956.0xadc]

Breakpoint 1, 0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll



C-x C-f hello1.tar.bz2
Parsing tar file...done

here Emacs hangs? The portion of overlapped window isn't redisplayed...



(gdb) c
Continuing.
       3 [sig] emacs 3956 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump

Program exited with code 0103000.
(gdb)


As alternative:

[...]
an alternative

[Switching to thread 3692.0xc0c]

Breakpoint 1, 0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
#1  0x6101669e in stackdump () from /usr/bin/cygwin1.dll
#2  0x61017fd5 in _cygtls::signal_exit () from /usr/bin/cygwin1.dll
#3  0x61018638 in sigpacket::process () from /usr/bin/cygwin1.dll
#4  0x61099f57 in wait_sig () from /usr/bin/cygwin1.dll
#5  0x61002f32 in cygthread::callfunc () from /usr/bin/cygwin1.dll
#6  0x61003769 in cygthread::stub () from /usr/bin/cygwin1.dll
#7  0x00001074 in ?? ()
#8  0x00000000 in ?? ()
(gdb) c
Continuing.
       3 [sig] emacs 3692 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump

Program exited with code 0103000.
(gdb)


    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Sun, 15 Jun 2008 03:29:51 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: emacs-devel@gnu.org
> 
> (gdb) run -Q
> Starting program: /usr/local/emacs/bin/emacs.exe -Q
> [New thread 3956.0xda8]
> [New thread 3956.0xadc]
> [New thread 3956.0x478]
> [New thread 3956.0xedc]
> [New thread 3956.0x178]
> [New thread 3956.0xf80]
> [New thread 3956.0x9f4]
> [New thread 3956.0xde8]
> [New thread 3956.0x1a0]
> [Switching to thread 3956.0xadc]
> 
> Breakpoint 1, 0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
> 
> 
> 
> C-x C-f hello1.tar.bz2
> Parsing tar file...done
> 
> here Emacs hangs? The portion of overlapped window isn't redisplayed...
> 
> 
> 
> (gdb) c
> Continuing.
>        3 [sig] emacs 3956 open_stackdumpfile: Dumping stack trace to 
> emacs.exe.stackdump
> 
> Program exited with code 0103000.
> (gdb)
> 
> 
> As alternative:
> 
> [...]
> an alternative
> 
> [Switching to thread 3692.0xc0c]
> 
> Breakpoint 1, 0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
> (gdb) bt
> #0  0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
> #1  0x6101669e in stackdump () from /usr/bin/cygwin1.dll
> #2  0x61017fd5 in _cygtls::signal_exit () from /usr/bin/cygwin1.dll
> #3  0x61018638 in sigpacket::process () from /usr/bin/cygwin1.dll
> #4  0x61099f57 in wait_sig () from /usr/bin/cygwin1.dll
> #5  0x61002f32 in cygthread::callfunc () from /usr/bin/cygwin1.dll
> #6  0x61003769 in cygthread::stub () from /usr/bin/cygwin1.dll
> #7  0x00001074 in ?? ()
> #8  0x00000000 in ?? ()

This backtrace is in the wrong thread.  You need to switch to the
thread that runs the main Emacs code, I'm guessing that's the 1st or
the second of the threads announced after "run -Q" above.  The command
"info threads" should tell you more about each thread.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:
> 
> This backtrace is in the wrong thread.  You need to switch to the
> thread that runs the main Emacs code, I'm guessing that's the 1st or
> the second of the threads announced after "run -Q" above.  

Hot to switch?


> The command
> "info threads" should tell you more about each thread.

$ gdb /usr/local/emacs/bin/emacs.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break open_stackdumpfile
Function "open_stackdumpfile" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (open_stackdumpfile) pending.
(gdb) run -Q
Starting program: /usr/local/emacs/bin/emacs.exe -Q
[New thread 2100.0x204]
[New thread 2100.0x250]
[New thread 2100.0xb30]
[New thread 2100.0xe48]
[New thread 2100.0xe28]
[New thread 2100.0xcf0]
[New thread 2100.0x454]
[New thread 2100.0xaa8]
[New thread 2100.0xe10]
[Switching to thread 2100.0x250]

Breakpoint 1, 0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
(gdb) info threads
   9 thread 2100.0xe10  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
   8 thread 2100.0xaa8  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
   7 thread 2100.0x454  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
   6 thread 2100.0xcf0  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
   5 thread 2100.0xe28  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
   4 thread 2100.0xe48  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
   3 thread 2100.0xb30  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
* 2 thread 2100.0x250  0x61016416 in open_stackdumpfile ()
    from /usr/bin/cygwin1.dll
   1 thread 2100.0x204  0x7c91e4f4 in ntdll!LdrAccessResource ()
    from /c/WINDOWS/system32/ntdll.dll
(gdb) c
Continuing.
       3 [sig] emacs 2100 open_stackdumpfile: Dumping stack trace to 
emacs.exe.stackdump

Program exited with code 0103000.
(gdb)


    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Sun, 15 Jun 2008 14:50:10 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii ha scritto:
> > 
> > This backtrace is in the wrong thread.  You need to switch to the
> > thread that runs the main Emacs code, I'm guessing that's the 1st or
> > the second of the threads announced after "run -Q" above.  
> 
> Hot to switch?

 (gdb) thread N

where N is the ordinal number of the thread shown by GDB in the 1st
column of the "info threads" output:

> (gdb) info threads
>    9 thread 2100.0xe10  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
>    8 thread 2100.0xaa8  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
>    7 thread 2100.0x454  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
>    6 thread 2100.0xcf0  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
>    5 thread 2100.0xe28  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
>    4 thread 2100.0xe48  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
>    3 thread 2100.0xb30  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll
> * 2 thread 2100.0x250  0x61016416 in open_stackdumpfile ()
>     from /usr/bin/cygwin1.dll
>    1 thread 2100.0x204  0x7c91e4f4 in ntdll!LdrAccessResource ()
>     from /c/WINDOWS/system32/ntdll.dll

I think "thread 1" is what you want.  But if it doesn't produce a
useful backtrace, try others (except 2, which you already saw is in
the Cygwin signal handler) until you see something familiar.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:
>> Date: Sun, 15 Jun 2008 14:50:10 +0200
>> From: Angelo Graziosi  
>> Hot to switch?
> 
>  (gdb) thread N

> I think "thread 1" is what you want.  But if it doesn't produce a
> useful backtrace, try others (except 2, which you already saw is in
> the Cygwin signal handler) until you see something familiar.

If I have followed the right procedure... this is the result:

$ gdb /usr/local/emacs/bin/emacs.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break open_stackdumpfile
Function "open_stackdumpfile" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (open_stackdumpfile) pending.
(gdb) run -Q
Starting program: /usr/local/emacs/bin/emacs.exe -Q
[New thread 3092.0xc10]
[New thread 3092.0x8bc]
[New thread 3092.0x8b4]
[New thread 3092.0x8c0]
[New thread 3092.0x8a8]
[New thread 3092.0x8a4]
[New thread 3092.0xc20]
[New thread 3092.0xc0c]
[New thread 3092.0xc48]
[Switching to thread 3092.0x8bc]

Breakpoint 1, 0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
(gdb) thread 1
[Switching to thread 1 (thread 3092.0xc10)]#0  0x7c91e4f4 in 
ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
/c/WINDOWS/system32/ntdll.dll
#1  0x7c91df3c in ntdll!ZwWaitForSingleObject ()
    from /c/WINDOWS/system32/ntdll.dll
#2  0x7c8025db in WaitForSingleObjectEx ()
    from /c/WINDOWS/system32/kernel32.dll
#3  0x0000049c in ?? ()
#4  0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (thread 3092.0x8bc)]#0  0x61016416 in 
open_stackdumpfile
     () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
#1  0x6101669e in stackdump () from /usr/bin/cygwin1.dll
#2  0x61017fd5 in _cygtls::signal_exit () from /usr/bin/cygwin1.dll
#3  0x61018638 in sigpacket::process () from /usr/bin/cygwin1.dll
#4  0x61099f57 in wait_sig () from /usr/bin/cygwin1.dll
#5  0x61002f32 in cygthread::callfunc () from /usr/bin/cygwin1.dll
#6  0x61003769 in cygthread::stub () from /usr/bin/cygwin1.dll
#7  0x00001074 in ?? ()
#8  0x00000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (thread 3092.0x8b4)]#0  0x7c91e4f4 in 
ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
/c/WINDOWS/system32/ntdll.dll
#1  0x7c91d1fc in ntdll!ZwDelayExecution () from 
/c/WINDOWS/system32/ntdll.dll
#2  0x71a22b67 in WahQueueUserApc () from /c/WINDOWS/system32/ws2help.dll
#3  0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
#4  0x00247b00 in ?? ()
#5  0x02cbcdf0 in ?? ()
#6  0x71a22af1 in WahQueueUserApc () from /c/WINDOWS/system32/ws2help.dll
#7  0x18ec81ec in ?? ()
#8  0xa1000001 in ?? ()
#9  0x71a25078 in WahNotifyAllProcesses () from 
/c/WINDOWS/system32/ws2help.dll
Cannot access memory at address 0x8b55ff8f
(gdb) thread 4
[Switching to thread 4 (thread 3092.0x8c0)]#0  0x7c91e4f4 in 
ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
/c/WINDOWS/system32/ntdll.dll
#1  0x7c91da2c in ntdll!ZwRemoveIoCompletion ()
    from /c/WINDOWS/system32/ntdll.dll
#2  0x719dd394 in SetServiceA () from /c/WINDOWS/System32/mswsock.dll
#3  0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
#4  0x719dd6d7 in SetServiceA () from /c/WINDOWS/System32/mswsock.dll
#5  0x10ec83ec in ?? ()
#6  0x8b084d8b in ?? ()
#7  0x49830441 in ?? ()
#8  0x5653ff04 in ?? ()
#9  0xf8458957 in ?? ()
#10 0x0018a164 in ?? ()
#11 0x016a0000 in bss_sbrk_buffer ()
#12 0x0f6c8889 in ?? ()
#13 0x15ff0000 in ?? ()
#14 0x719d1168 in ?? () from /c/WINDOWS/System32/mswsock.dll
#15 0x6c15ff50 in ?? ()
#16 0xbf719d11 in ?? ()
#17 0x71a0793c in s_perror () from /c/WINDOWS/System32/mswsock.dll
Cannot access memory at address 0x8b55ff8f
(gdb) thread 5
[Switching to thread 5 (thread 3092.0x8a8)]#0  0x7c91e4f4 in 
ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
/c/WINDOWS/system32/ntdll.dll
#1  0x7e3991be in USER32!GetProcessWindowStation ()
    from /c/WINDOWS/system32/user32.dll
#2  0x7e3a776b in USER32!GetMessageA () from /c/WINDOWS/system32/user32.dll
#3  0x610c28a5 in wininfo::winthread () from /usr/bin/cygwin1.dll
#4  0x610c28de in winthread () from /usr/bin/cygwin1.dll
#5  0x61002f32 in cygthread::callfunc () from /usr/bin/cygwin1.dll
#6  0x61003769 in cygthread::stub () from /usr/bin/cygwin1.dll
#7  0x00000000 in ?? ()

(gdb) c
Continuing.
       3 [main] emacs 3092 sig_send: wait for sig_complete event failed, 
signal 6, rc 258, Win32 error 0

Program exited with code 01.
(gdb)


For the sake of completeness, in thread 4 we find 'bss_sbrk_buffer' 
which is defined in src/sheap.c as

char bss_sbrk_buffer[STATIC_HEAP_SIZE];

Trying STATIC_HEAP_SIZE = 25MB does not solve and, sincerely, I do not 
think here is the culprit.

    Angelo

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Sun, 15 Jun 2008 23:45:50 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: emacs-devel@gnu.org
> 
> (gdb) thread 1
> [Switching to thread 1 (thread 3092.0xc10)]#0  0x7c91e4f4 in 
> ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
> (gdb) bt
> #0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
> /c/WINDOWS/system32/ntdll.dll
> #1  0x7c91df3c in ntdll!ZwWaitForSingleObject ()
>     from /c/WINDOWS/system32/ntdll.dll
> #2  0x7c8025db in WaitForSingleObjectEx ()
>     from /c/WINDOWS/system32/kernel32.dll
> #3  0x0000049c in ?? ()
> #4  0x00000000 in ?? ()
> (gdb) thread 2
> [Switching to thread 2 (thread 3092.0x8bc)]#0  0x61016416 in 
> open_stackdumpfile
>      () from /usr/bin/cygwin1.dll
> (gdb) bt
> #0  0x61016416 in open_stackdumpfile () from /usr/bin/cygwin1.dll
> #1  0x6101669e in stackdump () from /usr/bin/cygwin1.dll
> #2  0x61017fd5 in _cygtls::signal_exit () from /usr/bin/cygwin1.dll
> #3  0x61018638 in sigpacket::process () from /usr/bin/cygwin1.dll
> #4  0x61099f57 in wait_sig () from /usr/bin/cygwin1.dll
> #5  0x61002f32 in cygthread::callfunc () from /usr/bin/cygwin1.dll
> #6  0x61003769 in cygthread::stub () from /usr/bin/cygwin1.dll
> #7  0x00001074 in ?? ()
> #8  0x00000000 in ?? ()
> (gdb) thread 3
> [Switching to thread 3 (thread 3092.0x8b4)]#0  0x7c91e4f4 in 
> ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
> (gdb) bt
> #0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
> /c/WINDOWS/system32/ntdll.dll
> #1  0x7c91d1fc in ntdll!ZwDelayExecution () from 
> /c/WINDOWS/system32/ntdll.dll
> #2  0x71a22b67 in WahQueueUserApc () from /c/WINDOWS/system32/ws2help.dll
> #3  0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
> #4  0x00247b00 in ?? ()
> #5  0x02cbcdf0 in ?? ()
> #6  0x71a22af1 in WahQueueUserApc () from /c/WINDOWS/system32/ws2help.dll
> #7  0x18ec81ec in ?? ()
> #8  0xa1000001 in ?? ()
> #9  0x71a25078 in WahNotifyAllProcesses () from 
> /c/WINDOWS/system32/ws2help.dll
> Cannot access memory at address 0x8b55ff8f
> (gdb) thread 4
> [Switching to thread 4 (thread 3092.0x8c0)]#0  0x7c91e4f4 in 
> ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
> (gdb) bt
> #0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
> /c/WINDOWS/system32/ntdll.dll
> #1  0x7c91da2c in ntdll!ZwRemoveIoCompletion ()
>     from /c/WINDOWS/system32/ntdll.dll
> #2  0x719dd394 in SetServiceA () from /c/WINDOWS/System32/mswsock.dll
> #3  0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
> #4  0x719dd6d7 in SetServiceA () from /c/WINDOWS/System32/mswsock.dll
> #5  0x10ec83ec in ?? ()
> #6  0x8b084d8b in ?? ()
> #7  0x49830441 in ?? ()
> #8  0x5653ff04 in ?? ()
> #9  0xf8458957 in ?? ()
> #10 0x0018a164 in ?? ()
> #11 0x016a0000 in bss_sbrk_buffer ()
> #12 0x0f6c8889 in ?? ()
> #13 0x15ff0000 in ?? ()
> #14 0x719d1168 in ?? () from /c/WINDOWS/System32/mswsock.dll
> #15 0x6c15ff50 in ?? ()
> #16 0xbf719d11 in ?? ()
> #17 0x71a0793c in s_perror () from /c/WINDOWS/System32/mswsock.dll
> Cannot access memory at address 0x8b55ff8f
> (gdb) thread 5
> [Switching to thread 5 (thread 3092.0x8a8)]#0  0x7c91e4f4 in 
> ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
> (gdb) bt
> #0  0x7c91e4f4 in ntdll!LdrAccessResource () from 
> /c/WINDOWS/system32/ntdll.dll
> #1  0x7e3991be in USER32!GetProcessWindowStation ()
>     from /c/WINDOWS/system32/user32.dll
> #2  0x7e3a776b in USER32!GetMessageA () from /c/WINDOWS/system32/user32.dll
> #3  0x610c28a5 in wininfo::winthread () from /usr/bin/cygwin1.dll
> #4  0x610c28de in winthread () from /usr/bin/cygwin1.dll
> #5  0x61002f32 in cygthread::callfunc () from /usr/bin/cygwin1.dll
> #6  0x61003769 in cygthread::stub () from /usr/bin/cygwin1.dll
> #7  0x00000000 in ?? ()
> 

What about the other 4 threads? do they also show such an unhelpful
backtrace?  If so, I guess we are stuck with what you produced from
the stack dump file.  Does anyone have a suggestion on how to proceed
with this crash?

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

Eli Zaretskii ha scritto:
> 
> What about the other 4 threads? do they also show such an unhelpful
> backtrace?  If so, I guess we are stuck with what you produced from
> the stack dump file.  Does anyone have a suggestion on how to proceed
> with this crash?
> 
The other threads were like the first, so I have excluded them from the 
report.

The only thing I can say is that CVS dated (-D) "27 May 2008 19:58" 
works and "27 May 2008 19:59" doesn't. 'diff' shows that the differences 
are only in tar-mode.el file (and ChangeLog, excluding */CVS/*).

C-x C-f hello.tar.bz2 RED causes "Parsing tar file...done " in the 
minibuffer and before Emacs can display the contents of tar file (in 
dired mode style), it crashes.

Thanks for the assistance (and patience!).


Cheers,
    Angelo.

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Eli Zaretskii]

> Date: Mon, 16 Jun 2008 22:41:32 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: emacs-devel@gnu.org
> 
> The only thing I can say is that CVS dated (-D) "27 May 2008 19:58" 
> works and "27 May 2008 19:59" doesn't. 'diff' shows that the differences 
> are only in tar-mode.el file (and ChangeLog, excluding */CVS/*).

Can you post the diffs here?

Also, does the problem happen with any tarball, or only with some of
them?

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

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

Eli Zaretskii ha scritto:
>> Date: Mon, 16 Jun 2008 22:41:32 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> CC: emacs-devel@gnu.org
>>
>> The only thing I can say is that CVS dated (-D) "27 May 2008 19:58" 
>> works and "27 May 2008 19:59" doesn't. 'diff' shows that the differences 
>> are only in tar-mode.el file (and ChangeLog, excluding */CVS/*).
> 
> Can you post the diffs here?

Attached.

> 
> Also, does the problem happen with any tarball, or only with some of
> them?

It happens with all tarball I tried (someone created in 2003!). When I 
discovered this casually, I created a simple test case: a tarball with 
only an hello.c file.

If the tarball is a 'tar' only (no compressed, i.e. hello.tar) then [1]

emacs -Q&
C-x C-f hello.tar RET

works, but closing it (i.e. clicking the 'x') and retyping

C-x C-f hello.tar RET

causes Emacs to abort as described (and this with several tar files).

If the tarball is compressed (bz2/gz), Emacs crashes immediately (after 
"Parsing... done)").


Cheers,
    Angelo.

---
[1] Also: "emacs -Q -nw" gives the same results.


[-- Attachment #2: emacs_tar-mode.diff.tar.bz2 --]
[-- Type: application/octet-stream, Size: 7956 bytes --]

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

The patch proposed here

http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00839.html

seems to solve this bug!

(Now, with tar files, there is only the annoying bug #1655)


Many thanks,
       Angelo.


Angelo Graziosi ha scritto:
> I want to flag that current CVS 23.0.60 of Emacs stack dumps when
> loading tar.[bz2/gz] files, on Cygwin.
> 
> This happens with simple file like this
> 
> $ cat hello.c
> /* hello.c */
> #include <stdio.h>
> 
> int main()
> {
>    printf("Hello World\n");
> }
> 
> $ tar -cjf hello.tar.bz2 hello.c
> 
> $ emacs -Q&
> C-x C-f /tmp/hello.tar.bz2 RET
> 
> and after bunzipping it stack dumps
> 
> $
> [2]+  Aborted                 (core dumped) emacs -Q
> 
> 
> If the file is a simple .tar (hello.tar):
> 
> $ emacs -Q&
> C-x C-f /tmp/hello.tar RET
> 
> the file is loaded BUT...
> 
> ...BUT closing it (click on the 'x' of the tool-bar) and reloading
> 
> C-x C-f /tmp/hello.tar RET
> 
> still aborts:
> 
> $
> [1]+  Aborted                 (core dumped) emacs -Q
> 
> 
> The last useful CVS which works fine with tar files is that
> 
> cvs ... -D "27 May 2008 12:00"
> 
> Instead, the first which does NOT work is -D "28 May 2008 12:00".
> 
> I haven't searched between these two dates (hours).
> 
>  From the lisp/ChangeLog I see  that about May 27 there was several 
> changes to tar mode.
> 
> 
> Cheers,
>    Angelo.
> 
> 

Re: Stak dump with tar.[bz2/gz] files (Cygwin)

[Angelo Graziosi]

(Wrong link in my previous post, sorry!)


The patch proposed here

http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-12/msg00642.html

seems to solve this bug!

(Now, with tar files, there is only the annoying bug #1655)


Many thanks,
        Angelo.


Angelo Graziosi ha scritto:
> I want to flag that current CVS 23.0.60 of Emacs stack dumps when
> loading tar.[bz2/gz] files, on Cygwin.
> 
> This happens with simple file like this
> 
> $ cat hello.c
> /* hello.c */
> #include <stdio.h>
> 
> int main()
> {
>    printf("Hello World\n");
> }
> 
> $ tar -cjf hello.tar.bz2 hello.c
> 
> $ emacs -Q&
> C-x C-f /tmp/hello.tar.bz2 RET
> 
> and after bunzipping it stack dumps
> 
> $
> [2]+  Aborted                 (core dumped) emacs -Q
> 
> 
> If the file is a simple .tar (hello.tar):
> 
> $ emacs -Q&
> C-x C-f /tmp/hello.tar RET
> 
> the file is loaded BUT...
> 
> ...BUT closing it (click on the 'x' of the tool-bar) and reloading
> 
> C-x C-f /tmp/hello.tar RET
> 
> still aborts:
> 
> $
> [1]+  Aborted                 (core dumped) emacs -Q
> 
> 
> The last useful CVS which works fine with tar files is that
> 
> cvs ... -D "27 May 2008 12:00"
> 
> Instead, the first which does NOT work is -D "28 May 2008 12:00".
> 
> I haven't searched between these two dates (hours).
> 
>  From the lisp/ChangeLog I see  that about May 27 there was several 
> changes to tar mode.
> 
> 
> Cheers,
>    Angelo.
> 
>