On Wed, Feb 05, 2020 at 04:11:04PM -0500, John Cowan wrote: > On Mon, Feb 3, 2020 at 5:11 PM szgyg <sz...@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
