Hi Jon,
On Fri, 16 May 2025 21:14:00 +0900
Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> On Fri, 16 May 2025 13:46:21 +0200
> Christian Franke wrote:
> > Testcase:
> >
> > $ uname -r # Also occurs with 3.6.1-1.x86_64
> > 3.7.0-0.95.g854150fda310.x86_64
> >
> > $ cat sigsegv.c
> > int main()
> > {
> > *(volatile char *)0 = 0;
> > return 42; // NOTREACHED
> > }
> >
> > $ gcc -o sigsegv sigsegv.c
> >
> > $ ./sigsegv # OK
> > Segmentation fault
> >
> > $ echo $?
> > 139
> >
> > $ (sleep 5; taskkill /f /im strace.exe) & strace ./sigsegv # Infinite loop
> > ...
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000100401092
> > --- Process 11224 (pid: 2162), exception c0000005 at 0000000
> > SUCCESS: ... (localized message from taskkill)
> >
> >
> > The problem also occurs if a SIGSEGV handler is present. The handler
> > code is not executed if strace is used but works as expected without strace.
>
> I could reproduce that. And also found cygwin 3.4.10 does not have this
> issue. I'll look into this.
I could bisect the issue and found the next commit triggered the issue.
commit 91457377d6c9f89a08b1b70e45cbae87ef467119
Author: Jon Turney <jon.tur...@dronecode.org.uk>
Date: Thu Jan 11 20:00:14 2024 +0000
Cygwin: Make 'ulimit -c' control writing a coredump
Pre-format a command to be executed on a fatal error to run 'dumper'
(using an absolute path).
Factor out executing a pre-formatted command, so we can use that for
invoking the JIT debugger in try_to_debug() (if error_start is present
in the CYGWIN env var) and to invoke dumper when a fatal error occurs.
On a fatal error, if the core file size limit is greater than 1MB,
invoke dumper to write a core dump. Otherwise, if that limit is greater
than 0, write a .stackdump file, as previously.
Adjust and clarify the associated documentation.
Also: Fix so that the error_start JIT debugger is now invoked, even when
ulimit -c is zero.
Also: Fix uses of console_printf() inside exec_prepared_command(). It's
output is written via the Windows console device, so needs to use
Windows-style line endings.
Also: consistently return non-zero from try_to_debug() if we debugged.
Future work: Truncate or remove the file written, if it exceeds the
maximum size set by the ulimit.
Future work: Using the words "fatal error" could probably be improved
on. This means exiting on one of the "certain signals whose default
action is to cause the process to terminate and produce a core dump
file".
I also found the following patch fixes the issue. I'm not sure
this is the right thing, so could you please have a look?
diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index 9763a1b04..aea2821f6 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -597,7 +597,7 @@ try_to_debug ()
{
extern void break_here ();
break_here ();
- return 1;
+ return 0;
}
/* Otherwise, invoke the JIT debugger, if set */
--
Takashi Yano <takashi.y...@nifty.ne.jp>
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
