Bug 206534 - Marble crashes when sending multiple queries too fast (QMutex::lock, QThreadPrivate::finish)
Summary: Marble crashes when sending multiple queries too fast (QMutex::lock, QThread...
Status: RESOLVED FIXED
Alias: None
Product: marble
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: 0.10 (KDE 4.5)
Assignee: marble-bugs
URL:
Keywords:
: 221541 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-06 20:36 UTC by Oliver Putz
Modified: 2010-05-19 00:56 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Putz 2009-09-06 20:36:24 UTC
Version:           0.8.1 (using 4.3.1 (KDE 4.3.1), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.30-gentoo-r4

Steps to reproduce:

1) Search for some city (e.g. kiel)
2) Quickly append and remove characters to / from the query (possibly try hitting enter each time you modified the search query)
3) After several attempts you should see marble crash with a backtrace like the one below

Note: This seems not to be related to the particular map view. Perhaps problems with different queries scrolling the globe too quickly to different locations?

#0  QMutex::lock (this=0x80) at thread/qmutex.cpp:152
	self = <value optimized out>
#1  0x00007f3c68345750 in QThreadPrivate::finish (arg=<value optimized out>) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:120
	thr = (class QThread *) 0x21c6ca0
	d = (class QThreadPrivate *) 0x0
	locker = {{mtx = 0x80, val = 128}}
#2  0x00007f3c683458ed in QThreadPrivate::start (arg=0x21c6ca0) at thread/qthread_unix.cpp:191
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {139897196906832, 5607221268078788116, 140735590027936, 139897196904960, 139897196906832, 4096, 
        -5501024362364797420, -5501135536250814956}, __mask_was_saved = 0}}, __pad = {0x7f3c5aba0170, 0x0, 0x7f3c676da182, 0x7f3c5aba0200}}
	not_first_call = <value optimized out>
#3  0x00007f3c680d5017 in start_thread (arg=<value optimized out>) at pthread_create.c:297
	__res = <value optimized out>
	pd = (struct pthread *) 0x7f3c5aba0950
	unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139897196906832, 5607221268078788116, 140735590027936, 139897196904960, 139897196906832, 4096, -5501024362354311660, 
        -5501135870605656556}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
	not_first_call = <value optimized out>
	robust = <value optimized out>
#4  0x00007f3c676a348d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#5  0x0000000000000000 in ?? ()
No symbol table info available.
The program is running.  Exit anyway? (y or n)
Comment 1 Dennis Nienhüser 2009-11-06 16:53:54 UTC
SVN commit 1045679 by nienhueser:

Clear orphane search results from the model so that they do not appear as empty entries at the end of the search result list after several searches.
Guard access to the model to prevent crashes when modifying it concurrently. Cannot be done in the model itself easily since it doesn't encapsulate its data storage.
CCBUG: 206534


 M  +6 -0      MarbleRunnerManager.cpp  
 M  +2 -1      MarbleRunnerManager.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1045679
Comment 2 Dennis Nienhüser 2010-01-06 18:01:45 UTC
*** Bug 221541 has been marked as a duplicate of this bug. ***
Comment 3 jensmh 2010-05-19 00:56:07 UTC
We think that the problem has been dealt with.
If this is not the case please feel free to reopen the bug report if necessary.