Reputation: 2810
I have protocols
that I use to describe various types of Vectors
, and some shared functionality for all of them. I use this to get diagonal, aspectFit, aspectFill, etc. I have enabled Address Sanitizer
in scheme
. Unfortunately when I try to use generic function that should return array of all vector's axes, address sanitizer reports some error.
protocol Vector {
associatedtype ValueType: FloatingPoint
func allAxesValues<V>() -> [V] where V == ValueType
}
protocol Vector2D: Vector {
init(x: ValueType, y: ValueType)
var x: ValueType { get set }
var y: ValueType { get set }
}
extension Vector2D {
func allAxesValues<V>() -> [V] where V == Self.ValueType {
return [x, y]
}
}
extension CGSize: Vector2D {}
let test = CGSize(width: 100, height: 200)
let a = test.allAxesValues()
Address sanitizer reports this:
==1775==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x00016fabb7a8 at pc 0x000101d7ba50 bp 0x00016fabb730 sp 0x00016fabb728
READ of size 8 at 0x00016fabb7a8 thread T0
#0 0x101d7ba4f in $SSo6CGSizeV8FindloAR8Vector2DA2cDP1x9ValueTypeQzvgTW (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x9ba4f)
#1 0x101d32923 in $S8FindloAR8Vector2DPAAE13allAxesValuesSayqd__Gy9ValueTypeQzRsd__lF (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x52923)
#2 0x101d7bd67 in $SSo6CGSizeV8FindloAR6VectorA2cDP13allAxesValuesSayqd__Gy9ValueTypeQzRsd__lFTW (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x9bd67)
#3 0x101d34977 in $S8FindloAR8Vector2DPAAE14aspectFunction33_752D57C238B0CAACA3665849AD14E727LL0D6ToSize8functionxx_Sb9ValueTypeQz_AItXEtF (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x54977)
#4 0x101d356f3 in $S8FindloAR8Vector2DPAAE9aspectFit9fitToSizexx_tF (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x556f3)
#5 0x101da2157 in $SSo7UIImageC8FindloARE19updateMediaNodeSize20augmentedRealityView4node05mediaF08animatedy09AugmentedI00niJ4BaseC_ypypSbtF (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0xc2157)
#6 0x101da22af in $SSo7UIImageC8FindloAR0B5MediaA2cDP06updateD8NodeSize20augmentedRealityView4node05mediaF08animatedy09AugmentedI00niJ4BaseC_ypypSbtFTW (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0xc22af)
#7 0x101df492b in $S8FindloAR0A30AugmentedRealityViewObjectNodePAAE010updateMainG4Size8animatedySb_tF (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x11492b)
#8 0x101df04cf in $S8FindloAR0A30AugmentedRealityViewObjectNodePAAE09setupMainG12DisplayLayeryyF (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x1104cf)
#9 0x101df0ac3 in $S8FindloAR0A30AugmentedRealityViewObjectNodePAAE5setupyyFyAA0A5Media_pSg_AFtcfU_ (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x110ac3)
#10 0x101db8997 in $S8FindloAR0A5Media_pSgACIeggg_A2CIegnn_TR (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0xd8997)
#11 0x10202197b in $S11Observation12ObservationsV19executeNotification33_DF89E5A0D3A6524E6B622E937DD6C8FBLL03forA08oldValue03newR0yA2ACyxG_xxtFyycfU_ (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/Observation.framework/Observation:arm64+0x597b)
#12 0x1020219df in $SIeg_IeyB_TR (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/Observation.framework/Observation:arm64+0x59df)
#13 0x10052f893 in __wrap_dispatch_async_block_invoke (/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/libclang_rt.asan_ios_dynamic.dylib:arm64+0x4b893)
#14 0x102c8f83f in _dispatch_call_block_and_release (/usr/lib/system/introspection/libdispatch.dylib:arm64+0x383f)
#15 0x102c90de3 in _dispatch_client_callout (/usr/lib/system/introspection/libdispatch.dylib:arm64+0x4de3)
#16 0x102c9ea93 in _dispatch_main_queue_callback_4CF (/usr/lib/system/introspection/libdispatch.dylib:arm64+0x12a93)
#17 0x1f42a21bb in <redacted> (/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation:arm64+0xac1bb)
#18 0x1f429d083 in <redacted> (/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation:arm64+0xa7083)
#19 0x1f429c5b7 in CFRunLoopRunSpecific (/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation:arm64+0xa65b7)
#20 0x1f650d583 in GSEventRunModal (/System/Library/PrivateFrameworks/GraphicsServices.framework/GraphicsServices:arm64+0xb583)
#21 0x2208947ab in UIApplicationMain (/System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore:arm64+0x3657ab)
#22 0x10035651b in main (/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Findlo:arm64+0x10001651b)
#23 0x1f3d5cc0b in <redacted> (/usr/lib/system/libdyld.dylib:arm64+0xc0b)
Address 0x00016fabb7a8 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow (/private/var/containers/Bundle/Application/E56F108E-F784-461F-BBA5-2E8A4198DB7E/Findlo.app/Frameworks/FindloAR.framework/FindloAR:arm64+0x9ba4f) in $SSo6CGSizeV8FindloAR8Vector2DA2cDP1x9ValueTypeQzvgTW
Shadow bytes around the buggy address:
0x0001310b76a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0001310b76b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0001310b76c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0001310b76d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0001310b76e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0001310b76f0: ca ca ca ca 00[cb]cb cb cb cb cb cb ca ca ca ca
0x0001310b7700: 00 cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
0x0001310b7710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0001310b7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0001310b7730: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
0x0001310b7740: 00 00 cb cb cb cb cb cb ca ca ca ca 00 00 cb cb
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==1775==ABORTING
AddressSanitizer report breakpoint hit. Use 'thread info -s' to get extended information about the report.
What does it mean? How can I fix it? If I disable Address sanitizer
, then code works fine. This code is a little simplified, but I hope it's enough. If not, I will try to prepare sample project.
Upvotes: 2
Views: 6249
Reputation: 7534
Address Sanitizer
does not report false positives so you certainly have a problem; "working fine" probably means "getting lucky".
You should build a debug build with symbols intact to better see what is happening since all these names are mangled.
Your SSo6CGSizeV8FindloAR8Vector2DA2cDP1x9ValueTypeQzvgTW
(is that supposed to be something like CGSize Findlo(Vector2D, ValueType)
?) method is accessing out of bounds memory on the stack, that is all that i can say with what is here.
You should post the code for that method and the parameters you are calling it with for a better answer. You can also just look there to see what variables are allocated on the stack (probably an array) and maybe see how they might be going out of bounds.
The reason this appears to be working fine is likely that you either don't call any functions after the overflow occurs (adding another stack frame), or you never access the overflowed memory after doing so. if you did add a new stack frame you would see the data you overflowed with would become corrupted by the new frame data.
Upvotes: 6