It intentionally acts as an intercept for such things, so that core dumps can be nicely packaged up and sent to maintainers in a GUI-friendly way so maintainers can get valuable debugging information even from non-tech-savvy users. If you’re running something on the terminal, it won’t be intercepted and the core dump will be put in the working directory of the binary, but if you executed it through the GUI it will.
Assuming, of course, you turn crash interception on- it’s off by default since it might contain sensitive info. Apport itself is always on and running to handle Ubuntu errors, but the crash interception needs enabled.
I love gdb! I recently had to do a debug and wow its so cool! On gentoo I can compile everything with symbols and source and can do a complete stack trace.
Am I the only one in this thread who uses VSCode + GDB together? The inspection panes and ability to breakpoint and hover over variables to drill down in them is just great, seems like everyone should set up their own c_cpp_properties.json && tasks.json files and give it a try.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
Where does it write the file
Nobody knows
Probably the same place as failed sudo reports
On a secret FBI server somewhere where they watch your failures and laugh
When you apply for a home loan or a passport:
“Unfortunately we will have to reject your application”
“Why?”
“We have received several reports of failed sudo attempts and segmentation faults”
If you are using systemd, there’s a tool called coredumpctl.
you can set it
tl;dw: writes to the path in
/proc/sys/kernel/core_patternI believe it’s
/var/lib/apport/coredumpon Ubuntu.imagine if it, like, told you this so you didn’t have to find out about it via a post on lemmy
Imagine if you knew the most basic foundational features of the language you were using.
Next we’ll teach you about this neat thing called the compiler.
I’m not a C/C++ dev, but isn’t
apportUbuntu’s crash reporter? Why would dumps be going into there?Though on a rhetorical thought, I am aware of systemd’s
coredumptctlso perhaps its collecting dumps the same way systemd does.https://wiki.ubuntu.com/Apport
It intentionally acts as an intercept for such things, so that core dumps can be nicely packaged up and sent to maintainers in a GUI-friendly way so maintainers can get valuable debugging information even from non-tech-savvy users. If you’re running something on the terminal, it won’t be intercepted and the core dump will be put in the working directory of the binary, but if you executed it through the GUI it will.
Assuming, of course, you turn crash interception on- it’s off by default since it might contain sensitive info. Apport itself is always on and running to handle Ubuntu errors, but the crash interception needs enabled.
Ah I see, that’s actually pretty cool - thanks!
np
i mean you’re expected to know the basic functioning of the compiler when you use it
imagine if it like, read that file and gave you a stack trace
gdb gives you waaaaaaaaaaaaaaay more than a stack trace.
…unless you build the executable with optimizations that remove the stack frame. Good luck debugging that sucker!
I love gdb! I recently had to do a debug and wow its so cool! On gentoo I can compile everything with symbols and source and can do a complete stack trace.
Am I the only one in this thread who uses VSCode + GDB together? The inspection panes and ability to breakpoint and hover over variables to drill down in them is just great, seems like everyone should set up their own c_cpp_properties.json && tasks.json files and give it a try.