[SR-8980] Swift 4.2 runtime Segmentation Fault with release configuration

[swift-ci]

Previous ID	SR-8980
Radar	rdar://problem/45588367
Original Reporter	dlbuckley (JIRA User)
Type	Bug
Status	Resolved
Resolution	Cannot Reproduce

Attachment: Download

Environment

Swift: 4.2
Ubuntu: 16.04

Additional Detail from JIRA

Votes	1
Component/s
Labels	Bug, Linux, OptimizedOnly, RunTimeCrash, Runtime
Assignee	None
Priority	Medium

md5: c146b8eccd37e0dd9f848f4e6238e70d

Issue Description:

We have encountered an issue where Vapor 2.4.5 runs fine on the Swift 4.2 Ubuntu docker image in debug, but as soon as we change to building with the release configuration we get a Segmentation fault 19 out of 20 times we try to run the resulting executable. This doesn't happen when building with Xcode on macOS.

I have raised a bug on the Vapor Github repo (vapor/vapor#1829) informing them of this issue, but since it's a Swift runtime issue I thought it would be best to also raise a bug here so measures can be put in place to prevent it in future.

Reproduction Steps

1. Extract the example project (see attached) and navigate into the directory using terminal.

2. Run

   docker run --rm -it --volume "$(pwd):/app" --workdir /app swift:4.2 /bin/bash

3. Run

   swift build -c release

4. Run the resulting executable

5. Experience a Segmentation fault. (if it doesn't happen right away, stop the executable and run it again)

From a core dump it looks like there is some issue with the dynamic casting:

#&#8203;0  0x00007f5c3d2a3124 in swift_dynamicCastMetatypeImpl(swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*) () from /usr/lib/swift/linux/libswiftCore.so
(gdb) bt
#&#8203;0  0x00007f5c3d2a3124 in swift_dynamicCastMetatypeImpl(swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*) () from /usr/lib/swift/linux/libswiftCore.so
#&#8203;1  0x00007f5c3d052c0a in swift_swiftValueConformsTo () from /usr/lib/swift/linux/libswiftCore.so
#&#8203;2  0x00007f5c3d2a3be5 in _dynamicCastToExistential(swift::OpaqueValue*, swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*, swift::TargetExistentialTypeMetadata<swift::InProcess> const*, swift::DynamicCastFlags) () from /usr/lib/swift/linux/libswiftCore.so
#&#8203;3  0x00007f5c3d2a33fd in checkDynamicCastFromOptional(swift::OpaqueValue*, swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*, swift::DynamicCastFlags)
    () from /usr/lib/swift/linux/libswiftCore.so
#&#8203;4  0x00007f5c3d2a1fcf in swift_dynamicCastImpl(swift::OpaqueValue*, swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*, swift::DynamicCastFlags) ()
   from /usr/lib/swift/linux/libswiftCore.so
#&#8203;5  0x0000559c49f0e480 in $S7Configs6ConfigC5VaporE13customResolve6unique4file7keyPath2as7defaultxSS_SSSaySSGxmxACKXEtKlFAD11LogProtocol_p_Tg5011$S7Configs6b9C5Vapor11lM39_ps5Error_pIggozo_AcdE_psAF_pIeggrzo_TRAcdL_ps0S0_pIggozo_Tf1nnnncn_nTf4xnndnn_nTm ()
#&#8203;6  0x0000559c49f0e03d in $S7Configs6ConfigC5VaporE13customResolve6unique4file7keyPath2as7defaultxSS_SSSaySSGxmxACKXEtKlF7Console0L8Protocol_p_Tg5011$S7Configs6b12C7Console0C8M39_ps5Error_pIggozo_AcdE_psAF_pIeggrzo_TRAclM_ps0T0_pIggozo_Tf1nnnncn_nTf4xnndnn_n ()
#&#8203;7  0x0000559c49f2a7eb in $S5Vapor7DropletC6config6router6server6client10middleware7console3log4hash6cipher8commands4view5cache4mailAC7Configs6ConfigCSg_7Routing6RouterCSgAA21ServerFactoryProtocol_pSgAA06ClientuV0_pSgSay4HTTP10Middleware_pGSg7Console0zV0_pSgAA03LogV0_pSgAA04HashV0_pSgAA06CipherV0_pSgSayA5_7Command_pGSgAA12ViewRenderer_pSg5Cache05CacheV0_pSgAA04MailV0_pSgtKcfcTf4ggnngggnnggnnn_n ()
#&#8203;8  0x0000559c49f28590 in $S5Vapor7DropletCyAC7Configs6ConfigCKcfC ()
#&#8203;9  0x0000559c49eba71d in main ()

[gwynne]

Attached is a somewhat more detailed trace and associated info accessible from LLDB that was generated by reproducing the same crash with a Swift built in RelWithDebInfo configuration and app binary built with -g -O using the Swift 4.2 on Ubuntu 16.04 Docker image.

[swift-ci]

Comment by Dale Buckley (JIRA)

@gwynne thats a great log, I'll be digging in how you managed to get something so detailed so I can use that method in future, thanks!

[gwynne]

It wasn't that magical ^^; No one in their right mind would actually try building an entire RelWithDebInfo Swift in a low-powered Docker container! (Fortunately, I'm not in my right mind 😉 ) The actual detailed info is nothing but "run the app in the debugger and print out some basic state data", all of which is easy enough to get at - OS version (uname, backtrace (thread backtrace), registers (register read, image list (cat /proc/pid/maps). It's a minimal version of the info you'd find in a crash report on macOS, except with a slightly more useful backtrace because it's pre-symbolicated (and even then, since it's optimized code, it's of only so much use).

[gwynne]

(Wow. TIL that Jira can't handle emoji in its comment form. C'mon Atlassian!)

[swift-ci]

Comment by Dale Buckley (JIRA)

To be perfectly honest it didn't even occur to me to to build swift in release mode with debug configuration and then try to run vapor on that. I've only ever built swift once from scratch so it's not something I think about doing much. But lets face it, it's not ever day (in normal use cases for swift usage) you encounter a runtime bug that only happens on one platform and not the other, normally it's excellent people like yourself who have forged and smoothed out that path before I even get there.

Learn something new every day 🙂

[gwynne]

Honestly I probably should have just built Swift in debug mode outright rather than mucking with release-debuginfo (which is actually much slower to build), so it's questionable whether I did anything too brilliant 🙂

[belkadan]

@swift-ci create

[eeckstein]

Is this still relevant?