Bug 230343 - Closing app with 2 projects loaded
Summary: Closing app with 2 projects loaded
Status: RESOLVED DUPLICATE of bug 230748
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (old) (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR crash
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-11 18:03 UTC by Eric Thiele
Modified: 2010-03-26 19:52 UTC (History)
1 user (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 Eric Thiele 2010-03-11 18:03:13 UTC
Application that crashed: kdevelop.bin
Version of the application: 3.9.99 (using KDevPlatform 0.9.99)
KDE Version: 4.4.1 (KDE 4.4.1)
Qt Version: 4.6.2
Operating System: Linux 2.6.32-gentoo x86_64

What I was doing when the application crashed:
open two customs make projects and then cloased app. Now BAckgrund task were running.

 -- Backtrace:
Application: KDevelop (/usr/bin/kdevelop.bin), signal: Segmentation fault
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.2200.4-gdb.py", line 9, in <module>
    from gobject import register
  File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
    import gdb.backtrace
ImportError: No module named backtrace
The current source language is "auto; currently asm".
[Current thread is 1 (Thread 0x7f00b022a760 (LWP 26578))]

Thread 3 (Thread 0x7f009e19f710 (LWP 26581)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211
#1  0x00007f00acb0dbd7 in QWaitConditionPrivate::wait (this=0x24dc088, mutex=0x24dc090, time=200000) at thread/qwaitcondition_unix.cpp:85
#2  QWaitCondition::wait (this=0x24dc088, mutex=0x24dc090, time=200000) at thread/qwaitcondition_unix.cpp:159
#3  0x00007f00a9540f7e in KDevelop::DUChainPrivate::CleanupThread::run (this=0x24dc070) at /var/tmp/portage/dev-util/kdevplatform-0.9.99/work/kdevplatform-0.9.99/language/duchain/duchain.cpp:286
#4  0x00007f00acb0cd05 in QThreadPrivate::start (arg=0x24dc070) at thread/qthread_unix.cpp:248
#5  0x00007f00ac87e4f7 in start_thread (arg=<value optimized out>) at pthread_create.c:297
#6  0x00007f00aaf3cc7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f0089337710 (LWP 26595)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f00aa101cf6 in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x7f00aa3e0220) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2304
#2  0x00007f00aa101d39 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=0x7f00aa3ee2ec) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1438
#3  0x00007f00ac87e4f7 in start_thread (arg=<value optimized out>) at pthread_create.c:297
#4  0x00007f00aaf3cc7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f00b022a760 (LWP 26578)):
[KCrash Handler]
#5  0x00007f00aaedcda7 in malloc_consolidate (av=0x7f0084000020) at malloc.c:5142
#6  0x00007f00aaede5e0 in _int_free (av=0x7f0084000020, p=0x7f00879f6df0) at malloc.c:5015
#7  0x00007f00aaee190c in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3738
#8  0x00007f008adba5b8 in ~KDevVarLengthArray (this=0x3266f40, __in_chrg=<value optimized out>) at /usr/include/kdevplatform/util/kdevvarlengtharray.h:120
#9  ~TemporaryDataManager (this=0x3266f40, __in_chrg=<value optimized out>) at /usr/include/kdevplatform/language/duchain/appendedlist.h:80
#10 0x00007f008adb85a7 in destroy () at /var/tmp/portage/dev-util/kdevelop-3.9.99/work/kdevelop-3.9.99/languages/cpp/parser/rpp/pp-macro.cpp:31
#11 0x00007f00aae9dfc5 in __run_exit_handlers (status=0, listp=0x7f00ab1bf4a8, run_list_atexit=true) at exit.c:78
#12 0x00007f00aae9e015 in *__GI_exit (status=-2080374752) at exit.c:100
#13 0x00007f00aae87bad in __libc_start_main (main=0x404860 <main>, argc=1, ubp_av=0x7fffea8df268, init=0x409a60 <__libc_csu_init>, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7fffea8df258) at libc-start.c:252
#14 0x0000000000404729 in _start () at ../sysdeps/x86_64/elf/start.S:113

Reported using DrKonqi
Comment 1 David Nolden 2010-03-14 18:07:00 UTC
Is this reproducible? It looks very unnormal, what version of libc are you using?
Comment 2 Andreas Pakulat 2010-03-14 19:40:31 UTC
(In reply to comment #1)
> Is this reproducible? It looks very unnormal, what version of libc are you
> using?

In case you hoped for that, this is not the libc 2.10 bug, that one crashes in malloc_printerr - always. Its strange nonetheless.
Comment 3 Eric Thiele 2010-03-15 18:38:54 UTC
Version was 2.11-r1 (gentoo)
Comment 4 Andreas Pakulat 2010-03-26 19:52:05 UTC

*** This bug has been marked as a duplicate of bug 230748 ***