On Thu, 30 May 2024 18:29:17 -0400, Ken Brown via Cygwin > On 5/30/2024 3:39 PM, Jon Turney via Cygwin wrote: > > On 27/05/2024 16:14, Ken Brown via Cygwin wrote: > >> On 5/27/2024 5:17 AM, Lemures Lemniscati via Cygwin wrote: > >>> On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin > >>> Here is a log from gdb. Will it help? > >>> run > >>> info threads > >>> info stack > >>> list > >>> > >>> > >>> $ HOME=/tmp gdb --args asy -vv -f pdf test > >> [...] > >>> Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap. > >> > >> I don't get this SIGRAP when I run the same command. The program just > >> runs to completion. Maybe someone can explain what might cause this. > >> I have no idea. > > > > Getting SIGTRAP rather than SIGSEGV or whatever here seems like it might > > be an unintended consequence of the dumper changes I made in 3.5.0. > > > >> 0 0x00007ffd8487d313 in KERNELBASE!DebugBreak () from > >> /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > >> #1 0x00007ffd527f6367 in break_here () at > >> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:472 > >> #2 0x00007ffd52810349 in try_to_debug () at > >> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:597 > >> #3 exception::handle (e=0x28bc6f0, frame=<optimized out>, > >> in=0x28bc200, dispatch=<optimized out>) > >> at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:810 > >> #4 0x00007ffd871b49ff in ntdll!.chkstk () from > >> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > >> #5 0x00007ffd8712e466 in ntdll!RtlFindCharInUnicodeString () from > >> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > >> #6 0x00007ffd871b39ee in ntdll!KiUserExceptionDispatcher () from > >> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > >> #7 0x00007ffd5291bdd4 in init_cygheap::find_tls (this=0x800000000, > >> sig=20, issig_wait=@0x28bca3f: false) > > > > The important thing in this backtrace is that an exception is occurring > > in find_tls, not that we break into the debugging while handling it > > (rather than rethrowing the exception to let the debugger handle it, > > which is maybe what should happen? and did in previous versions of > > Cygwin??) > > Thanks. So find_tls, running in the "sig" thread, is getting an > exception while Cygwin is trying to process signal 20. The latter is > SIGCHLD. Based on Lem's original report, I would guess that the SIGCHLD > is generated by ghostscript exiting when it finishes processing the > file. An error in processing the signal would explain the fact that asy > hangs. > > I'm not familiar enough with Cygwin's signal-handling code to be able to > debug this, especially since I can't reproduce the problem. > > It would be helpful if others could try Lem's recipe and see if they can > reproduce it.
An additional report: On one of my machines, the issue (signal SIGTRAP) is resolved by updating Windows 11 Pro to H23H2 Build 22631.3672. But, on another one, it still occurs. Lem -- 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
