Created attachment 2091 [details] Window describing Claws-related kernel crash. Have experienced what appear to be kernel crashes related to Claws Mail, based on the limited information it is reporting. I am unable to copy and paste the text from the window showing this information, so I am attaching a screenshot of the window. It is referencing a general protection fault in one of the libraries. Fedora's bug reporting system has been offline due to a server move, but this particular crash cannot be reported to them, per the information.
Also per the information it says report to the kernel maintainers. Did you get their input?
Anyway, best explain what you were doing leading up to this crash, so we can attempt to reproduce it. And can you reproduce it?
I have absolutely no idea what is causing them, there are multiple instances of this. When booting up the computer, I will occasionally see a popup indicating a crash/problem occurred once the desktop appears. When I click the popup's Report icon, the bug reporter software loads and displayed that information in the screenshot. As to notifying the kernel maintainers, I would not know who to contact. I sent the same screenshot to a friend who writes Linux software and based on that information, he said that it is occurring in a library libgobject 2.0, but the culprit looks like a null pointer exception in Claws. The only system changes I made, which I doubt would cause this, is that I changed the default web browser to Chromium and the default e-mail application to Claws. I also did a memory test and that passed.
i am using kernel 5.8.9 on fc32 and no crash (yet?)
Between yesterday and today, there have been a total of five such crashes queued in the reporting software, all showing the exact same library and also referencing Claws. Kernels were 5.8.8 and (updated this morning) 5.8.9.
Created attachment 2093 [details] g_type_check_instance crash Claws g_type_check_instance crash
Created attachment 2094 [details] nl_load_domain_cold crash Claws nl_load_domain_cold crash
There are also separate Claws Mail crashes, nl_load_domain_cold and g_type_check_instance. Screenshots from the reporting software are attached.
try to a (text) backtrace rather than those images. gdb file /usr/bin/claws-mail run --debug [CRASH HERE] bt full Attach the tailend of the debug output and the bt
I tested the memory earlier, entire test took over three hours, it found no errors. In launching Claws now, using the syntax in Comment 9, I have been unsuccessful getting it to crash. I am able to copy and paste the 'core backtrace' information from the crash reports. Would that help?
Got it. How to reproduce (at least on my system): 1. Use MATE desktop. 2. Launch Claws Mail. 3. Go to System/Control Center/Appearance (under 'Look and Feel'). 4. Change theme. 5. Click 'Close' icon. 6. Claws Mail crashes. Attaching 'bt full' and requested crash info from the gdb log.
Created attachment 2095 [details] bt full 'bt full' information from gdb log.
Created attachment 2096 [details] Crash information Crash information from gdb log.
How to you start Claws Mail? Is it automatically started by remembering your last session or because you tuned up your desktop to start it when desktop is opening?
I launch it from the desktop.
To clarify: I manually launch it from the desktop. Not automated in any way.
I see. That ruins my theory :-). Well, something I don't get yet, is: how is your scenario about changing the desktop theme related to the crashes your were initialy reporting here? That sounds something different to me (some buggy themes are known to crash Claws Mail, BTW).
I can tell you that from prior crashes (before I was able to successfully capture this data), crashes occurred while switching between both MATE and non-MATE themes.
Created attachment 2097 [details] backtrace generated from abrt-action-generate-backtrace backtrace generated after running abrt-action-generate-backtrace
Created attachment 2098 [details] original core_backtrace file from crash report/dump original core_backtrace file from crash report/dump information
Created attachment 2099 [details] GDB output of last ~20 seconds before Claws crash today 21 Sep 2020. Last ~20 seconds of GDB output up to the point where it ends at the Claws crash.
Created attachment 2100 [details] GDB 'bt full' backtrace from today's crash, 21 Sep 2020. GDB 'bt full' backtrace from today's crash, 21 Sep 2020.
Today's crash was reproduced in the same manner as described in Comment 11.
Just experienced another crash. Was using the LXQt desktop, changed thene, Claws crashed. This crash, like some others, included a second crash listed in ABRT relating to the kernel (now 5.8.10). Backtrace info from this latest kernel crash entry: traps: claws-mail[16555] general protection fault ip:7f2929373660 sp:7fff32f74a08 error:0 in libgobject-2.0.so.0.6400.5[7f292934c000+30000]
https://gitlab.gnome.org/GNOME/gtk/-/issues/2056 While searching to see what that libgobject_2.0 library does, the above came up in the search results. It's an issue filed by one of the other Claws developers a year ago. It's the same type of crash as what I've been experiencing while changing themes: in g_type_check_instance_is_a () at /lib64/libgobject-2.0.so.0
Created attachment 2102 [details] Entire gdb output - personal information removed Entire output from gdb
Comment on attachment 2102 [details] Entire gdb output - personal information removed Just for information - the file you uploaded it contains a tiny amount of info from gdb - just 4 lines at the top saying it is starting claws, and just 4 lines at the bottom saying it's got control again because claws crashed. ALL the rest of the output is from claws, and is the "debug trace" that claws produces when run with the "--debug" flag (in this case because gdb was told to start claws by "run --debug"). These lines show what claws was doing and why it was doing it... with as much or as little info as the claws programmers thought they'd need when trying to follow the workings of claws. Ideally it shows what claws was about to try to do just before the crash, but earlier on it will also show stuff from claws' setup which might help to explain what happened. gdb itself really only comes into play once claws has crashed, when gdb is then able to look at the contents of memory, create the stack trace etc, showing what the immediate aftermath of the crash looks like and hopefully just info, combined with the --debug info - for someone to work out why it happened.
Thank you for your comments Jeremy. He now has the entire output from the gdb command, as well as the full backtrace information, all generated from the instructions provided in an earlier comment. I hope there is something in either or both, that explains why Claws crashes in this manner.
https://bugzilla.redhat.com/show_bug.cgi?id=1882947
In reply to comment 17: > some buggy themes are known to crash Claws Mail, BTW The two recent detailed backtraces mention theme "Mint-Y-Red" and "Menta". https://bugzilla.redhat.com/1889848
(In reply to Michael Schwendt from comment #30) My preferred desktop environments are LXDE and LXQT, as both are lightweight and they just work. I am open to suggestions (here or on the mailing list) as to any themes that might work. FWIW, Cinnamon (including Mint-Y-Red) and the extra packages from KDE/Plasma have been removed from this system. MATE and XFCE are still installed. My preference is to exhaust all available options, before deciding to discontinue use of Claws Mail, this includes the X11-inspired crashes. Fedora 33 may resolve some issues, however, I am waiting for that to be officially released, before upgrading.
> I am open to suggestions (here or on the mailing list) as to any themes > that might work. greybird on kde here. works fine.
(In reply to Paul from comment #32) I do not have that particular theme installed on Plasma. The main issue I have with KDE/Plasma is the icon themes. Doesn't say which icon theme is for which desktop. In changing one, the Fedora icon on the taskbar, changed to the Gnome foot. And I discovered it also changed the icon themes for some of the other desktops installed. Regarding the X11 and GTK crashes, this system allocates only 256MB of the system RAM for video (original 4GB RAM was replaced with new 8GB RAM). Given how Linux has expanded over the years, is 256MB enough? Unfortunately, when HP designed this system, they only installed two PCI-E x1 (closed-end) slots. Although I found one x1-Radeon based card, it requires the PC to have at least a 400W power supply, the factory power supply is only 250W. I frown on using NVIDIA, because the other desktop used an on-board NVIDIA GPU (until I installed an x16-based Radeon card) and while it was using NVIDIA graphics, if I tried to run either Plasma or MATE, there would be a complete X crash, requiring a power down to get out of that. And unless GTK was disabled under NVIDIA, Firefox, Thunderbird and SeaMonkey all crashed (this goes back to Fedora 21). Strangely, LXDE and LXQT ran fine under the NVIDIA graphics and with 3GB of RAM, it also allocated 256MB for video memory.