sentry-native icon indicating copy to clipboard operation
sentry-native copied to clipboard

Stack trace only shows assembly in libc call but does not show sources in parent call tree

Open JasonDictos opened this issue 2 years ago • 6 comments

Description

The stack trace shows just the libc call, but does not show the source for the parent sources

When does the problem happen

  • [ ] During build
  • [ ] During run-time
  • [x] When capturing a hard crash

Environment

This is on our docker/ecr linux image in aws

  • OS: Ubuntu 12.01
  • Compiler: gcc11.01
  • CMake version and config: sentrybackend=crashpad cmake version 3.21.3 Steps To Reproduce

image

Note the above, I cannot see the line location in our 'Main' function, the emulates crash here was a call to 'strcpy(nullptr, "123")' [we are testing the output still]

JasonDictos avatar Nov 01 '21 22:11 JasonDictos

I would suspect that you have not uploaded the necessary debug files for it. We don’t have built-in symbol servers for linux at the moment, so you would have to upload these debug files for all the system libraries that you link to manually.

Swatinem avatar Nov 02 '21 12:11 Swatinem

Yeah they are uploaded, I have symbols for the binary: image

We run these commands post build to publish:

	sentry-cli releases new $ProjectVersion 
	sentry-cli releases files $ProjectVersion upload $InstalledRoot/$ProjectName/boxReceive sentry
	sentry-cli upload-dif --wait --include-sources $BuildRoot/receiving 
	sentry-cli releases set-commits --ignore-missing --auto $ProjectVersion 
<html>
<body>
<!--StartFragment-->

16:56:44 Receiving[Sentry-1/5]: Created release 1.0.0.1078.
--
222 | 16:56:46 Receiving[Sentry-1/5]: > Found 3 debug information files
223 | 16:56:48 Receiving[Sentry-1/5]: > Resolved source code for 2 debug information files
224 | 16:56:48 Receiving[Sentry-1/5]: > Prepared debug information files for upload
225 | 16:56:52 Receiving[Sentry-1/5]: > Uploaded 4 missing debug information files
226 | 16:56:53 Receiving[Sentry-1/5]: > File processing complete:
227 | 16:56:53 Receiving[Sentry-1/5]:
228 | 16:56:53 Receiving[Sentry-1/5]:        OK 52e4c4c6-02d0-b7a7-d599-0efed5dec119 (boxReceive; x86_64 library)
229 | 16:56:53 Receiving[Sentry-1/5]:        OK 52e4c4c6-02d0-b7a7-d599-0efed5dec119 (boxReceive.debug; x86_64 debug companion)
230 | 16:56:53 Receiving[Sentry-1/5]:        OK 52e4c4c6-02d0-b7a7-d599-0efed5dec119 (boxReceive.debug; x86_64 sources)
231 | 16:56:53 Receiving[Sentry-1/5]:        OK c6fa65f5-9cf5-a15d-09a4-d377dfa38ed7 (crashpad_handler; x86_64 sources)
232 | 16:56:54 Receiving[Sentry-1/5]: +------------------------+--------------+
233 | 16:56:54 Receiving[Sentry-1/5]: \| Repository             \| Revision     \|
234 | 16:56:54 Receiving[Sentry-1/5]: +------------------------+--------------+
235 | 16:56:54 Receiving[Sentry-1/5]: \| trice-imaging/edgeLink \| ********** \|
236 | 16:56:54 Receiving[Sentry-1/5]: +------------------------+--------------+

<!--EndFragment-->
</body>
</html>

JasonDictos avatar Nov 02 '21 16:11 JasonDictos

Well I see this error: image

JasonDictos avatar Nov 02 '21 17:11 JasonDictos

You were complaining about the libc symbols though?

Swatinem avatar Nov 03 '21 08:11 Swatinem

I've uploaded symbols for our app, it crashed in libc.

Not really interested in looking at the source code of libc, want to see the line/location where it called libc, prior to libc crashing.

Is that possible?

JasonDictos avatar Nov 03 '21 16:11 JasonDictos

Ah okay, that sounds more interesting. Though you should still upload at least the .so for your libc, so that unwind info is there and usable.

Swatinem avatar Nov 04 '21 09:11 Swatinem

Closing due to inactivity, feel free to open again if this issue still matters.

ashwoods avatar Nov 10 '23 12:11 ashwoods