GNU bug report logs - #39118
3.0.0 JIT segfaults on 64-bit Cygwin

Previous Next

Full log

Message #61 received at 39118 <at> debbugs.gnu.org (full text, mbox):

From: szgyg <szgyg <at> ludens.elte.hu>
To: John Cowan <cowan <at> ccil.org>
Cc: 39118 <at> debbugs.gnu.org, guile-devel <at> gnu.org
Subject: Re: bug#39118: Segfault while building on 64-bit Cygwin
Date: Wed, 5 Feb 2020 23:42:50 +0100

On Wed, Feb 05, 2020 at 04:11:04PM -0500, John Cowan wrote:
> On Mon, Feb 3, 2020 at 5:11 PM szgyg <szgyg <at> ludens.elte.hu> wrote:
> 
> On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> > > Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows,
> > after
> > > all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> > > [...]
> >
> > Please see my previous mail on how to get a real core dump on cygwin
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28
> 
> 
> Okay, I looked at that page.  However, Cygwin's dumper requires you to know
> the Windows PID of the process to dump.  Clearly it is intended for a
> long-running process such as a server process, which you can force to core
> dump, as if by "/bin/kill -SIGSEGV pid"; it is not suitable for a process
> that gets a segmentation violation for internal reasons.  In any case, when
> building, I have no idea of the pid of the process which is dumping; it
> starts up and then dumps immediately.


| One common way to use dumper is to plug it into cygwin's Just-In-Time
| debugging facility by adding
| error_start=x:\path\to\dumper.exe
| to the CYGWIN environment variable. Please note that x:\path\to\dumper.exe
| is Windows-style and not cygwin path. If error_start is set this way, then
| dumper will be started whenever some program encounters a fatal error.


s

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.