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.E733.50F79699@gmail.com>
 <f12d6965-9ed9-4cae-bf6e-ebddc2c093b6@cornell.edu>
 <20240527181731.3FD9.50F79699@gmail.com>
 <b9ebc9cd-6e82-463d-8035-b6e145a4f84b@cornell.edu>
Content-Language: en-US
Cc: cygwin@cygwin.com
In-Reply-To: <b9ebc9cd-6e82-463d-8035-b6e145a4f84b@cornell.edu>
Precedence: list
From: Jon Turney via Cygwin <cygwin@cygwin.com>
Reply-To: Jon Turney <jon.turney@dronecode.org.uk>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.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