https://bugs.kde.org/show_bug.cgi?id=492956
Bug ID: 492956
Summary: konqueror uses 100% of one cpu frozen at startup
Classification: Frameworks and Libraries
Product: frameworks-kio
Version: 6.5.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kio-bugs-n...@kde.org
Reporter: pio...@netscape.net
CC: kdelibs-b...@kde.org
Target Milestone: ---
SUMMARY
I am not sure it is just konqueror since plasmashell too is using up one cpu
while the favourites list in the start-menu is empty. cannot debug that problem
though since plasmashell is doing so many things in various threads
simultaneously. so I'll focus on what I found in debugging konqueror:
STEPS TO REPRODUCE
1. start konqueror
2. get unlucky
3. you can kill konqueror now
OBSERVED RESULT
gdb shows the process hangs in std::_Rb_tree_increment(std::_Rb_tree_node_base
const*) which is called from QMap<int,
KIO::SimpleJob*>::const_iterator::operator++ which is called from QMap<int,
KIO::SimpleJob*>::erase
```
(gdb) p this->d.d->m
$7 = {_M_t = {
_M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<int const,
KIO::SimpleJob*> > >> = {<std::__new_allocator<std::_Rb_tree_node<std::pair<int
const, KIO::SimpleJob*> > >> = {<No data fields>}, <No data fields>},
<std::_Rb_tree_key_compare<std::less<int> >> = {
_M_key_compare = {<std::binary_function<int, int, bool>> = {<No data
fields>}, <No data fields>}}, <std::_Rb_tree_header> = {_M_header = {_M_color =
std::_S_red,
_M_parent = 0x0, _M_left = 0x5555576b3c90, _M_right =
0x5555576b3c90}, _M_node_count = 0}, <No data fields>}}}
```
so you are calling erase on an empty std::map and the mentioned iterator's
increment assembly code just loops through the tree in search for a null-value
never finding any since the left and right branch point back at itself.
the problematic sources is however not KIO::HostQueue::takeFirstInQueue which
calls that erase, but logically its caller who failed to check if there is a
non-empty queue to begin with.
EXPECTED RESULT
I expect you to change KIO::ProtoQueue::startAJob in src/core/scheduler.cpp to
somehow verify the HostQueue hq is non-empty before the line
```
SimpleJob *startingJob = hq->takeFirstInQueue();
```
or something similar since you cannot rely on an empty map to conveniently have
a tree that ends in null. there is even an assert in debug-mode that should
have been triggered when your developers tried it out! or maybe something is
wrong with my system causing such misbehaviour. don't even know if my
suggestion makes sense as I am not a kde-developer myself and have no idea what
those things are supposed to do. all I know is konqueror always worked and now
it does not. and likely next reboot it will work again or just crash. but if
this is a mistake someone made due to misunderstanding the c++ standard, then
please communicate that to everyone making use of std::map (or rather QMap):
before any kind of increment or erasing make sure the container is not empty!
without asserts enabled computer will just randomly freeze and maybe segfault
otherwise and that's bad for the popularity of plasma!
SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
Operating System: Gentoo Linux 2.15
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
--
You are receiving this mail because:
You are watching all bug changes.
