search

swiftlang / swift

The Swift Programming Language
https://swift.org
Apache License 2.0
67.31k stars 10.34k forks source link

[SR-15680] EXC_BAD_ACCESS error using withTaskGroup #57959

Open swift-ci opened 2 years ago

swift-ci commented 2 years ago
Previous ID SR-15680
Radar None
Original Reporter Stefan Springer (JIRA User)
Type Bug
Environment Swift 5.5.2 on macOS 12.0.1 (ARM), UPDATE: also with macOS 12.1 (ARM)
Additional Detail from JIRA | | | |------------------|-----------------| |Votes | 0 | |Component/s | swift | |Labels | Bug, Concurrency | |Assignee | None | |Priority | Medium | md5: cab31ad2eaa04857aab2c34d5f394e13

Issue Description:

I am getting EXC_BAD_ACCESS errors using withTaskGroup when using larger data. See my demo Swift package https://github.com/stefanspringer1/BadAccessDemo.git [UPDATE: better see the other repository mentioned in the next paragraph]. In my real project, I could avoid the error by keeping track outside of withTaskGroup of the date used, but then I cannot remove that data from the tracking (I then get EXC_BAD_ACCESS errors again), and this "trick" did not work for the demo project. It seems that the data just dissapears.

UPDATE: A second repository https://github.com/stefanspringer1/BadAccessDemo2.git is more succinct. Also see the discussion on https://forums.swift.org/t/exc-bad-access-using-withtaskgroup-depending-on-size-of-data/54506. I am getting an EXC_BAD_ACCESS when using withTaskGroup in this way, depending on how big the structure being built is, the structure being of same kind, and being completely read and then written, so the structure itself should be OK. The start of the crash data for the second repository is:

Translated Report (Full Report Below)

Process: BadAccessDemo2 [51166]
Path: /Users/USER/*/BadAccessDemo2
Identifier: BadAccessDemo2
Version: ???
Code Type: ARM-64 (Native)
Parent Process: zsh [47252]
Responsible: Terminal [47250]
User ID: 501

Date/Time: 2022-01-07 21:31:04.0692 +0100
OS Version: macOS 12.0.1 (21A559)
Report Version: 12
Anonymous UUID: AC3DEC9D-06B9-3E64-2D4B-44D808CBB77B

Sleep/Wake UUID: 6E6113C5-9465-476E-A068-3B373C450C7B

Time Awake Since Boot: 470000 seconds
Time Since Wake: 19757 seconds

System Integrity Protection: enabled

Crashed Thread: 1 Dispatch queue: com.apple.root.user-initiated-qos.cooperative

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000016fcdfff0
Exception Codes: 0x0000000000000002, 0x000000016fcdfff0
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process: exc handler [51166]

VM Region Info: 0x16fcdfff0 is in 0x16fcdc000-0x16fce0000; bytes after start: 16368 bytes before end: 15
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
Stack 16f4e0000-16fcdc000 [ 8176K] rw-/rwx SM=PRV thread 0
--> STACK GUARD 16fcdc000-16fce0000 [ 16K] --/rwx SM=NUL ... for thread 1
Stack 16fce0000-16fd68000 [ 544K] rw-/rwx SM=PRV thread 1

Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1bdfbd954 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x1bdfbdd00 machmsg + 76
2 CoreFoundation 0x1be0c4e38 __CFRunLoopServiceMachPort + 372
3 CoreFoundation 0x1be0c32f0 \_CFRunLoopRun + 1212
4 CoreFoundation 0x1be0c2694 CFRunLoopRunSpecific + 600
5 CoreFoundation 0x1be14ec28 CFRunLoopRun + 64
6 libswift_Concurrency.dylib 0x23b5e8ee8 swift_task_asyncMainDrainQueueImpl() + 40
7 libswift_Concurrency.dylib 0x23b5e8ec0 swift_task_asyncMainDrainQueue + 100
8 BadAccessDemo2 0x100127d04 BadAccessDemo2_main + 84
9 dyld 0x10059d0f4 start + 520

Thread 1 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos.cooperative
0 libswiftCore.dylib 0x1cb3da1b4 swift_arrayDestroy + 4
1 libswiftCore.dylib 0x1cb125794 _DictionaryStorage.deinit + 268
2 libswiftCore.dylib 0x1cb1258c8 DictionaryStorage._deallocating_deinit + 16
3 libswiftCore.dylib 0x1cb3e7774 _swift_releasedealloc + 56
4 BadAccessDemo2 0x10015de14 XElement.deinit + 60
5 BadAccessDemo2 0x10015de48 XElement.\_deallocating_deinit + 12
6 libswiftCore.dylib 0x1cb3e7774 _swift_releasedealloc + 56
7 libswiftCore.dylib 0x1cb3e8724 bool swift::HeapObjectSideTableEntry::decrementStrong\<(swift::PerformDeinit)1>(unsigned int) + 292
8 BadAccessDemo2 0x10015de2c XElement.deinit + 84
9 BadAccessDemo2 0x10015de48 XElement.\_deallocating_deinit + 12
10 libswiftCore.dylib 0x1cb3e7774 _swift_release_dealloc + 56
11 libswiftCore.dylib 0x1cb3e8724 bool swift::HeapObjectSideTableEntry::decrementStrong\<(swift::PerformDeinit)1>(unsigned int) + 292
...

swift-ci commented 2 years ago

Comment by Stefan Springer (JIRA)

The reason might be a deep recursion of deinits, see https://bugs.swift.org/browse/SR-15803 for this issue.

tomerd commented 2 years ago

cc @ktoso @DougGregor

msdrigg commented 2 weeks ago

I am seeing this in the latest XCode (16.0 beta 6)

mikeash commented 1 week ago

This does indeed look like https://github.com/swiftlang/swift/issues/58080. The task group is incidental here, and the issue is caused by destroying a very deep object graph. This is something I'd like to improve at some point, but that's how it works now. As a workaround, avoid creating extremely deep (in the thousands or tens of thousands of levels) object graphs, or write a bit of non-recursive code to break the links from the bottom up.