Crashed: com.apple.CFNetwork.LoaderQ

Question

Created 6d

Replies 3

Boosts 0

Participants 2

com.apple.main-thread 0 StarMaker 0x5c40854 _isPlatformVersionAtLeast.cold.2 + 4425680980 1 StarMaker 0x526d278 -[FPRScreenTraceTracker displayLinkStep] + 191 (FPRScreenTraceTracker.m:191) 2 QuartzCore 0xbe924 CA::Display::DisplayLinkItem::dispatch(CA::SignPost::Interval<(CA::SignPost::CAEventCode)835322056>&) + 64 3 QuartzCore 0x9bf38 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 880 4 QuartzCore 0xaf770 CA::Display::DisplayLink::dispatch_deferred_display_links(unsigned int) + 360 5 UIKitCore 0x7dee4 _UIUpdateSequenceRunNext + 128 6 UIKitCore 0x7d374 schedulerStepScheduledMainSectionContinue + 60 7 UpdateCycle 0x1560 UC::DriverCore::continueProcessing() + 84 8 CoreFoundation 0x164cc __CFMachPortPerform + 168 9 CoreFoundation 0x460b0 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 60 10 CoreFoundation 0x45fd8 __CFRunLoopDoSource1 + 508 11 CoreFoundation 0x1dc1c __CFRunLoopRun + 2168 12 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 13 GraphicsServices 0x1498 GSEventRunModal + 120 14 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 15 UIKitCore 0x46e54 UIApplicationMain + 336 16 StarMaker 0x50c965c main + 18 (main.m:18) 17 ??? 0x19a9dae28 (缺少)

Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x27d30 zorro::KbLog::Loop() + 88 (kblog.cc:88) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8

Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19a4e4 zorro::ZkbLog::Loop() + 157 (zlog.cc:157) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8

Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19c4d8 zorro::QosManager::Loop() + 966 (string:966) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8

Answered by DTS Engineer in 880103022

Again, I recommend that you review tip 5 of Quinn’s Top Ten DevForums Tips. Your reply above is barely readable.

Focusing on the crash report, it comes from a third-party crash reporter. I don’t trust such reports in general. See Implementing Your Own Crash Reporter for a detailed explanation as to why. And in this specific case it doesn’t contain the information I need. I was hoping to get an Apple crash report, ideally one in JSON format.

As to what’s happening here:

com.apple.CFNetwork.LoaderQ is the name of the thread on which URLSession runs its core functionality.
CFNetwork is calling down to Network framework.
Which is, in turn, calling down to the QUIC implementation.
That’s crashing for some reason, but it’s hard to offer any insight given the very limited information in this third-party crash report (it has no OS version, no binary image list, no register state, and so on).

If you can find an Apple crash report for this, I’d be happy to take another look.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

5d

Accepted Answer

Please post a full Apple crash report for this. See Posting a Crash Report for advice on how to do that.

ps I also recommend that you read through Quinn’s Top Ten DevForums Tips, and particularly tip 5.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

kakoAoteman OP

5d

Crash location：

Crashed thread：com.apple.CFNetwork.LoaderQ

Crash framework：libquic.dylib

Crash function：

quic_fc_service_pending_send_data + 360

Crash stack:

Crashed: com.apple.CFNetwork.LoaderQ 0 libquic.dylib 0x36d84 quic_fc_service_pending_send_data + 360

1 libquic.dylib 0x3bcf0 _quic_conn_outbound_stopping_block_invoke 2 + 28

2 Network 0x23e428 nw_protocol_instance_access_flow_state + 136

3 libquic.dylib 0x3bcb8 __quic_conn_outbound_stopping_block_invoke + 744

4 libquic.dylib 0x3b754 quic_conn_outbound_stopping + 168

5 Network 0x3559b4 nw_protocol_implementation_finalize_output_frames + 576

6 Network 0x67308 nw_flow_service_writes + 5264

7 Network 0x58944 nw_endpoint_handler_add_write_request + 4860

8 Network 0x57880 nw_endpoint_handler_add_write_request + 568

9 Network 0x575a4 nw_connection_add_write_request_on_queue + 228

10 Network 0x5c314 nw_connection_async_if_needed + 76

11 Network 0x573c4 nw_connection_add_write_request + 312

12 Network 0x56868 nw_connection_send + 516

13 CFNetwork 0x66b30 NWIOConnection::writeWithContext + 380

14 CFNetwork 0xa53f4 HTTP3Framer::writeFrame + 536

15 CFNetwork 0xa8ac8 HTTP3Stream::_sendHEADERS + 2384

16 CFNetwork 0xa7ef0 invocation function for block in HTTP3Stream::scheduleAndOpenWithHandler + 316

17 CFNetwork 0xada7c HTTP3Connection::_tryCreateBidirectionalStreams + 620

18 CFNetwork 0xa6b28 HTTP3Stream::scheduleAndOpenWithHandler + 3184

19 CFNetwork 0x64ba0 HTTPProtocol::useNetStreamInfoForRequest + 3340

20 CFNetwork 0xad538 HTTP3ConnectionCacheEntry::enqueueRequestForProtocol + 2500

21 CFNetwork 0xb3ec4 HTTP3ConnectionCacheWrapper::enqueueRequestForProtocol + 128

...``

**Crash analysis:

issue_da165ae3b7947c32f9747f769e65eeff_crash_session_dceeb349f1044f7a84d14c9468f68490_DNE_4_v2_stacktrace.txt

**

This crash occurred within the Apple system framework, specifically in the QUIC protocol implementation of libquic.dylib. The crash function quic_fc_service_pending_send_data is part of the QUIC flow control mechanism, responsible for handling the data streams to be sent. From the stack trace, we can see: The crash occurred during the sending stage of the HTTP/3 request. Regarding the operations of HTTP3Stream::_sendHEADERS and HTTP3Connection An exception occurred when accessing the stream state during the quic_conn_outbound_stopping process.

0

Answer 3

DTS Engineer OP

Apple

2d

Recommended

Again, I recommend that you review tip 5 of Quinn’s Top Ten DevForums Tips. Your reply above is barely readable.

Focusing on the crash report, it comes from a third-party crash reporter. I don’t trust such reports in general. See Implementing Your Own Crash Reporter for a detailed explanation as to why. And in this specific case it doesn’t contain the information I need. I was hoping to get an Apple crash report, ideally one in JSON format.

As to what’s happening here:

com.apple.CFNetwork.LoaderQ is the name of the thread on which URLSession runs its core functionality.
CFNetwork is calling down to Network framework.
Which is, in turn, calling down to the QUIC implementation.
That’s crashing for some reason, but it’s hard to offer any insight given the very limited information in this third-party crash report (it has no OS version, no binary image list, no register state, and so on).

If you can find an Apple crash report for this, I’d be happy to take another look.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0