Version: (using KDE KDE 3.4.0) Installed from: Debian testing/unstable Packages I just experienced this twice. once with a .tar.gz, once with a .zip. Reproduce it like this: Open a konqueror window (for example in ~). Split it. open in one side a .{zip|gz|whatevercompressed} file go to the other side. open another {file|folder}. go back to the side with the compressed folder open. go up using the up-arrow in toolbar or alt-up -> CRASH! This is especially annoying because it will happen, when you're deep into your work with a lot of windows {split|open|working in}.
Debian konqueror 3.4 crashes, self compiled 3_4_BRANCH in FreeBSD won't.
Up to date 3_4_BRANCH build on debian. kio (KDirListerCache): [void KDirListerCache::slotUpdateResult(KIO::Job*)] finished update file:///home/teve/src ASSERT: "listers" in kdirlister.cpp (1444) KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = konqueror path = <unknown> pid = 7925 #3 0xb71f3b68 in QGList::first () from /opt/qt334/lib/libqt-mt.so.3 #4 0xb7c6ee57 in QPtrList<KDirLister>::first (this=0x0) at qptrlist.h:109 #5 0xb7c3d263 in KDirListerCache::slotUpdateResult (this=0x846e5f8, j=0x8377108) at kdirlister.cpp:1477 #6 0xb7c4315b in KDirListerCache::qt_invoke (this=0x846e5f8, _id=10, _o=0xbfffed00) at kdirlister_p.moc:135 #7 0xb6f42aec in QObject::activate_signal () from /opt/qt334/lib/libqt-mt.so.3 #8 0xb7bab3ab in KIO::Job::result (this=0x8377108, t0=0x8377108) at jobclasses.moc:156 #9 0xb7b967be in KIO::Job::emitResult (this=0x8377108) at job.cpp:218 #10 0xb7b97dca in KIO::SimpleJob::slotFinished (this=0x8377108) at job.cpp:547 #11 0xb7b9f39a in KIO::ListJob::slotFinished (this=0x8377108) at job.cpp:2050 #12 0xb7baf4f7 in KIO::ListJob::qt_invoke (this=0x8377108, _id=16, _o=0xbfffef90) at jobclasses.moc:1713 #13 0xb6f42aec in QObject::activate_signal () from /opt/qt334/lib/libqt-mt.so.3 #14 0xb6f42914 in QObject::activate_signal () from /opt/qt334/lib/libqt-mt.so.3 #15 0xb7b8ddf9 in KIO::SlaveInterface::finished (this=0x8350618) at slaveinterface.moc:226 #16 0xb7b8c404 in KIO::SlaveInterface::dispatch (this=0x8350618, _cmd=104, rawdata=@0xbffff180) at slaveinterface.cpp:243 #17 0xb7b8c074 in KIO::SlaveInterface::dispatch (this=0x8350618) at slaveinterface.cpp:173 #18 0xb7b89f2f in KIO::Slave::gotInput (this=0x8350618) at slave.cpp:300 #19 0xb7b8b913 in KIO::Slave::qt_invoke (this=0x8350618, _id=4, _o=0xbffff2a0) at slave.moc:113 #20 0xb6f42aec in QObject::activate_signal () from /opt/qt334/lib/libqt-mt.so.3 #21 0xb6f42c4d in QObject::activate_signal () from /opt/qt334/lib/libqt-mt.so.3 #22 0xb72796f2 in QSocketNotifier::activated () from /opt/qt334/lib/libqt-mt.so.3 #23 0xb6f5f2d0 in QSocketNotifier::event () from /opt/qt334/lib/libqt-mt.so.3 #24 0xb6ee61bf in QApplication::internalNotify () from /opt/qt334/lib/libqt-mt.so.3 #25 0xb6ee57be in QApplication::notify () from /opt/qt334/lib/libqt-mt.so.3 #26 0xb75752a0 in KApplication::notify (this=0xbffff9a0, receiver=0x836d960, event=0xbffff5c0) at kapplication.cpp:549 #27 0xb6ed5bba in QEventLoop::activateSocketNotifiers () from /opt/qt334/lib/libqt-mt.so.3 #28 0xb6e8ebd3 in QEventLoop::processEvents () from /opt/qt334/lib/libqt-mt.so.3 #29 0xb6ef85d8 in QEventLoop::enterLoop () from /opt/qt334/lib/libqt-mt.so.3 #30 0xb6ef8488 in QEventLoop::exec () from /opt/qt334/lib/libqt-mt.so.3 #31 0xb6ee6411 in QApplication::exec () from /opt/qt334/lib/libqt-mt.so.3 #32 0xb7f5caf4 in kdemain (argc=1, argv=0xbffffb24) at konq_main.cc:206 #33 0x08048696 in main (argc=1, argv=0xbffffb24) at konqueror.la.cc:2
*** Bug 103923 has been marked as a duplicate of this bug. ***
Created attachment 10661 [details] Another backtrace with more details.
*** Bug 104061 has been marked as a duplicate of this bug. ***
*** Bug 104170 has been marked as a duplicate of this bug. ***
*** Bug 104410 has been marked as a duplicate of this bug. ***
I still cannot reproduce. Pasting the backtrace from attachment 10661 [details] for easier searching (backtraces should never be attached): Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2003)] [KCrash handler] #5 0xb76b416d in QGList::first (this=0x0) at tools/qglist.cpp:839 #6 0xb7d9711b in QPtrList<KDirLister>::first (this=0x0) at qptrlist.h:109 #7 0xb7d9163b in KDirListerCache::slotUpdateResult (this=0x8692228, j=0x8545b08) at kdirlister.cpp:1477 #8 0xb7d960ca in KDirListerCache::qt_invoke (this=0x8692228, _id=10, _o=0xbf81aeb0) at kdirlister_p.moc:135 #9 0xb73df40f in QObject::activate_signal (this=0x8545b08, clist=0x82328c8, o=0xbf81aeb0) at kernel/qobject.cpp:2355 #10 0xb7cfff97 in KIO::Job::result (this=0x8545b08, t0=0x8545b08) at jobclasses.moc:156 #11 0xb7cecce6 in KIO::Job::emitResult (this=0x8545b08) at job.cpp:218 #12 0xb7cee0f7 in KIO::SimpleJob::slotFinished (this=0x8545b08) at job.cpp:551 #13 0xb7cf4c81 in KIO::ListJob::slotFinished (this=0x8545b08) at job.cpp:2056 #14 0xb7d0383a in KIO::ListJob::qt_invoke (this=0x8545b08, _id=16, _o=0xbf81b110) at jobclasses.moc:1713 #15 0xb73df40f in QObject::activate_signal (this=0x84cdee8, clist=0x84cf198, o=0xbf81b110) at kernel/qobject.cpp:2355 #16 0xb73df2b2 in QObject::activate_signal (this=0x84cdee8, signal=6) at kernel/qobject.cpp:2324 #17 0xb7ce19dd in KIO::SlaveInterface::finished (this=0x84cdee8) at slaveinterface.moc:226 #18 0xb7ce0245 in KIO::SlaveInterface::dispatch (this=0x84cdee8, _cmd=104, rawdata=@0xbf81b2d0) at slaveinterface.cpp:243 #19 0xb7cdfee3 in KIO::SlaveInterface::dispatch (this=0x84cdee8) at slaveinterface.cpp:173 #20 0xb7cddd0f in KIO::Slave::gotInput (this=0x84cdee8) at slave.cpp:300 #21 0xb7cdf57f in KIO::Slave::qt_invoke (this=0x84cdee8, _id=4, _o=0xbf81b3e0) at slave.moc:113 #22 0xb73df40f in QObject::activate_signal (this=0x84cd348, clist=0x84ca620, o=0xbf81b3e0) at kernel/qobject.cpp:2355 #23 0xb73df749 in QObject::activate_signal (this=0x84cd348, signal=2, param=13) at kernel/qobject.cpp:2448 #24 0xb773f745 in QSocketNotifier::activated (this=0x84cd348, t0=13) at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85 #25 0xb73ff473 in QSocketNotifier::event (this=0x84cd348, e=0xbf81b690) at kernel/qsocketnotifier.cpp:258 #26 0xb737c815 in QApplication::internalNotify (this=0xbf81ba40, receiver=0x84cd348, e=0xbf81b690) at kernel/qapplication.cpp:2635 #27 0xb737bd56 in QApplication::notify (this=0xbf81ba40, receiver=0x84cd348, e=0xbf81b690) at kernel/qapplication.cpp:2358 #28 0xb79b3ce3 in KApplication::notify (this=0xbf81ba40, receiver=0x84cd348, event=0xbf81b690) at kapplication.cpp:549 #29 0xb7eee5ce in QApplication::sendEvent (receiver=0x84cd348, event=0xbf81b690) at qapplication.h:491 #30 0xb736b254 in QEventLoop::activateSocketNotifiers (this=0x80b4738) at kernel/qeventloop_unix.cpp:578 #31 0xb7323cb5 in QEventLoop::processEvents (this=0x80b4738, flags=4) at kernel/qeventloop_x11.cpp:383 #32 0xb7390c5f in QEventLoop::enterLoop (this=0x80b4738) at kernel/qeventloop.cpp:198 #33 0xb7390b7a in QEventLoop::exec (this=0x80b4738) at kernel/qeventloop.cpp:145 #34 0xb737c981 in QApplication::exec (this=0xbf81ba40) at kernel/qapplication.cpp:2758 #35 0xb663fd89 in kdemain (argc=2, argv=0x8088bf8) at konq_main.cc:206 #36 0xb6fdd720 in kdeinitmain (argc=2, argv=0x8088bf8) at konqueror_dummy.cc:2 #37 0x0804e1eb in launch (argc=2, _name=0x808940c "konqueror", args=0x808941f "\001", cwd=0x0, envc=1, envs=0x8089430 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x8089434 "ulixys;1113619540;713128;1327_TIME154099") at kinit.cpp:625 #38 0x0804f3cf in handle_launcher_request (sock=8) at kinit.cpp:1189 #39 0x0804f9fc in handle_requests (waitForPid=0) at kinit.cpp:1392 #40 0x08050e07 in main (argc=2, argv=0xbf81c0b4, envp=0xbf81c0c0) at kinit.cpp:1836
*** Bug 104536 has been marked as a duplicate of this bug. ***
Enter with konqueror in an arhive (I've tried .zip;.tar.bz2) (it will be in arh_type://arhive_name.extension/)and press "Up"(the icon) or Alt+Up(kb) CRASH
It will crash NOT ONLY when konqueror window is split ;please rename the bug
It seems that all reports are from DEbian systems ....
*** Bug 104540 has been marked as a duplicate of this bug. ***
bash-3.00$ valgrind --tool=memcheck --num-callers=16 konqueror ==25665== Memcheck, a memory error detector for x86-linux. ==25665== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==25665== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==25665== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==25665== For more details, rerun with: -v ==25665== ==25675== Thread 2: ==25675== Conditional jump or move depends on uninitialised value(s) ==25675== at 0x1CE50658: __pthread_manager (in /lib/libpthread-0.10.so) ==25675== by 0x1BA93219: clone (in /lib/libc-2.3.4.so) ==25675== ==25675== Syscall param clone(child_tidptr) contains uninitialised byte(s) ==25675== at 0x1BA9320C: clone (in /lib/libc-2.3.4.so) ==25675== by 0x1BA93219: clone (in /lib/libc-2.3.4.so) libkonq: WARNING: Could not load wallpaper /opt/kde/share/apps/konqueror/tiles/ ASSERT: "listers" in kdirlister.cpp (1444) ==25665== ==25665== Thread 1: ==25665== Invalid read of size 4 ==25665== at 0x1CA281B9: QGList::first() (in /opt/kde/lib/libqt-mt.so.3.3.4) ==25665== by 0x1BDFBD1C: QPtrList<KDirLister>::first() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BDFB1CD: KDirListerCache::slotUpdateResult(KIO::Job*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BDFBA67: KDirListerCache::qt_invoke(int, QUObject*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1C7341DC: QObject::activate_signal(QConnectionList*, QUObject*) (in /opt/kde/lib/libqt-mt.so.3.3.4) ==25665== by 0x1BD54ED4: KIO::Job::result(KIO::Job*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD54F6A: KIO::Job::emitResult() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD57FC3: KIO::SimpleJob::slotFinished() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD62F89: KIO::ListJob::slotFinished() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD6A217: KIO::ListJob::qt_invoke(int, QUObject*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1C7341DC: QObject::activate_signal(QConnectionList*, QUObject*) (in /opt/kde/lib/libqt-mt.so.3.3.4) ==25665== by 0x1C734C6D: QObject::activate_signal(int) (in /opt/kde/lib/libqt-mt.so.3.3.4) ==25665== by 0x1BD444D6: KIO::SlaveInterface::finished() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD4629E: KIO::SlaveInterface::dispatch(int, QMemArray<char> const&) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD45BCB: KIO::SlaveInterface::dispatch() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD421B3: KIO::Slave::gotInput() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== Address 0x8 is not stack'd, malloc'd or (recently) free'd KCrash: Application 'konqueror' crashing... ==25665== ==25665== Invalid free() / delete / delete[] ==25665== at 0x1B903AAF: free (in /usr/lib/valgrind/vgpreload_memcheck.so) ==25665== by 0x1BACD53B: free_mem (in /lib/libc-2.3.4.so) ==25665== by 0x1BACD0D1: __libc_freeres (in /lib/libc-2.3.4.so) ==25665== by 0x1B8FD9E2: _vgw(float, long double,...)(...)(long double,...)(short) (in /usr/lib/valgrind/vg_inject.so) ==25665== by 0x1C323BC1: KCrash::defaultCrashHandler(int) (in /opt/kde/lib/libkdecore.so.4.2.0) ==25665== by 0x1CE55C66: __pthread_sighandler (in /lib/libpthread-0.10.so) ==25665== by 0x1BA03857: (within /lib/libc-2.3.4.so) ==25665== by 0x1BDFBD1C: QPtrList<KDirLister>::first() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BDFB1CD: KDirListerCache::slotUpdateResult(KIO::Job*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BDFBA67: KDirListerCache::qt_invoke(int, QUObject*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1C7341DC: QObject::activate_signal(QConnectionList*, QUObject*) (in /opt/kde/lib/libqt-mt.so.3.3.4) ==25665== by 0x1BD54ED4: KIO::Job::result(KIO::Job*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD54F6A: KIO::Job::emitResult() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD57FC3: KIO::SimpleJob::slotFinished() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD62F89: KIO::ListJob::slotFinished() (in /opt/kde/lib/libkio.so.4.2.0) ==25665== by 0x1BD6A217: KIO::ListJob::qt_invoke(int, QUObject*) (in /opt/kde/lib/libkio.so.4.2.0) ==25665== Address 0x1CEE3340 is not stack'd, malloc'd or (recently) free'd ==25665== ==25665== ERROR SUMMARY: 9 errors from 4 contexts (suppressed: 241 from 9) ==25665== malloc/free: in use at exit: 5672492 bytes in 111966 blocks. ==25665== malloc/free: 874574 allocs, 762609 frees, 41691695 bytes allocated. ==25665== For counts of detected errors, rerun with: -v ==25665== searching for pointers to 111966 not-freed blocks. ==25665== checked 7356084 bytes. ==25665== ==25665== LEAK SUMMARY: ==25665== definitely lost: 740 bytes in 18 blocks. ==25665== possibly lost: 2820 bytes in 2 blocks. ==25665== still reachable: 5668932 bytes in 111946 blocks. ==25665== suppressed: 0 bytes in 0 blocks. ==25665== Use --leak-check=full to see details of leaked memory. bash-3.00$
Created attachment 10791 [details] konq-val.txt
> It seems that all reports are from DEbian systems .... No I don't use a Debian system here. So please don't make this become a distribution specific bug.
*** Bug 104844 has been marked as a duplicate of this bug. ***
*** Bug 104862 has been marked as a duplicate of this bug. ***
*** Bug 104866 has been marked as a duplicate of this bug. ***
*** Bug 104924 has been marked as a duplicate of this bug. ***
I have this error, some times, when access the System icon in my desktop. Reproduce it like this: - Open System in desktop; - In System, open Media; - Close the Konqueror; - Open System in desktop again; - Open Media again and the KDE will go CRASH! This error occurs in the second access. My Linux is Debian Testing (Sarge) with KDE .deb packages from this repository: http://pkg-kde.alioth.debian.org/kde-3.4.0/
*** Bug 105050 has been marked as a duplicate of this bug. ***
If you see ALL the bug reports are from debian systems with KDE 3.4 Bug 105050 Bug 104924 Bug 104866 Bug 104862 Bug 104844 Bug 104540 Bug 104536 Bug 104410 Bug 104170 Bug 104061 Bug 103923 So I haven't seen any report from another distro (comment #16 does not mention the distro;maybe is Debian based(maybe Ubuntu?))
Bug 103923 does not say the distro(is from the person with comment #16) sorry
> So I haven't seen any report from another distro (comment #16 does not mention > the distro; maybe is Debian based (maybe Ubuntu?)) No, I don't use Debian, neither Ubuntu nor any other Debian based System. My entire System is build up from Sources and it went through quite a few iterations over the years (e.g. compiled out of itself again with newer and newer stuff). It's not just a copy over old, It's a sane new build every time in a new chroot Environment. I even use my own Initscripts only to complete this. Nonetheless this behavior was also reported by other people visiting the #kde-devel IRC channel. I recall one was using gentoo and another one again a different system. Now there are a few options that are hard to trigger. I tried this, compiled KDE CVS HEAD (everytime it's a new update from CVS) with gcc 3.4.3 using -O2 -s -pipe and the problem exists on an AMD XP 2600 CPU machine. Then I recompiled everything without optimization with -O0 -s -pipe and the problem still exists. Later on I tried the same with gcc 4.0.0 before it got blacklisted same options as above and the problem still exist. So what else can trigger this issue than KDE or a part inside KDE or the kioslave itself ? Trying two different flags passed to the compiler and two different compilers. So this is hardly not a broken code generation issue, there is also no magic leet options used either, no architecture specific stuff like -march and nothing else so it's quite asumable that ix86 architecture usually generates more or less usable code. We had some talks in the #kde-devel channel some days ago with a slightly offtopic stuff such as 'do you use the correct libraries'. There are even some developers who have a working KDE install sitting in /usr/ and thus having /usr/lib/ filled up with KDE libraries and /usr/include/ with KDE headerfiles. And then using some build script to re-compile nightly CVS and have it set in a prefix like /opt/kde/. The problem now as I know it from my former GNOME times and creator and maintainer of CVSGnome there can be this assumable theoretical problem that the compiler as well as linker has a search precedence for libraries during linktime inside /usr/lib/ so it's assumable that people might compile a new KDE in a different prefix but by mistake compile and link against the old cruft found in /usr/. Even changing PREFIX'es or other stuff won't help here. It's usually required to patch either libtool or remove the old cruft from /usr/ entirely to make sure that a KDE build from CVS compiles and operates instantly and without any errors. On my System this is the case, there is only one KDE and it's sitting in /opt/kde/ here. I don't exactly know how the ZIP specific iolave works since it's just the ZIP stuff that borks here. Every other archive format seem to work instantly and perfectly. ARK works perfectly in this aspect as well. This is and can only be a code issue or (assuming here) in case the ioslave calls an external program such as ZIP, that the ZIP binary might cause problems.
*** Bug 105042 has been marked as a duplicate of this bug. ***
Ok I made the following stuff today: a) I recompiled entire KDE from CVS/SVN :) b) --enable-debug=full c) -O0 -g -Wl,--as-needed Then I re-run Konqueror one time through valgrind and then again through GDB. While running Konqueror through valgrind, I got plenty of output but then the crashandler from KDE jumped in and the backtrace from it was useless because it was the wrong thread. I then re-run Konqueror through GDB and the results were quite more interesting. I got a quite interesting full backtrace in kdirlister.cpp and hope its of more use now. Here is the interesting part of that backtrace. I am going to attach the valgrind.txt as well as gdb.txt file as well in hope it's of help. (gdb) bt full #0 0xb7054228 in QGList::first () from /opt/kde/lib/libqt-mt.so.3 No symbol table info available. #1 0xb7a9c96d in QPtrList<KDirLister>::first (this=0x0) at qptrlist.h:109 No locals. #2 0xb7a9625b in KDirListerCache::slotUpdateResult (this=0x8532e80, j=0x81f0100) at kdirlister.cpp:1477 job = (class KIO::ListJob *) 0x81f0100 dir = (KDirListerCache::DirItem *) 0x8216d80 dot = (const QString &) @0x0: Cannot access memory at address 0x0 (gdb) q And this is the interesting part from kdirlister.cpp line 1477 1475: // check if anyone wants the mimetypes immediately 1476: bool delayedMimeTypes = true; 1477:> for ( kdl = listers->first(); kdl; kdl = listers->next() ) <--- 1478: delayedMimeTypes &= kdl->d->delayedMimeTypes;
Created attachment 10895 [details] Output Valgrind.
Created attachment 10896 [details] Output GDB
Ok I did some more investigations in the Code, though my C++ knowledge kinda sucks bonobo balls :) but It was quite worth the effort anyways. The KDirListerCache function starting at line 1412 from file kdirlister.cpp: void KDirListerCache::slotUpdateResult( KIO::Job * j ) Is the cause of the problems. What did I do ? ;---------------------------------------- void KDirListerCache::slotUpdateResult( KIO::Job * j ) { return; Q_ASSERT( j ); KIO::ListJob *job = static_cast<KIO::ListJob *>( j ); KURL jobUrl = joburl( job ); jobUrl.adjustPath(-1); // need remove trailing slashes again, ... QString jobUrlStr = "file:///home/galaxy"; kdDebug(7004) << k_funcinfo << "finished update.: " << jobUrl << endl; kdDebug(7004) << k_funcinfo << "jobUrl.url......: " << jobUrl.url() << endl; kdDebug(7004) << k_funcinfo << "jobUrlStr.......: " << jobUrlStr << endl; KDirLister *kdl; QPtrList<KDirLister> *listers = urlsCurrentlyHeld[jobUrlStr]; QPtrList<KDirLister> *tmpLst = urlsCurrentlyListed.take( jobUrlStr ); if ( tmpLst ) { if ( listers ) for ( kdl = tmpLst->first(); kdl; kdl = tmpLst->next() ) { Q_ASSERT( listers->containsRef( kdl ) == 0 ); listers->append( kdl ); } else { listers = tmpLst; urlsCurrentlyHeld.insert( jobUrlStr, listers ); } } // once we are updating dirs that are only in the cache this will fail! Q_ASSERT( listers ); ;---------------------------------------- Ok we see this code fragment here. Why does the Q_ASSERT got emitted ? That was my first question. So listers somehow must be empty ? Or NULL as we say in C, just a quick guess but it was clear that something went wrong till there. From beginning of the functioncall till there. So my first assumption was whether jobUrl.url or JobUrlStr are right or containing something. QPtrList = 0x0 doesn't sound right either in the previous backtrace.. I don't know in detail but these things were floating around in my mind. kdDebug(7004) << k_funcinfo << "finished update.: " << jobUrl << endl; kdDebug(7004) << k_funcinfo << "jobUrl.url......: " << jobUrl.url() << endl; kdDebug(7004) << k_funcinfo << "jobUrlStr.......: " << jobUrlStr << endl; I started the good old printf ("%s", str); debugging way and I used the stuff what was there. I don't know whether I called the functions for output correctly but I gave it a try at least. JobUrl.url, JobUrlStr are all returning 'file:///home/galaxy' so the strings seem to be ok. My next thought was wheter the stuff might be in utf8 and I tried fiddling around with QString::fromUtf8(jobUrl.Url()); I assumed here whether it might be possible that the string should be constant chars and no Utf8... But since my knowledge about KDE's internals are quite basic and my C++ skills too I at least gave it a try but wasn't successful. So I continued my approach and came to the conclusion what might happen when I entirely disable this function by returning from it as soon as it gets called. I tried this as you can see in the above return; The result was that when leaving the *.zip files that nothing crashes anymore. I can use Konqueror normally again, nothing crashes and nothing bad happens. So the bug must be somewhere in there but don't ask me where.
I had a closer look at this part. Why is the Q_ASSERT happening listers empty ? well maybe tmpLst is empty so listers can't have any values either ? I tried adding a Q_ASSERT ( tmpLst ); at the bottom to test what is happening. And yes tmpLst seem to be NULL somehow. So what's going on here ? The assert is happening all the time. I then had the idea above again with the return from function. So I added an 'else return;' at the bottom of this if statement and compiled the whole thing. It came to my attention that this seem to work, still it's not known to me what causes this but for a small hack this seems to solve the issue. While browsing through my filelist I detected that the whole thing crashed on other ocassions as well and I found out that when there is nothing to insert, there is also nothing to be removed so I added a return; from the remove function. All in all I came to this small 'hack' (because it can not be considered anything reliable, serious or solving) that works for me meanwhile. I can enter ZIP archives, leave them again, do normal filemanaging, enter ZIP and other archives normally, get out of them again etc. Using asserts when possible to catch bugs is of course a reasonable thing but there should be some 'returns' from code either in case of trapping problems. ;------------------------ if ( tmpLst ) { if ( listers ) for ( kdl = tmpLst->first(); kdl; kdl = tmpLst->next() ) { Q_ASSERT( listers->containsRef( kdl ) == 0 ); listers->append( kdl ); } else { listers = tmpLst; urlsCurrentlyHeld.insert( jobUrlStr, listers ); } } // once we are updating dirs that are only in the cache this will fail! Q_ASSERT( listers ); ;------------------------
Created attachment 10898 [details] This is a hack that works for me TM!
I have investigated some more into this. ;------------- QPtrList<KDirLister> *listers = urlsCurrentlyHeld[jobUrlStr]; QPtrList<KDirLister> *tmpLst = urlsCurrentlyListed.take( jobUrlStr ); ;------------- We figured out that tmpLst is empty and thus run into the assert. We also found out that jobUrlStr contains a valid constant string. This constant string is somewhere located in memory at some address. So tmpLst should point at that address where the string is and should therefore contain an address. Why is this not happening ?
*** Bug 105389 has been marked as a duplicate of this bug. ***
*** Bug 105402 has been marked as a duplicate of this bug. ***
*** Bug 105553 has been marked as a duplicate of this bug. ***
Michael wanted more bug reports..
Thanks, I'll be on it soon. Jeez, 4 weeks and already thousands of helpful comments :-) I have the suspicion that I broke it when doing the KDirLister optimizations, we'll see...
SVN commit 415093 by brade: The evening begins quite well -- that was easy to fix, though a bit embarrassing :-\ My redirection code wasn't perfect.. ehm, complete, I forgot about 2 important lines. What happened is this: When pressing up while being in an archive we end up in e.g. tar:/home/michael, which redirects to file:///home/michael. The item is in the cache already, but in this case I forgot to insert the listers and holders with the new url back into the KDirListerCache. Sorry... Many thanks for all the reports! Much appreciated. BUG: 103795, 105827, 104973 M +3 -0 trunk/KDE/kdelibs/kio/kio/kdirlister.cpp --- trunk/KDE/kdelibs/kio/kio/kdirlister.cpp #415092:415093 @@ -1207,6 +1207,9 @@ delete dir; itemsInUse.insert( newUrl.url(), newDir ); + urlsCurrentlyListed.insert( newUrl.url(), listers ); + if ( holders ) + urlsCurrentlyHeld.insert( newUrl.url(), holders ); // emit old items: listers, holders for ( KDirLister *kdl = listers->first(); kdl; kdl = listers->next() )
*** Bug 106009 has been marked as a duplicate of this bug. ***
*** Bug 103942 has been marked as a duplicate of this bug. ***
*** Bug 104149 has been marked as a duplicate of this bug. ***
*** Bug 106083 has been marked as a duplicate of this bug. ***
Re: Bug 106083 I upgraded to 417237 and it appears to be fixed. Good! We do need to develop methods to avoid such regressions.
*** Bug 106550 has been marked as a duplicate of this bug. ***
*** Bug 106575 has been marked as a duplicate of this bug. ***
*** Bug 106933 has been marked as a duplicate of this bug. ***
*** Bug 107115 has been marked as a duplicate of this bug. ***
*** Bug 107270 has been marked as a duplicate of this bug. ***
*** Bug 107386 has been marked as a duplicate of this bug. ***
After poweroff the computer i can reproduce the bug / issue. The easy way to reproduce it's: (On Fedora Core 4 Test 3, KDE 3.4.0) Open Konqueror from the taskbar panel (Home icon) Push detailed view button Open a .tar.bz2 file Push Up button. ...and the result ...the SIGSEGV Signal 11 crash. If the problem was solved there are a patch, app, release to solve it?? Thnxs
El Martes, 14 de Junio de 2005 17:05, Torrent escribió: || If the problem was solved there are a patch, app, release to solve it?? || Thnxs This bug is fixed in my KDE 3.4.1
Yes, it's fixed. If you want a patch, please see comment #39.
*** Bug 107436 has been marked as a duplicate of this bug. ***
*** Bug 107578 has been marked as a duplicate of this bug. ***
*** Bug 108158 has been marked as a duplicate of this bug. ***
*** Bug 109506 has been marked as a duplicate of this bug. ***
*** Bug 110108 has been marked as a duplicate of this bug. ***
*** Bug 112719 has been marked as a duplicate of this bug. ***
*** Bug 113456 has been marked as a duplicate of this bug. ***
*** Bug 115678 has been marked as a duplicate of this bug. ***
*** Bug 115688 has been marked as a duplicate of this bug. ***
*** Bug 115697 has been marked as a duplicate of this bug. ***
*** Bug 118395 has been marked as a duplicate of this bug. ***
*** Bug 127807 has been marked as a duplicate of this bug. ***
Does someone experiences this same problem in present? I have KDE 4.14.3. I connect to a server via sftp, browse to a zip file, open it, and when I click up it always crashes. Details: Executable: konqueror PID: 4595 Signal: Segmentation fault (11) Time: 23 01 2015 17:15:17 The Reporting Assistant won't send the auto crash report.
Manu, it does not make sense to add comments to ten year old bugs. Without providing the backtrace of your crash, nobody will be able to help you. But what you see might be bug 341187, which is fixed in KDE Applications 14.12 release.