Cyberbeni
December 14, 2024, 12:13am
1
The one I reported to the main repo still has the "triage needed" label after 3 weeks, which makes me believe that it's not in the correct place.
opened 12:15PM - 26 Nov 24 UTC
bug
crash
triage needed
### Description
I have 2 machines. An Intel J4105 based one running Ubuntu 20… .04 which doesn't have this issue and a Ryzen 1700x based one running Nobara 40, which does have this issue.
The crash happens using the binary from the artifactbundle found here: https://github.com/nicklockwood/SwiftFormat/releases/tag/0.55.2
Workspace I'm using for testing: https://github.com/Cyberbeni/Wiring/commit/4f7922785ae0f221bf4373d038a86ca30bf4273e
When I run swiftformat, I get a segmentation fault:
```console
> ~/Downloads/swiftformat_linux .
Running SwiftFormat...
Reading config file at /home/cyberbeni/Developer/Wiring/.swiftformat
[1] 6165 segmentation fault (core dumped) ~/Downloads/swiftformat_linux .
```
But when I run this program in verbose mode, I don't get a crash:
```console
> ~/Downloads/swiftformat_linux --verbose .
Running SwiftFormat...
Reading config file at /home/cyberbeni/Developer/Wiring/.swiftformat
...
SwiftFormat completed in 0.16s.
0/31 files formatted.
```
Same behaviour when running the same binary with podman: `ghcr.io/nicklockwood/swiftformat:0.55.2`
I also don't get a crash when running the code in the linked workspace inside a podman container.
Also no crash when using the container of version 0.54.5, which was built without the static SDK on swift:focal and copied over to swift:focal-slim
Also no crash when building locally without the static SDK with the following command: `swift build --product swiftformat --configuration release -Xlinker -s`
cc https://github.com/nicklockwood/SwiftFormat/issues/1930
### Reproduction
See description.
### Stack dump
```console
> coredumpctl info
PID: 4738 (swiftformat_lin)
UID: 1000 (cyberbeni)
GID: 1001 (cyberbeni)
Signal: 11 (SEGV)
Timestamp: Tue 2024-11-26 14:58:19 CET (9min ago)
Command Line: /home/cyberbeni/Downloads/swiftformat_linux .
Executable: /home/cyberbeni/Downloads/swiftformat_linux
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole@27e0da96d4f6401bba8ab0766af41051.service
Unit: user@1000.service
User Unit: app-org.kde.konsole@27e0da96d4f6401bba8ab0766af41051.service
Slice: user-1000.slice
Owner UID: 1000 (cyberbeni)
Boot ID: ca63284dfda64320ae40facc142760fe
Machine ID: 02f7a45841774093b59a960034641923
Hostname: nobara-pc
Storage: /var/lib/systemd/coredump/core.swiftformat_lin.1000.ca63284dfda64320ae40facc142760fe.4738.1732629499000000.zst (present)
Size on Disk: 12.9M
Message: Process 4738 (swiftformat_lin) of user 1000 dumped core.
Module /home/cyberbeni/Downloads/swiftformat_linux without build-id.
Stack trace of thread 4743:
#0 0x00000000017cd57c n/a (/home/cyberbeni/Downloads/swiftformat_linux + 0x15cd57c)
ELF object binary architecture: AMD x86-64
```
From `/var/lib/systemd/coredump`:
[coredump.zip](https://github.com/user-attachments/files/17920633/coredump.zip)
### Expected behavior
Swift files are formatted inside the folder that is passed in as an argument.
### Environment
```Dockerfile
FROM --platform=$BUILDPLATFORM swift:6.0.1 AS builder
WORKDIR /workspace
RUN swift sdk install \
https://download.swift.org/swift-6.0.1-release/static-sdk/swift-6.0.1-RELEASE/swift-6.0.1-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz \
--checksum d4f46ba40e11e697387468e18987ee622908bc350310d8af54eb5e17c2ff5481
```
Also tried with 6.0.2:
```Dockerfile
FROM --platform=$BUILDPLATFORM swift:6.0.2 AS build
WORKDIR /workspace
RUN swift sdk install \
https://download.swift.org/swift-6.0.2-release/static-sdk/swift-6.0.2-RELEASE/swift-6.0.2-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz \
--checksum aa5515476a403797223fc2aad4ca0c3bf83995d5427fb297cab1d93c68cee075
```
### Additional information
_No response_
It would be good to know about this. I ran into an issue cross compiling with the static SDK from macOS and I have no clue where to file an issue for it.
Ping @al45tair , the author of this SDK, will it be supported by you, @etcwilde , or someone else going forward, or should it be considered community-supported from now on?
1 Like
al45tair
December 15, 2024, 2:52pm
4
Reporting here and on Github is the right place, and please do ping me if you spot one of these that I haven't noticed yet, but we're in holiday season so support from us will be slower than usual. Looking at the Github Issue, it looks like the most likely explanation is some Musl-vs-Glibc thing involving swift-format that is then causing the program to do something bad with a Set (resulting in the usual fatal error).
In these cases it'll be really helpful to (a) not strip the program and (b) install the backtracer on the system where the crash is happening, so that we get a proper backtrace and indeed a message explaining why we failed.
2 Likes