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.

Sign up for GitHub

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

Jump to bottom

[SR-755] [Linux] Stack traces do not include debug symbols #43370

Open
drewcrawford opened this issue Feb 17, 2016 · 3 comments
Open

[SR-755] [Linux] Stack traces do not include debug symbols #43370

drewcrawford opened this issue Feb 17, 2016 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. Linux Platform: Linux

Comments

@drewcrawford
Copy link
Contributor

Previous ID SR-755
Radar rdar://problem/32295838
Original Reporter @drewcrawford
Type Bug
Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a

Additional Detail from JIRA
Votes 10
Component/s
Labels Bug, Linux
Assignee None
Priority Medium

md5: 08f080f5fb0fe8d5531da4d738eb7636

Issue Description:

A recent Swift snapshot added stack traces for e.g. fatalError. 👍 However, these stack traces do not support debug symbols 🙁 The behavior is verified correct on OSX, so this bug is Linux-specific.

$ cat test.swift
func doesNotAppearInStackTrace() {
    fatalError("Does this function appear in the stack trace?")
}
doesNotAppearInStackTrace()
swiftc -g test.swift && ./test
fatal error: Does this function appear in the stack trace?: file test.swift, line 2
Current stack trace:
/usr/local/lib/swift/linux/libswiftCore.so(swift_reportError+0x8b) [0x7f8ef4700e4b]
/usr/local/lib/swift/linux/libswiftCore.so(_swift_stdlib_reportFatalErrorInFile+0x71) [0x7f8ef47125e1]
/usr/local/lib/swift/linux/libswiftCore.so(+0x2861bc) [0x7f8ef465f1bc]
/usr/local/lib/swift/linux/libswiftCore.so(+0x2864fb) [0x7f8ef465f4fb]
/usr/local/lib/swift/linux/libswiftCore.so(function signature specialization <Arg[0] = Exploded, Arg[1] = Exploded, Arg[2] = Exploded> of Swift._assertionFailed (Swift.StaticString, Swift.String, Swift.StaticString, Swift.UInt, flags : Swift.UInt32) -> ()+0x75) [0x7f8ef465f645]
./test() [0x400b69]
./test() [0x400aa1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8ef382db45]
./test() [0x400989]
Illegal instruction

Expected: test symbols should appear in this stack trace

Actual: symbols are given for all modules except test.
@swift-ci
Copy link
Collaborator

Comment by Gregor Milos (Grzegorz Miłoś) (JIRA)

This is because swift uses local symbols in ELF executables extensively and `dladdr` cannot find them (that's the documented behaviour of `dladdr` on Linux). AFAIK there is no simple alternative to `dladdr` and implementing ELF parsing code in stdlib isn't a good idea.

Instead, I'm proposing writing a python script that is able to re-symbolicated stack trace afterwards. The input to it would be the executable + a log that contains a stack trace. It'll use lldb python bindings to construct debugging target identical in memory layout to what run at the time of the crash. Then it'll interrogate all the stack trace addresses for appropriate symbol information.

One complication is that due to Linux's ASLR, we need extra information about where the libraries were mapped at the time of the crash. This can be achieved by minor stdlib patch to print offset of framePC from the base of the shared lib that contains the address.

@swift-ci
Copy link
Collaborator

Comment by Gregor Milos (Grzegorz Miłoś) (JIRA)

PR: #4479

@mickeyl
Copy link

mickeyl commented Dec 8, 2021

This seems to be broken again. I'm running `swift-5.5.1-RELEASE` on an Ubuntu derivative w/ kernel 5.11 x86_64-unknown-linux-gnu. Here's an example stacktrace:

ELMpersonator/Adapter.swift:273: Fatal error: 'try!' expression unexpectedly raised an error: Swift_CAN.CAN.Error.writeError
Current stack trace:
0    libswiftCore.so                    0x00007fba705d3ae0 swift_reportError + 50
1    libswiftCore.so                    0x00007fba7064c270 _swift_stdlib_reportFatalErrorInFile + 109
2    libswiftCore.so                    0x00007fba703594d2 <unavailable> + 1414354
3    libswiftCore.so                    0x00007fba703591fb <unavailable> + 1413627
4    libswiftCore.so                    0x00007fba70357ee0 _assertionFailure(_:_:file:line:flags:) + 447
5    libswiftCore.so                    0x00007fba703a16a0 swift_unexpectedError + 770
6    ELMpersonator                      0x0000562e64840d01 <unavailable> + 4254977
7    ELMpersonator                      0x0000562e6483f646 <unavailable> + 4249158
8    ELMpersonator                      0x0000562e6483ea76 <unavailable> + 4246134
9    ELMpersonator                      0x0000562e64839385 <unavailable> + 4223877
10   ELMpersonator                      0x0000562e64853223 <unavailable> + 4330019
11   ELMpersonator                      0x0000562e64856a97 <unavailable> + 4344471
12   ELMpersonator                      0x0000562e644fce01 <unavailable> + 830977
13   ELMpersonator                      0x0000562e644fcf47 <unavailable> + 831303
14   ELMpersonator                      0x0000562e6484f2e2 <unavailable> + 4313826
15   libc.so.6                          0x00007fba6efecfc0 __libc_start_main + 243
16   ELMpersonator                      0x0000562e644b12ee <unavailable> + 520942
fish: 'sudo .build/debug/ELMpersonator…' terminated by signal SIGILL (Illegale Instruktion)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. Linux Platform: Linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mickeyl @drewcrawford @swift-ci