The callstack (opening the _crash file in a text editor):
pc 0x30cd7d libxpc.dylib _sigtramp+29
# 1 pc 0x398fc3 dmengine ares__sortaddrinfo+643
# 2 pc 0x39b0bb dmengine end_hquery+75
# 3 pc 0x3a1843 dmengine qcallback+19
# 4 pc 0x3a0a3e dmengine end_query+270
# 5 pc 0x3a142d dmengine process_answer+1741
# 6 pc 0x39fc7f dmengine processfds+1775
# 7 pc 0x2a45e0 dmengine _ZN5dmDNS13GetHostByNameEPKcPN8dmSocket7AddressEPNS_7ChannelEibb+480
# 8 pc 0x25a1ae dmengine _ZN16dmConnectionPool6DoDialEPNS_14ConnectionPoolEPKctPN5dmDNS7ChannelEbiPjPN8dmSocket6ResultEbb+126
# 9 pc 0x25a8a1 dmengine _ZN16dmConnectionPool4DialEPNS_14ConnectionPoolEPKctPN5dmDNS7ChannelEbiPjPN8dmSocket6ResultE+193
#10 pc 0x2663a5 dmengine _ZN12dmHttpClient8Response7ConnectEPKctbi+165
#11 pc 0x266d1f dmengine _ZN12dmHttpClientL9DoRequestEPNS_6ClientEPKcS3_+255
#12 pc 0x1acad3 dmengine _ZN13dmHttpService13HandleRequestEPNS_6WorkerEPKN9dmMessage3URLEPN9dmHttpDDF11HttpRequestE+659
#13 pc 0x1acd0f dmengine _ZN13dmHttpService8DispatchEPN9dmMessage7MessageEPv+63
#14 pc 0x27c89c dmengine _ZN9dmMessage16InternalDispatchEyPFvPNS_7MessageEPvES2_b+652
#15 pc 0x1acec8 dmengine _ZN13dmHttpService4LoopEPv+72
#16 pc 0x289e3c dmengine _ZN8dmThreadL16ThreadStartProxyEPv+28
#17 pc 0x2c8950 libxpc.dylib _pthread_start+224
The callstack looks ok (valid), so I trust it.
The issue is http request related (the dmHttpService::HandleRequest).
Since http requests work most of the time, I think something more special occurred, like the request timed out.
In the 1.2.181 BETA we fixed a number of issues related to the http.requests, and I think #5672 might fix this issue.
On a related note, we’re also considering removing the cares
library altogether, but that won’t happen until the 1.2.182 at the earliest)