DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 98272385E45C
Date: Fri, 31 May 2024 19:27:54 +0900
To: cygwin AT cygwin DOT com
Subject: Re: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf
In-Reply-To: <c7bd6f0c-504f-4de1-82fb-3b7b71a89cf4@cornell.edu>
References: <97a2a8e3-0a6e-470d-a45d-15ffa876ea17 AT dronecode DOT org DOT uk>
 <c7bd6f0c-504f-4de1-82fb-3b7b71a89cf4 AT cornell DOT edu>
Message-Id: <20240531192752.3D83.50F79699@gmail.com>
MIME-Version: 1.0
Precedence: list
From: Lemures Lemniscati via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Lemures Lemniscati <lemures DOT lemniscati AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

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