| Summary: | ktorrent-dev: latest updates; crash during normal downloads | ||
|---|---|---|---|
| Product: | [Applications] ktorrent | Reporter: | George R. Goffe <grgoffe> |
| Component: | general | Assignee: | Joris Guisson <joris.guisson> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | cfeck |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | sanitized output from gdb run from the script command | ||
|
Description
George R. Goffe
2011-08-21 16:34:34 UTC
Just curious, how often do you want to report this bug? Joris, why does kt::GUI::infoMsg() use a local event loop, causing nested dialogs? Christoph, That's a fair question. It is my intent to provide as much info as possible. All these look different so I keep hoping that there's a tiny bit of information in them that it will help. I could stop reporting the problem if that's what you guys want. I am curious, though, as to how this bug was resolved as fixed. Regards, George... > I could stop reporting the problem if that's what you guys want. No, please continue reporting bugs, but in this case, they all crash in QAbstractSocketEngine::state(), so DrKonqi should have listed duplicates. > I am curious, though, as to how this bug was resolved as fixed. Either it has something to do with unavailable file/socket descriptors, or nested event loops. Both are evil bugs that are not easy to fix. > Joris, why does kt::GUI::infoMsg() use a local event loop, causing nested > dialogs? It just calls one of the static KMessageBox functions to display a message box. I don't think nested event loops have anything to do with it. Bug 278555 does not happen after a lot of nested eventloops. *** This bug has been marked as a duplicate of bug 278555 *** Christoph, I will look for the failure at the point you mention above and not file the bug report. Would that be ok? I am running against whatever is "latest" in Joris' repository. I check this daily and rebuild if there are updates. Should I make new bugs for these: I'm also seeing a TON of error messages in the ~/.kde/share/apps/ktorrent/log files to the tune of 30-50 messages per second. Tail -f <log file> just flys through messages. Most of the messages are meaningless, like "<timestamp> Error:" I'm also seeing multiple prompts that mostly say "duplicate torrent, torrent's merged". These messages pile up and seem to require that they be replied to (poke the ok button) in the order they appear. After a while, it's impossible to make the prompt pile disappear. Thanks, George... Hi, I have tried to run valgrind (svn version) on this latest ktorrent-dev and here's what I get: ==16794== Memcheck, a memory error detector ==16794== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==16794== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info ==16794== Command: /usr/bin/ktorrent --nofork ==16794== Parent PID: 16367 ==16794== ==16794== Conditional jump or move depends on uninitialised value(s) ==16794== at 0x33D3338: bt::Downloader::getDownloadedBytesOfCurrentChunksFile(QString const&) (downloader.cpp:670) ==16794== by 0x33F4BC9: bt::TorrentControl::initInternal(bt::QueueManagerInterface*, QString const&, QString const&) (torrentcontrol.cpp:711) ==16794== by 0x33F5378: bt::TorrentControl::init(bt::QueueManagerInterface*, QString const&, QString const&, QString const&) (torrentcontrol.cpp:562) ==16794== by 0x806C245: kt::Core::loadExistingTorrent(QString const&) (core.cpp:718) ==16794== by 0x806D822: kt::Core::loadTorrents() (core.cpp:750) ==16794== by 0x8077C2F: kt::GUI::GUI() (gui.cpp:87) ==16794== by 0x8079875: kt::App::newInstance() (app.cpp:60) ==16794== by 0x2CAFDA0: KUniqueApplication::Private::_k_newInstanceNoFork() (kuniqueapplication.cpp:369) ==16794== by 0x2CAFE14: KUniqueApplication::qt_metacall(QMetaObject::Call, int, void**) (kuniqueapplication.moc:72) ==16794== by 0x749079A: QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) (qmetaobject.cpp:237) ==16794== by 0x749B136: QMetaCallEvent::placeMetaCall(QObject*) (qobject.cpp:535) ==16794== by 0x749F7CE: QObject::event(QEvent*) (qobject.cpp:1217) ==16794== by 0x748A56B: QCoreApplication::event(QEvent*) (qcoreapplication.cpp:1560) ==16794== by 0x2149B9F: QApplication::event(QEvent*) (qapplication.cpp:2503) ==16794== by 0x214758B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4462) ==16794== by 0x214C291: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:3862) ==16794== by 0x8079476: kt::App::notify(QObject*, QEvent*) (app.cpp:99) ==16794== by 0x7489F62: QCoreApplication::notifyInternal(QObject*, QEvent*) (qcoreapplication.cpp:731) ==16794== by 0x748DCB4: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (qcoreapplication.h:215) ==16794== by 0x748DE8D: QCoreApplication::sendPostedEvents(QObject*, int) (qcoreapplication.cpp:1265) ==16794== by 0x74B7B34: postEventSourceDispatch(_GSource*, int (*)(void*), void*) (qcoreapplication.h:220) ==16794== by 0x6D6191: g_main_context_dispatch (gmain.c:2149) ==16794== by 0x6D6977: g_main_context_iterate.clone.5 (gmain.c:2780) ==16794== by 0x6D6C34: g_main_context_iteration (gmain.c:2843) ==16794== by 0x74B7CAC: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:422) ==16794== by 0x21FB205: QGuiEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qguieventdispatcher_glib.cpp:207) ==16794== by 0x74890F9: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:149) ==16794== by 0x74893A9: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:201) ==16794== by 0x748DF56: QCoreApplication::exec() (qcoreapplication.cpp:1008) ==16794== by 0x2145397: QApplication::exec() (qapplication.cpp:3736) ==16794== by 0x8069060: main (main.cpp:177) ==16794== ==16794== ==16794== Valgrind's memory management: out of memory: ==16794== newSuperblock's request for 1048576 bytes failed. ==16794== 2750091264 bytes have already been allocated. ==16794== Valgrind cannot continue. Sorry. ==16794== ==16794== There are several possible reasons for this. ==16794== - You have some kind of memory limit in place. Look at the ==16794== output of 'ulimit -a'. Is there a limit on the size of ==16794== virtual memory or address space? ==16794== - You have run out of swap space. ==16794== - Valgrind has a bug. If you think this is the case or you are ==16794== not sure, please let us know and we'll try to fix it. ==16794== Please note that programs can take substantially more memory than ==16794== normal when running under Valgrind tools, eg. up to twice or ==16794== more, depending on the tool. On a 64-bit machine, Valgrind ==16794== should be able to make use of up 32GB memory. On a 32-bit ==16794== machine, Valgrind should be able to use all the memory available ==16794== to a single process, up to 4GB if that's how you have your ==16794== kernel configured. Most 32-bit Linux setups allow a maximum of ==16794== 3GB per process. ==16794== ==16794== Whatever the reason, Valgrind cannot continue. Sorry. Created attachment 63350 [details]
sanitized output from gdb run from the script command
Hi,
After updating ktorrent on my FC14 system:
rpm -qa | grep ktorrent
libktorrent-debuginfo-1.1.2-1.fc14.i686
ktorrent-debuginfo-4.1.2-1.fc14.i686
libktorrent-1.1.2-1.fc14.i686
ktorrent-libs-4.1.2-1.fc14.i686
kde-plasma-ktorrent-4.1.2-1.fc14.i686
ktorrent-4.1.2-1.fc14.i686
I started the script command and then gdb on ktorrent to see if I could trap this bug. I'm including the script file which shows a segfault.
I have been running ktorrent-dev and happened to quit from that invocation. This produced some interesting log messages that really seem to apply to this bug. This seems to describe EXACTLY what I'm seeing.
tail -20 ktorrent-dev.log
Fri Sep 2 02:24:44 2011: Scrape : leechers = 9, seeders = 5, downloaded = 12
Fri Sep 2 02:24:44 2011: Scrape : leechers = 5, seeders = 9, downloaded = 40
Fri Sep 2 02:24:44 2011: Scrape : leechers = 39, seeders = 84, downloaded = 10997
Fri Sep 2 02:24:44 2011: Scrape : leechers = 44, seeders = 83, downloaded = 13567
Fri Sep 2 02:24:44 2011: Scrape : leechers = 6, seeders = 13, downloaded = 568
Fri Sep 2 02:24:44 2011: Scrape : leechers = 39, seeders = 84, downloaded = 10997
Fri Sep 2 02:24:45 2011: UTP: Connection 16066|16065 closed
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454) KWidgetItemDelegateEventListener::eventFilter: User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!
Fri Sep 2 02:24:45 2011: Qt Debug: ktorrent(6454)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x2057dfa0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
I see lots of shit related to avahi, can you disable the zeroconf plugin ? |