3 ms·

I strongly encourage developments like that. It’s a shame that Linux and macOS didn’t adopt something like Microsoft’s symbol server. This project could become

I strongly encourage developments like that. It’s a shame that Linux and macOS didn’t adopt something like Microsoft’s symbol server. This project could become something like this. If you have an installation like this you can also plug it into Sentry as symbol server and it picks it up.

blinkingled 6y ago
Yep, in case of Linux the 'it's OSS. Download the tar.gz configure --enable-debug and deal with it' attitude hampered the development and use of something like a Symbol Server. Microsoft has had it since at least 2005 - that's the first Visual Studio release I remember using it with - so it might have exited before that. It's things like these that separate MS from all others - Engineering culture of having to give 2 shits about other people - OEMs, developers, corporate IT, partners and having the chops to effectively address it at scale within their Engineering teams.
- de_watcher 6y ago
  What are you talking about? Linux distros come with debug info packages.
  - blinkingled 6y ago
    Yeah I know - that's a more recent thing however and the attitude in the early days was what I was referring to. Oh and the debuginfo packages used to be and still are huge in size. Not sure if anything has changed most recently but the concept of lazy loading symbols from remote and storing only what you need locally is not something you can do with debuginfo packages.
    - de_watcher 6y ago
      Oh yes, the size is killing it. Our applications are not that big so the bandwidth use isn't completely insane, but I see the problem.
saagarjha 6y ago
Apple runs something similar internally, as it can correlate debug symbols to binaries by checking the UUID the linker sticks in it. Unfortunately, it’s not generally available…
- pjscott 6y ago
  There used to be a hack where you could write your own UUID-to-dSYM script, name it "dsymForUUID", and then lldb would assume it was Apple's internal magic thing and use it. Fortunately lldb seems to have improved since those days, and has less magical options available: http://lldb.llvm.org/use/symbols.html http://lldb.llvm.org/use/symbols.html
bmn__ 6y ago
"Good enough" solutions were already in place for many years, that's why a symbol server was not a matter of urgency. Did you know about the following? • A package manager can be configured to install the corresponding debuginfo/debugsource packages, this is literally one menu toggle. It's off by default to save disk space, as most users don't need them. • A desktop environment crash handler (e.g. drkonqi) offers to install the missing debuginfo/debugsource packages and then produces a complete stacktrace. • gdb shows the command for installing the missing debuginfo/debugsource packages it needs.
- schultetwin1 6y ago
  I'm not aware of those solutions. Very cool! Are they specific to one distro (for example, Fedora)? How do I get gdb to show me the command to installing missing packages? One downside to those solutions, they only support debugging on the same machine running the executable. If I want to debug a crash dump from a machine different from my own I might not be able to install the packages.
  - bmn__ 6y ago
    > Are they specific to one distro no > How do I get gdb to show me the command With the "run" command. You get a message "Missing separate debuginfos, use:" and then debuginfo-install, zypper etc. depending on the distro.
- usr1106 6y ago
  In Opensuse (release, haven't used Tumbleweed) I found it easy to install debuginfo and debugsource packages. In Ubuntu I found it slightly confusing to locate debug symbol packages. I understood (or misunderstood) that there are 2 options where to find debug symbols and it just depends on the package maintainer how it's done. I did not find how to install debugsource at all. By doing debugsource I mean the source that has all the patches applied exactly as during the build and is in the same path as the symbols suggest.
- the_mitsuhiko 6y ago
  None of what we have is good enough unfortunately. If you have a random crash from a customer you’re out of luck.

blinkingled 6y ago

Yep, in case of Linux the 'it's OSS. Download the tar.gz configure --enable-debug and deal with it' attitude hampered the development and use of something like a Symbol Server. Microsoft has had it since at least 2005 - that's the first Visual Studio release I remember using it with - so it might have exited before that. It's things like these that separate MS from all others - Engineering culture of having to give 2 shits about other people - OEMs, developers, corporate IT, partners and having the chops to effectively address it at scale within their Engineering teams.

de_watcher 6y ago
What are you talking about? Linux distros come with debug info packages.
- blinkingled 6y ago
  Yeah I know - that's a more recent thing however and the attitude in the early days was what I was referring to. Oh and the debuginfo packages used to be and still are huge in size. Not sure if anything has changed most recently but the concept of lazy loading symbols from remote and storing only what you need locally is not something you can do with debuginfo packages.
  - de_watcher 6y ago
    Oh yes, the size is killing it. Our applications are not that big so the bandwidth use isn't completely insane, but I see the problem.

saagarjha 6y ago

Apple runs something similar internally, as it can correlate debug symbols to binaries by checking the UUID the linker sticks in it. Unfortunately, it’s not generally available…

pjscott 6y ago
There used to be a hack where you could write your own UUID-to-dSYM script, name it "dsymForUUID", and then lldb would assume it was Apple's internal magic thing and use it. Fortunately lldb seems to have improved since those days, and has less magical options available: http://lldb.llvm.org/use/symbols.html http://lldb.llvm.org/use/symbols.html

bmn__ 6y ago

"Good enough" solutions were already in place for many years, that's why a symbol server was not a matter of urgency. Did you know about the following? • A package manager can be configured to install the corresponding debuginfo/debugsource packages, this is literally one menu toggle. It's off by default to save disk space, as most users don't need them. • A desktop environment crash handler (e.g. drkonqi) offers to install the missing debuginfo/debugsource packages and then produces a complete stacktrace. • gdb shows the command for installing the missing debuginfo/debugsource packages it needs.

schultetwin1 6y ago
I'm not aware of those solutions. Very cool! Are they specific to one distro (for example, Fedora)? How do I get gdb to show me the command to installing missing packages? One downside to those solutions, they only support debugging on the same machine running the executable. If I want to debug a crash dump from a machine different from my own I might not be able to install the packages.
- bmn__ 6y ago
  > Are they specific to one distro no > How do I get gdb to show me the command With the "run" command. You get a message "Missing separate debuginfos, use:" and then debuginfo-install, zypper etc. depending on the distro.
usr1106 6y ago
In Opensuse (release, haven't used Tumbleweed) I found it easy to install debuginfo and debugsource packages. In Ubuntu I found it slightly confusing to locate debug symbol packages. I understood (or misunderstood) that there are 2 options where to find debug symbols and it just depends on the package maintainer how it's done. I did not find how to install debugsource at all. By doing debugsource I mean the source that has all the patches applied exactly as during the build and is in the same path as the symbols suggest.
the_mitsuhiko 6y ago
None of what we have is good enough unfortunately. If you have a random crash from a customer you’re out of luck.