Segmentation Fault when using Bundle on non-apple-plattform


I've been using Swift on unix / non-apple-plattforms. The following code produces a Segmentation Fault for me. Right now I'm pretty sure it is a bug. I just wanted to ask, if I probably did something wrong or so.

private static func bundle(for language: SupportedLanguage) -> Bundle {
    let i18nRootDirBundle = Bundle(path: DirectoryConfig.detect().workDir + "Resources/LocalizableStrings/")!
    let localizedStringsFileBundlePath = i18nRootDirBundle.path(forResource: language.shortName, ofType: "lproj")

    return Bundle(path: localizedStringsFileBundlePath!)!

private static func localizedStringWithoutFallback(for language: SupportedLanguage, with key: String) -> String {
    // return bundle(for: language).localizedString(forKey: key, value: nil, table: nil)) / /<- Segmentation Fault
    print(bundle(for: language))  // everything OK
    return key // everything OK

This code reproduces the error for me every time. If I change the last row to the part from the comments it will produces a segmentation fault. The code itself works. It will even print the correct keys a few times. But after some accesses to the bundle it will crash.

If I won't call localizedString the error won't occur. Initialising the bundle works (and everything expected is non-nil).

I had a reference before to avoid re-initialise the bundle all the time. But the result remains the same in both cases.

SupportedLanguage is a enum. The values for .shortName will be "en" and "de".

I've been using Vapor with Docker. I posted my docker file below.

# You can set the Swift version to what you need for your app. Versions can be found here:
FROM swift:5.0 as builder

# For local build, add `--build-arg env=docker`
# In your application, you can use `Environment.custom(name: "docker")` to check if you're in this env
ARG env=prod

RUN apt-get -qq update && apt-get install -y \
  libssl-dev zlib1g-dev \
  && rm -r /var/lib/apt/lists/*
COPY . .
RUN mkdir -p /build/lib && cp -R /usr/lib/swift/linux/*.so* /build/lib
RUN swift build -c debug && mv `swift build -c debug --show-bin-path` /build/bin

# Production image
FROM ubuntu:18.04
ARG env=prod
# DEBIAN_FRONTEND=noninteractive for automatic UTC configuration in tzdata
RUN apt-get -qq update && DEBIAN_FRONTEND=noninteractive apt-get install -y \
  libatomic1 libicu60 libxml2 libcurl4 libz-dev libbsd0 tzdata \
  && rm -r /var/lib/apt/lists/*

COPY --from=builder /build/bin/Run .
COPY --from=builder /build/lib/* /usr/lib/
COPY --from=builder /app/Public ./Public
COPY --from=builder /app/Resources ./Resources

ENTRYPOINT ./Run serve --env $ENVIRONMENT --hostname

Is there anything I can do to provide more information or to get better debug information?


Can you write a short sample that breaks the same way?

Any crash is a bug, and localized strings are supposed to work.

1 Like

I've done some more debugging and found out that this is related to any access to an .stringsdict-file. The bug was already reported.

For reference:
(I also provided another example project that will cause the bug to occur)

Thank you for doing this legwork.

We absolutely need to fix the crash and make the messaging better, but stringsdicts are not supported in swift-corelibs-foundation.

Are there any plans to support them? Is there anywhere a documentation about that? I haven‘t been able to find anything within the repository.

Thanks for your reply, I added some hotfix for that in my project that does not rely on stingdicts.

Apple does not comment on future plans, generally. This is not documented, which is an area for which I’m very happy to receive feedback.

Let me rephrase the question this way:

If someone were to provide a pull request (I’m not volunteering.) that implemented it for corelibs-foundation, would that likely:

  • be accepted as a step toward platform parity, since it exists de facto on Darwin, or
  • be rejected as a step away from platform parity, since it does not exist de jure on Darwin?
1 Like

As an aside, while we know this is how Apple operates internally, that it applies to ostensibly open source projects is extremely worrying. Whether or not Apple engineers will be doing the work, the question of whether stringsdict support is part of the plan or even desired for swift-corelibs-foundation should not be a secret. Otherwise, how else are external contributors supposed to plan their work, as @SDGGiesbrecht asks? Not to mention, how are companies adopting Swift supposed to evaluate their support requirements without such a roadmap (e.g. need to build stringsdict support on Linux themselves)?


I don’t think there’s any obstacle to a PR implementing it, so long that the implementation is close enough to take the same files as inputs.


Thank you. As I hoped, that ought to give everyone outside the black box the information they need without compromising the black box. :+1:

Terms of Service

Privacy Policy

Cookie Policy