bug#39118: Segfault while building on 64-bit Cygwin

szgyg <[email protected]>
Newsgroups gmane.lisp.guile.bugs
Message-ID <20200205224249.GC1659__3147.86934047646$1580942657$gmane$org@dtk>
On Wed, Feb 05, 2020 at 04:11:04PM -0500, John Cowan wrote:
> On Mon, Feb 3, 2020 at 5:11 PM szgyg <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.