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

*.dSYM files are missing on apple in installations / releases #47744

Closed
vtjnash opened this issue Nov 30, 2022 · 6 comments · Fixed by #48355
Closed

*.dSYM files are missing on apple in installations / releases #47744

vtjnash opened this issue Nov 30, 2022 · 6 comments · Fixed by #48355
Labels
release Release management and versioning. system:mac Affects only macOS

Comments

@vtjnash
Copy link
Member

vtjnash commented Nov 30, 2022

We ship (the equivalent of) .dSYM files on all other platforms, so it is weird for these to be missing from just Apple platforms, and can significantly hurt the debugging experience there when using releases (it is the moral equivalent to passing objcopy --strip-debug during make install on all other platforms)

@vtjnash vtjnash added system:mac Affects only macOS release Release management and versioning. labels Nov 30, 2022
@vtjnash vtjnash added this to the 1.9 milestone Nov 30, 2022
@KristofferC
Copy link
Member

can significantly hurt the debugging experience there when using releases

Out of curiosity, is there a concrete example where you can see the difference in error info between the platforms? I'm just thinking since no one seems to have complained.

@fingolfin
Copy link
Member

Shipping *.dSYM files in releases seems unusual. Not aware of anything else doing that? (That said, "nobody else doing that" isn't a particular good argument; just wondering)

@gbaraldi
Copy link
Member

IIRC, we do generate the files, we are probably just not copying them to the release.

@vtjnash
Copy link
Member Author

vtjnash commented Nov 30, 2022

Most platforms ship them in some form. Often as optional packages with the suffix -dbg on the installed name, split out from the build when packaging it (with objcopy --strip-debug–we even do that automatically in our build tests with JULIA_SPLITDEBUG to run some specific tests of the functionality). We also ship them on all other platforms, so it is weird for us to not ship this info specifically just on Apple.

@KristofferC Users probably just don't know what is broken relative to what it could do. You have to take a little extra effort to look at C=true info in stacktraces, profiling, or lldb. It took me a bit to realize what Elliot meant when he was screensharing with me debugging something in an installation and asked me why the backtraces were wonky. And I realized I had mentally filtered out the bad stuff because it was not currently relevant, and I knew my local build didn't have that issue.

@ViralBShah
Copy link
Member

If it improves the user experience, I suppose we should copy them. What's the size impact?

@KristofferC
Copy link
Member

KristofferC commented Dec 14, 2022

Is this really a regression vs 1.8? I don't think this is important enough to warrant a milestone.

@KristofferC KristofferC removed this from the 1.9 milestone Dec 14, 2022
vtjnash added a commit that referenced this issue Jan 19, 2023
vtjnash added a commit that referenced this issue Jan 19, 2023
vtjnash added a commit that referenced this issue Jan 19, 2023
vtjnash added a commit that referenced this issue Jan 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Release management and versioning. system:mac Affects only macOS
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants