URLRequest(url:cachePolicy:timeoutInterval:) started to crash in iOS 26

Something went wrong with you posting your crash report. The crash report says that you crashed on thread 10:

Triggered by Thread:  10

which matches the snippet you posted, but the crash report contains no thread 10 )-:

It’s possible that forums munged it )-: Please download your own crash report and see if it matches what you tried to post. If so, I’d like to get you to file a bug against the forums. But we’ll cross that bridge once we’ve confirmed it’s burning (-:

Regardless, I need to see the full crash report. If you posted the right file and forums is munging it, you’ll need to share it some other way. The best way to do that is to upload it to a file sharing site and then post the URL.

If you run into problems posting the URL, see tip 14 of Quinn’s Top Ten DevForums Tips.

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

@DTS Engineer thanks for noticing that... arghh, maybe I attached it as 'Text':

:)

@DTS Engineer it seems like .crash-files gets translated into text-file... so I can no longer attach it. I will try to upload it and share a link instead...

[For those following along at home, I got a non-corrupted copy of bims’s crash report via other means.]

Consider the crashing thread backtrace:

0  libsystem_malloc.dylib … _xzm_xzone_malloc_freelist_outlined + 864 (xzone_malloc.c:1869)
1  libswiftCore.dylib     … swift::swift_slowAllocTyped(unsigned long, unsigned long, unsigned long long) + 56 …
2  libswiftCore.dylib     … swift_allocObject + 136 (HeapObject.cpp:245)
3  Foundation             … specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growFo…
… …
9  Foundation             … URLRequest.init(url:cachePolicy:timeoutInterval:) + 92 (URLRequest.swift:44)
10 Live                   … Fetcher.fetchData(withPathAndQuery:httpHeaderFields:for:withTimeout:andCompletion:)…

Frame 10 shows your code creating a URLRequest, frames 9 through 3 are it working its way through Foundation, frames 2 and 1 are the Swift runtime, and frame 0 is the system memory allocator.

Unfortunately I just updated my iOS 26 test device to iOS 26.1, so it’s hard to be 100% sure what’s going on here. However, I suspect that iOS 26.1 and 26.0 have basically the same code, and if you disassemble the crashing instruction on iOS 26.1 you see tihs:

(lldb) disas -n _xzm_xzone_malloc_freelist_outlined
libsystem_malloc.dylib`_xzm_xzone_malloc_freelist_outlined:
    …
    0x192a19078 <+828>:  mov    x8, x4
    0x192a1907c <+832>:  stp    x20, x21, [sp, #-0x10]!
    0x192a19080 <+836>:  adrp   x20, 60
    0x192a19084 <+840>:  add    x20, x20, #0xc6c          ; "BUG IN CLIENT OF LIBMALLOC: memory corruption of free block"
    0x192a19088 <+844>:  adrp   x21, 378706
    0x192a1908c <+848>:  add    x21, x21, #0x638          ; gCRAnnotations
    0x192a19090 <+852>:  str    x20, [x21, #0x8]
    0x192a19094 <+856>:  str    x8, [x21, #0x38]
    0x192a19098 <+860>:  ldp    x20, x21, [sp], #0x10
    0x192a1909c <+864>:  brk    #0x1
    …

Note the brk instruction at +864. That gels with this line from your crash report:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)

So, the memory allocator has trapped. And the message at +840 is pretty darned suspicious.

Next, look at thread 11:

Thread 11:
0 libsystem_malloc.dylib  … _xzm_free_abort + 36 (xzone_malloc.c:2311)
1 libsystem_malloc.dylib  … _xzm_free + 1340 (xzone_malloc.c:4739)
2 libsystem_blocks.dylib  … _Block_release + 260 (runtime.cpp:1019)
3 libdispatch.dylib       … _dispatch_client_callout + 16 (client_callout.mm:85)
4 libdispatch.dylib       … <deduplicated_symbol> + 32 (:-1)
5 libdispatch.dylib       … _dispatch_workloop_invoke + 1980 (queue.c:4761)
6 libdispatch.dylib       … _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265)
7 libdispatch.dylib       … _dispatch_workloop_worker_thread + 692 (queue.c:6859)
8 libsystem_pthread.dylib … _pthread_wqthread + 292 (pthread.c:2696)
9 libsystem_pthread.dylib … start_wqthread + 8 (:-1)

Frame 1 shows that some is freeing memory and frame 0 shows that the memory allocator is just about to abort.

So, threads 10 and 11 have both trapped due to memory corruption. That seems like a smoking gun.

As to what’s caused that memory corruption, it’s hard to say. My advice in such situations is to run your program under the standard memory debugging tools. These can help make the problem more reproducible, and reliably reproducing the problem is key to investigations like this.

Oh, and if you have a shiny new iPhone 17, try enabling MTE. That’s can be really helpful in situations like this. See Enabling enhanced security for your app for more.

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