Bug 496620
| Summary: | Dolphin crashes when trying to browse an SMB workgroup or view the properties of / | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Oded Arbel <oded> |
| Component: | strigi | Assignee: | Deji Akingunola <dakingun> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | arbiter, dakingun, jamundso, jreznik, kevin, ltinkl, rdieter, smparrish, than |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 0.6.4-4.fc9 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-07-22 09:37:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Oded Arbel
2009-04-20 12:00:01 UTC
the fedora dolphin package is obsolete, since the dolphin application is now included in kdebase. chitlesh(~)[0]$rpm -qf /usr/bin/dolphin kdebase-4.2.1-2.fc10.i386 I'm reassigning the bug to kdebase uh, thanks. It is in kdebase on my system (4.2.2 on my system, as specified above), but I wasn't sure what to select in the component list. From the backtrace, it looks like this is a bug in the strigi-libs, which are built from the strigi SRPM. *** Bug 496684 has been marked as a duplicate of this bug. *** I can reproduce it. This bug is fixed in trunk, I'll try to prepare backport for 4.2.2. Ok, the patch seems to be working, Deji would you mind if I take care about it (as I'm provenpackager)? I thought strigi is under KDE SIG control... Sorry for my mess here... I comaintain strigi. Feel free to commit the fix. strigi-0.6.4-4.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/strigi-0.6.4-4.fc9 strigi-0.6.4-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/strigi-0.6.4-4.fc10 strigi-0.6.4-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update strigi'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3816 strigi-0.6.4-4.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update strigi'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3840 Will this be available for testing in rawhide (which is what I'm running and where I reported the bug)? yes, it was tagged yesterday, https://fedorahosted.org/rel-eng/ticket/1575 Ok, after the upgrade I can get a list of domains using smb:/, but clicking on a domain I get another crash. Here is the stack trace: ---8<--- Application: Dolphin (dolphin), signal SIGABRT 0x000000333d4a4db1 in nanosleep () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7ff2c813e820 (LWP 2166))] Thread 1 (Thread 0x7ff2c813e820 (LWP 2166)): [KCrash Handler] #5 0x000000333d4334f5 in raise () from /lib64/libc.so.6 #6 0x000000333d434d6a in abort () from /lib64/libc.so.6 #7 0x000000333d42c33a in __assert_fail () from /lib64/libc.so.6 #8 0x00007ff2c862d05c in Strigi::AnalysisResult::Private::Private(std::string const&, long, Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::string const&, Strigi::AnalysisResult&) () from /usr/lib64/libstreamanalyzer.so.0 #9 0x00007ff2c862d1ef in Strigi::AnalysisResult::AnalysisResult(std::string const&, long, Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::string const&) () from /usr/lib64/libstreamanalyzer.so.0 #10 0x00007ff2c9b56f42 in ?? () from /usr/lib64/libkio.so.5 #11 0x00007ff2c9b5859a in KFileMetaInfo::KFileMetaInfo(KUrl const&) () from /usr/lib64/libkio.so.5 #12 0x00007ff2c9b4827c in KFileItem::metaInfo(bool, int) const () from /usr/lib64/libkio.so.5 #13 0x00007ff2c9b4b1c1 in KFileItem::getToolTipText(int) const () from /usr/lib64/libkio.so.5 #14 0x0000003933a50d6c in ?? () from /usr/lib64/libdolphinprivate.so.4 #15 0x0000003933a51014 in ?? () from /usr/lib64/libdolphinprivate.so.4 #16 0x0000003345158612 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQtCore.so.4 #17 0x0000003345152353 in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4 #18 0x000000334658deac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #19 0x00000033465954de in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #20 0x00007ff2c8ef0146 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5 #21 0x0000003345142b7c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4 #22 0x000000334516e562 in ?? () from /usr/lib64/libQtCore.so.4 #23 0x000000334516c05d in ?? () from /usr/lib64/libQtCore.so.4 #24 0x000000333e83818e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #25 0x000000333e83b8e8 in ?? () from /lib64/libglib-2.0.so.0 #26 0x000000333e83ba5c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #27 0x000000334516bfa6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #28 0x00000033466220de in ?? () from /usr/lib64/libQtGui.so.4 #29 0x0000003345141452 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #30 0x0000003345141824 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #31 0x0000003345143919 in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #32 0x000000000043fb95 in _start () ---8<-- Sorry, that is the same problem as the original - I can't browse a workgroup. I have strigi 0.6.4-4 installed and I still get a crash (the above stack trace). And can you view properties of /? I can't reproduce it anymore. Are you sure you upgraded strigi-libs, not just the main package? Yes, I upgraded strigi-libs: ---8<--- $ rpm -qa strigi* strigi-libs-0.6.4-4.fc11.i586 strigi-libs-0.6.4-4.fc11.x86_64 ---8<--- And yes, I can do "properties" on /, and it works fine - so its likely not the same issue. Still, I have an update - it seems that I can go into a workgroup/domain and see the computers there, but after a few seconds (in which I have time to mouse over some computers) I get a crash again - here is the stack trace (which looks to me exactly like the previous ones): ---8<--- Application: Dolphin (dolphin), signal SIGABRT 0x000000333d4a4db1 in nanosleep () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7f44d7a37820 (LWP 23274))] Thread 2 (Thread 0x7f44ce167910 (LWP 23285)): #0 0x000000333d4d8d02 in select () from /lib64/libc.so.6 #1 0x0000003345121691 in ?? () from /usr/lib64/libQtCore.so.4 #2 0x000000334505a221 in ?? () from /usr/lib64/libQtCore.so.4 #3 0x000000333e00687a in start_thread () from /lib64/libpthread.so.0 #4 0x000000333d4e014d in clone () from /lib64/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f44d7a37820 (LWP 23274)): [KCrash Handler] #5 0x000000333d4334f5 in raise () from /lib64/libc.so.6 #6 0x000000333d434d6a in abort () from /lib64/libc.so.6 #7 0x000000333d42c33a in __assert_fail () from /lib64/libc.so.6 #8 0x00007f44d7f2605c in Strigi::AnalysisResult::Private::Private(std::string const&, long, Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::string const&, Strigi::AnalysisResult&) () from /usr/lib64/libstreamanalyzer.so.0 #9 0x00007f44d7f261ef in Strigi::AnalysisResult::AnalysisResult(std::string const&, long, Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::string const&) () from /usr/lib64/libstreamanalyzer.so.0 #10 0x00007f44d944ff42 in ?? () from /usr/lib64/libkio.so.5 #11 0x00007f44d945159a in KFileMetaInfo::KFileMetaInfo(KUrl const&) () from /usr/lib64/libkio.so.5 #12 0x00007f44d944127c in KFileItem::metaInfo(bool, int) const () from /usr/lib64/libkio.so.5 #13 0x00007f44d94441c1 in KFileItem::getToolTipText(int) const () from /usr/lib64/libkio.so.5 #14 0x0000003933a50d6c in ?? () from /usr/lib64/libdolphinprivate.so.4 #15 0x0000003933a51014 in ?? () from /usr/lib64/libdolphinprivate.so.4 #16 0x0000003345158612 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQtCore.so.4 #17 0x0000003345152353 in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4 #18 0x000000334658deac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #19 0x00000033465954de in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #20 0x00007f44d87e9146 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5 #21 0x0000003345142b7c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4 #22 0x000000334516e562 in ?? () from /usr/lib64/libQtCore.so.4 #23 0x000000334516c05d in ?? () from /usr/lib64/libQtCore.so.4 #24 0x000000333e83818e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #25 0x000000333e83b8e8 in ?? () from /lib64/libglib-2.0.so.0 #26 0x000000333e83ba5c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #27 0x000000334516bfa6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #28 0x00000033466220de in ?? () from /usr/lib64/libQtGui.so.4 #29 0x0000003345141452 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #30 0x0000003345141824 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #31 0x0000003345143919 in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #32 0x000000000043fb95 in _start () ---8<--- Also, ever since the upgrade, whenever I go to smb:/ , it takes about 10 seconds for Dolphin to show the list of workgroups, during which time the browser window is empty and the status bar shows the info from the previous view. strigi-0.6.4-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. strigi-0.6.4-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. Why is this marked closed ? I still get this crash with the latest updates. Here is a stack trace of a crash I received just now when trying to browse a workgroup: Application: Dolphin (dolphin), signal SIGABRT 0x0000003a9d6a5151 in nanosleep () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7fc61ba79820 (LWP 4781))] Thread 1 (Thread 0x7fc61ba79820 (LWP 4781)): [KCrash Handler] #5 0x0000003a9d6336c5 in raise () from /lib64/libc.so.6 #6 0x0000003a9d634f3a in abort () from /lib64/libc.so.6 #7 0x0000003a9d62c50a in __assert_fail () from /lib64/libc.so.6 #8 0x0000003ded21805c in Strigi::AnalysisResult::Private::Private(std::string const&, long, Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::string const&, Strigi::AnalysisResult&) () from /usr/lib64/libstreamanalyzer.so.0 #9 0x0000003ded2181ef in Strigi::AnalysisResult::AnalysisResult(std::string const&, long, Strigi::IndexWriter&, Strigi::StreamAnalyzer&, std::string const&) () from /usr/lib64/libstreamanalyzer.so.0 #10 0x0000003dec935a22 in ?? () from /usr/lib64/libkio.so.5 #11 0x0000003dec937034 in KFileMetaInfo::KFileMetaInfo(KUrl const&) () from /usr/lib64/libkio.so.5 #12 0x0000003dec926dcc in KFileItem::metaInfo(bool, int) const () from /usr/lib64/libkio.so.5 #13 0x0000003dec929d11 in KFileItem::getToolTipText(int) const () from /usr/lib64/libkio.so.5 #14 0x0000003ded650d6c in ?? () from /usr/lib64/libdolphinprivate.so.4 #15 0x0000003ded651014 in ?? () from /usr/lib64/libdolphinprivate.so.4 #16 0x0000003de8f58612 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQtCore.so.4 #17 0x0000003de8f52353 in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4 #18 0x0000003deaf8deac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #19 0x0000003deaf954de in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #20 0x0000003debc05c66 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5 #21 0x0000003de8f42b7c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4 #22 0x0000003de8f6e562 in ?? () from /usr/lib64/libQtCore.so.4 #23 0x0000003de8f6c05d in ?? () from /usr/lib64/libQtCore.so.4 #24 0x0000003a9fe3818e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #25 0x0000003a9fe3b8e8 in ?? () from /lib64/libglib-2.0.so.0 #26 0x0000003a9fe3ba5c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #27 0x0000003de8f6bfa6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #28 0x0000003deb0220de in ?? () from /usr/lib64/libQtGui.so.4 #29 0x0000003de8f41452 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #30 0x0000003de8f41824 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #31 0x0000003de8f43919 in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #32 0x000000000043fb95 in _start () Because we pushed the update and so Bodhi autoclosed the bug. The crash with the properties of / IS fixed, but it looks like the SMB stuff still triggers an assert. As Kevin said - it was autoclosed... It fixed one part of this issue but I can't reproduce it while browsing SMB shares. I'll try to recheck upstream bugzilla. Could you provide your SMB shares to see if there's some crippled share name or etc. Ok, update - I can actually browse SMB workgroups, see computers, shares directories and even files - as long as I don't hover the mouse over a workgroup or a computer for too long. If I put the mouse on a workgroup or a computer in a workgroup for some length of time (not sure how much - less then a second, but probably more then half a second) then I get the crash. All of the workgroup I have access to and all the computers listed under them that I bothered to check with exhibit this phenomena (I can see several dozens computers on my network, so naturally I didn't test all of them). I can show share lists using 'smbclient -L //server/' for some of them if you wish and think it is relevant, but I'm not sure how I can simulate accessing a workgroup with the command line. jreznik, based on the previous comment can you now reproduce this? This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Ping? Any updates?
--
Steven M. Parrish - KDE Triage Master
- PackageKit Triager
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
As I can't reproduce it, I can't unfortunately help. We can try to ping upstream. Apparently with current kdebase-4.2.4-2.fc11.x86_64 I cannot reproduce the crash either, so I'm closing this. Thanks to anyone who invested time and effort :-) |