Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
swift-ci opened this issue Oct 12, 2018 · 8 comments
Closed

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

swift-ci opened this issue Oct 12, 2018 · 8 comments

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Oct 12, 2018

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
Copy link
Contributor

@gwynne gwynne commented Oct 15, 2018

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
Copy link
Collaborator Author

@swift-ci swift-ci commented Oct 15, 2018

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
Copy link
Contributor

@gwynne gwynne commented Oct 15, 2018

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
Copy link
Contributor

@gwynne gwynne commented Oct 15, 2018

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

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Oct 15, 2018

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
Copy link
Contributor

@gwynne gwynne commented Oct 15, 2018

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
Copy link
Contributor

@belkadan belkadan commented Oct 26, 2018

@swift-ci create

@eeckstein
Copy link
Member

@eeckstein eeckstein commented Feb 15, 2019

Is this still relevant?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants