DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18F87385E457
Message-ID: <97a2a8e3-0a6e-470d-a45d-15ffa876ea17@dronecode.org.uk>
Date: Thu, 30 May 2024 20:39:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf
References: <20240526131145 DOT E733 DOT 50F79699 AT gmail DOT com>
 <f12d6965-9ed9-4cae-bf6e-ebddc2c093b6 AT cornell DOT edu>
 <20240527181731 DOT 3FD9 DOT 50F79699 AT gmail DOT com>
 <b9ebc9cd-6e82-463d-8035-b6e145a4f84b AT cornell DOT edu>
Content-Language: en-US
Cc: cygwin AT cygwin DOT com
In-Reply-To: <b9ebc9cd-6e82-463d-8035-b6e145a4f84b@cornell.edu>
Precedence: list
From: Jon Turney via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Jon Turney <jon DOT turney AT dronecode DOT org DOT uk>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 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??)


-- 
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