backtrace

I feel stupid but I need to get a backtrace for a bug report to KDE.
Thing is I don't know how?
I read the arch wiki on debugging but it makes no sense to me.

I just need to generate a backtrace for the system settings crash when I select GTK Application Styles.

How do I backtrace something that includes debug symbols? :space_invader:

Can someone explain it like I'm 5? Please?

Thank you.

I'm not sure whether this is what you want, but you could run it through strace, like so...

strace systemsettings5
1 Like

I'll give it a try. I'm not sure what the guy at KDE wants. Something with Symbols. Apparently my mile long crash report from their very own Ksystemlog doesn't provide the right info or something. meh.

HAHAHAHA! It just generated a 91meg text file for the trace. :sob:

1 Like
Name
strace - trace system calls and signals

Synopsis
strace [ -dDffhiqrtttTvVxx ] [ -acolumn ] [ -eexpr ] ... [ -ofile ] [ -ppid ] ... [ -sstrsize ] [ -uusername ] [ -Evar=val ] ... [ -Evar ] ... [ command [ arg ... ] ]

strace -c [ -D ] [ -eexpr ] ... [ -Ooverhead ] [ -Ssortby ] [ command [ arg ... ] ]

Description
In the simplest case strace runs the specified command until it exits. It intercepts and records the system calls which are called by a process and the signals which are received by a process. The name of each system call, its arguments and its return value are printed on standard error or to the file specified with the -o option.

strace is a useful diagnostic, instructional, and debugging tool. System administrators, diagnosticians and trouble-shooters will find it invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. Students, hackers and the overly-curious will find that a great deal can be learned about a system and its system calls by tracing even ordinary programs. And programmers will find that since system calls and signals are events that happen at the user/kernel interface, a close examination of this boundary is very useful for bug isolation, sanity checking and attempting to capture race conditions.

More information here, or locally...

man strace
1 Like

You can't.

If you a little bit older you might can do it. You must be able to read. :wink:
The main problem is that there are no debugging symbols for applications and libraries in the repository. To get these you have to recompile it. Depending on the application you might only recompile it or you need to do it also for some libraries.

If you want to use a PKGBUILD file, you need to enable the debug option and disable strip( !strip ) for makepkg. You usually also need to add some extra build options to enable debugging for this application. There is no standard so you need to read the documentation for that application.

The Wiki page give you a brad overview what you need to do.
https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

This is not a really easy task.

3 Likes

Thanks @xabbu for the reply. I promise I can read, it's the comprehension part that sometimes eludes me. :wink:

So this guy wants debug symbols but there's really no way for me to get them?
How are non-programmers supposed to file bug reports when this weiner wants that? /sigh

Btw, here's my bug report.
https://bugs.kde.org/show_bug.cgi?id=410789
Maybe I should just upload the 91meg text file for this guy. :tongue:

Also, I just realized I have that arch wiki page open already trying to figure this out before I posted.
I really don't want to compile/build/fondle systemsettings5 again just so this guy will have his symbols . I don't care enough about this bug to do that.

1 Like

He's a developer. He should have a virtual machine handy for testing this sort of thing. He shouldn't be laying the burden on the shoulders of the users.

1 Like

Well, you can but you need to recompile it. Unfortunately your bug is not in a simple separate application. You will at least recompile systemsettings and maybe more. I'm not a KDE user so I don't know.
Keep in mind that a simple recompile is not enough. You need to use the right options for makepkg and the application. The last part is usually done in the build () part of the PKGBUILD file.

This is a real problem in the Arch/Manjaro world. And a reason bug reports are just ignored by developers. I personally think that the Debian world makes is way easier for a user to provide debug information to developers.

3 Likes

Thank you both for your replies. I appreciate it.
On the upside, I learned a bit about chasing down a crash and debugging! :+1:

I'm going to go ahead and get Nate this 91meg file and see how that goes.
But if he still needs symbols I'll just let him close the bug report and move on with my life.

I have no experience with reporting bugs in the debian system. That much better?

It's been rather frustrating submitting bugs. As you said, a lot of Devs just ignore them.
OpenRazer did that to me as well as another I won't mention (They frequent the forums).

Again, thank you gentle beings for your expertise and patience.

:purple_heart:

1 Like

I'm such a brat. I named it kdebug8245127437572. :woman_shrugging:
Had to upload it to google drive. I guess you can't upload a 91M file to KDE bug site. Mwahahahaha.

1 Like

https://bugs.kde.org/show_bug.cgi?id=410789#c5

I'm not sure if this is the right question to ask but why aren't these tools available for Arch-based systems if they aid in bug reporting?
Basically, it's totally worthless to report bugs to KDE at the least if you're on Arch-based systems.
To say I don't understand is an understatement but is this a technical thing?

For years we are asking for debug symbols and arch devs saying they are coming and nothing has happened.

The thing is, such debug symbols could change the whole distribution and it's not easy to implement them. Arch is a fast, lightweight distributions. It's famous from it. If you compile a package with debug symbols, the package gains weight, uses more memory and in result the system build from such packages is slower. This is probably one of the secrets why Arch is the way it is - because it lacks debug symbols. With the symbols, Arch would be no faster then Ubuntu. It would be still more flexible but again, not faster.

Another issue with adding debug symbols is: it takes more time to compile and packages take more space (so more space is needed) and since Arch is not backed by any company and run by volunteers, they are not rushing to implement them.

There is an idea to have split packages, a main package and it's debug symbol part if I understand it correctly. This sounds like an interesting solution, because you could simply install this debug additional package for specific package and you could have fully working package with debug symbols without forcing it everywhere but again, it would mean to double the arch packages count, more compilation, more resources used to maintain those packages.

At least those are the arguments that were conveyed to me when I pursued this topic, also frustrated, why can't I help more by having debug symbols and why aren't they included in arch base.

Still, we can produce helpful bug reports and many Arch users do, but we can't back it up by detailed info with debugging symbols. We just add as much info as we can:

  • what is the terminal output,
  • what is the behavior,
  • what you did previous to that bug
  • make experiments and report results: check configs (use clean test user), roll back to previous version and then report results, change something to see if this helped, etc.

You just need to be creative. However, some issues will stay hard to debug, especially those pesky, vague segmentation faults (crashes). But even then I saw how developers were managing quite well with such reports without having those debug symbols info.

Ah, if the issue is general and happening on different distros, you can use other distro to create meaningful debug trace. Open Suse Thumbleweed should have them (if I'm not mistaken) and with the same package versions it should present similar environment as on Arch.

3 Likes

Wow, thank you for that explanation @michaldybczak.
It makes a lot of sense. I just didn't understand because I'm not a programmer, I suppose.
I'm a little smarter now.

It is very frustrating. Nate was very pleasant but it was obvious that without those symbols he'd rather do something else with his time. It's an annoying issue and one that I would imagine is hard to reproduce. So I do understand wanting that debug information.

arch-based distros and to me Manjaro in-particular are very special. It has taken some very smart people to make Arch and it's children distros the excellent OSes that they are.
I would think that those same smart, innovative people could come up with a solution for this that can keep the speed and flexibility arch is known for and still offer much needed debugging tools.

In his reply to me, Nate mentioned he's lobbied hard to get the bug reporting mechanism in Plasma turned off for all Arch systems.
To me that says there's a problem. It's not for me to point fingers but it seems like a real problem. I feel fairly worthless reporting bugs to KDE now.

Well, anyhow. Me whining about it isn't going to change it. I also don't have the know-how to offer a solution so I'll just shut my pie-hole and move along. :wink:

Thanks again for the great explanation.

:purple_heart:

2 Likes

Just choose your battles wisely. There are many bugs that we can report successfully. I also submitted some bugs but omitted those very technical ones or had to give as many information as I could, the rest must be done by developers to reproduce it and get more info meaningful to them.

So basically Plasma debugging mechanisms are useless in Arch, but we still can produce meaningful reports. We just have to work more and go into debugging mindset to be a partner to the developer. Arch users are often the biggest group reporting bugs so lack of debug symbols never stopped them.

This also another reason why Arch or Arch base is for more experienced users. We just can't mindlessly use automation tools and have to think to gather useful info ourselves.

2 Likes

This is 100% correct. It's the absence of the debugging symbols that makes Arch โ”€ and by consequence also Manjaro โ”€ so much faster. The overhead of all the debugging symbols in the code has a significant impact on the performance and the memory footprint.

Gentoo does a similar thing but streamlines the performance even more by cutting away interoperability with things you don't intend to install anyway. For instance, if you're not going to be using GNOME, then you can cut out the GNOME support from any GTK-based applications by way of build-time variables called "USE flags".


@Sinister, I've just updated my system โ”€ the mirrors were slow to sync over here, so I had to wait until this morning before updating โ”€ and I have tried what you say crashes the System Settings, but it doesn't crash here. I suspect that the crashes you're seeing may be the result of a certain theme or third-party Plasma widget you are using. :thinking:

There are many small things that make all of our installations unique. For instance, my system here is quite stable, but I cannot use the Pan Usenet client because it segfaults when downloading new articles, and I also cannot use the appmenu-gtk-module in order to export GTK application menus to Plasma's Global Menu widget, because then Chromium, Firefox and Plasmafox all segfault upon starting. And even with that module installed, GIMP still does not export its menu.

Other people are not reporting this behavior, and they are able to run Pan without any problems. So there must be something unique about my installation here โ”€ including the theming, et al โ”€ which causes those incompatibilities. It is therefore quite possible that you are seeing something similar on your machine. :thinking:

It really boggles my mind, I have to admit. I was really frustrated yesterday over this.
You and @michaldybczak explained it really well and I feel like I have a better understanding.
I think I'd rather have the a system without it and tough out the debugging if the cost is a sluggish pile of crap. I had Ubuntu Mate in VM and it took m i n u t e s to boot with the exact same settings my other VMs have. They all boot within seconds, perhaps closing on a minute at most.
I'd rather have Manjaro, thanks. :wink:

RE: unique systems.
I absolutely understand that. :slight_smile: It's one of the strengths and curses of Linux isn't it?
Total customization will inevitably have it's consequences.
Before I posted about this I went through pretty much everything I had. Other than what's on the taskbar I don't have plasmoids on my desktop.
The only thing I could track it to maybe was it started around the time I installed aritim-dark theme. I uninstalled it but the behaviour persists.
If it is/was the cause it may have tainted some config somewhere and I swear to all mighty Tiamat, it seems like KDE has configs just plastered everywhere.

I didn't really like that theme once I got a look at it anyhow so when I reinstall for the new system I think I'll avoid that. Also pay closer attention to theme installation. One at a time. Test, test, test.

Thanks for your reply @Aragorn. You're the best Dรบnedain ever. :wink:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by Bytemark