Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3BB9EFBC.4D6C88B2@rowman.com> Date: Tue, 02 Oct 2001 12:47:56 -0400 From: John Peacock MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: 1.3.3: Core's during testing of debugging bleadperl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Recent releases of bleadperl (5.8.0-to-be) are dumping core during make test but not during cd t && ./perl harness and the only thing that (significantly) differs between these is a specific flag (see below). The cores only show up when building a debugging version of Perl. For example, download and build a recent snapshot: http://www.iki.fi/jhi/perl AT 12258 DOT tgz using the conventional sh ./Configure -des -Dusedevel -D"optimize=-g" make make test and dozens of tests will fail with: 0 [main] perl 2092 open_stackdumpfile: Dumping stack trace to perl.exe.stackdump Segmentation fault (core dumped) errors. Running the same test will succeed under harness or run directly. For example ./perl.exe -I../lib op/mkdir.t will suceed and PERL_DESTRUCT_LEVEL=2 ./perl.exe -I../lib op/mkdir.t will dump core after the last test. I have tried to enable the dumper.exe utility, but this generates a core file which cannot be loaded into gdb because it causes gdb to core (and dump another file). :~( I have reduced the code required to core to the following trivial line: PERL_DESTRUCT_LEVEL=2 ./miniperl -e "\$ENV{'TEST'} = 1;" which will core with any recent (the last two months) bleadperl, but not under 5.6.1. If I run that line under gdb directly, I get: $ gdb -nw ./miniperl GNU gdb 5.0 (20010428-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) break Perl_safesysfree Breakpoint 1 at 0x44260a: file util.c, line 153. (gdb) run -e "\$ENV{'TEST'} = 1;" Starting program: /home/JPeacock/perl-DEVEL11005/./miniperl.exe -e "\$ENV{'TEST' } = 1;" gdb: unknown target exception 0x000006d1 at 0x77e87e08 Program received signal ?, Unknown signal. 0x77e87e08 in _libkernel32_a_iname () (gdb) bt #0 0x77e87e08 in _libkernel32_a_iname () #1 0x0022f408 in ?? () #2 0x77d5895a in _libkernel32_a_iname () #3 0x751511cb in _libkernel32_a_iname () #4 0x751aa114 in _libkernel32_a_iname () #5 0x751a8755 in _libkernel32_a_iname () #6 0x61067cec in _libkernel32_a_iname () #7 0x61068256 in _libkernel32_a_iname () #8 0x61003d4f in _libkernel32_a_iname () #9 0x6100421d in _libkernel32_a_iname () #10 0x6100425c in _libkernel32_a_iname () #11 0x004efd83 in cygwin_crt0 () at /cygnus/netrel/src/cygwin-1.3.3-2/winsup/cygwin/lib/cygwin_crt0.c:33 (gdb) which certainly looks like something has stomped on the stack. And this is whether or not I have PERL_DESTRUCT_LEVEL=2; just running it under gdb is sufficient. I am not able to sucessfully set a break point at any function that I know is being called (based on the stackdump file). At this point, I know I don't have enough to blame CygWin or Perl as the culprit. I am looking mostly for guidance on how to proceed to debug this. I know I had debugging Perl's testing fine, so I am going to try and downgrade to 1.3.2 and see if some of the problems go away. Thanks in advance John p.s. strace available on request (but I cannot see any real difference between the run with PERL_DESTRUCT_LEVEL=2 and not set). -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/