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: <3BC333FF.23E05C83@rowman.com> Date: Tue, 09 Oct 2001 13:29:35 -0400 From: John Peacock MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Perl 5.7.2 References: <3BC30401 DOT 2D09A965 AT rowman DOT com> <3BC341F5 DOT 12093 DOT C1DD7 AT localhost> <20011009125532 DOT A24952 AT redhat DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > > > I've duplicated the stack dump. It's coming from free and it is due > to memory corruption. Something in perl is corrupting the heap. > > AFAICT, it isn't a Cygwin problem. > > I suspect that there might be some problem with a misconfigured perl, > maybe? I know that perl can use its own version of malloc. I wonder > if some memory that is allocated by perl's malloc has been passed to > cygwin's malloc for freeing. If so, then *boom*. That is a distinct possibility. I could see that Perl_safesysfree was being called, but all of those things should have been created with Perl_safemalloc. These are both wrappers around the system malloc() and free() so it is an avenue of investigation at least. I'll look at the wrapper code and see if there is anything that has changed recently. But, would this mean that if miniperl is being run under gdb, there would be no core dump? Because that is the behavior I am seeing (once I downgraded to CygWin 1.3.2-2). -- 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/