By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 2399

Summary:	Konqueror crash when clicking a .iso file
Product:	TDE	Reporter:	Kristopher <gamrat.kristopher>
Component:	tdebase	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED WORKSFORME
Severity:	minor	CC:	bugwatch, michele.calgaro
Priority:	P5
Version:	R14.0.x [Trinity]
Hardware:	Other
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:

Description Kristopher 2015-03-16 10:20:35 CDT

Out of curiosity, I decided to click a .iso file to see if Konqueror could open it. A progress dialog appeared entitled "Examining in progress...", followed by the TDE Crash Handler alerting that Konqueror crashed. All of the Konqueror windows I had open, including the one displaying the .iso file, were still opened and functioning correctly, the only thing missing from my screen was the progress dialog.

I clicked the Backtrace tab in TDE Crash Handler, and to my surprise it took an entire hour to load a backtrace before displaying a dialog telling me that it could *not* generate a backtrace. During that time, the TDE Crash Handler consistently used anywhere from 80% to 105% of my CPU according to top. After spam-clicking the close button and allowing TDE to kill it, the Crash Handler process is replaced by a gdb instance with the same process ID, using anywhere from 98% to 101% of my CPU. I have killed gdb since is (currently) seems incapable of providing a backtrace in any reasonable amount of time for this bug. This is the first time ever that I have seen this kind of behavior from gdb or the TDE Crash Handler, so something major must be broken.

Comment 1 Michele Calgaro 2019-01-13 09:26:52 CST

Hi Kristopher,
Konqueror seems to work fine here and also on some other users when clicking on .iso file.
Is this still happening on your side? And if so, could it be that the iso file was too big and your computer ran out of RAM when you tested?

Comment 2 Michele Calgaro 2019-03-07 07:43:27 CST

We are unable to repdroduce this bug, no matter how many times we tried.
After discussing with the other devs, we have decided to close it. Feel free to reopen it in case you can reproduce it systematically.
From the description of the bug (and Kristopher computer from ohter bugs) we believe the computer was running out of memory and swap space if case the .iso was bigger than the free space.
Happy to work on this if the bug can be reproduce systematically.