Bug 162857 - plasma crash after trying to open .kilepr file from konqueror
Summary: plasma crash after trying to open .kilepr file from konqueror
Status: RESOLVED WORKSFORME
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-30 07:03 UTC by kate.g.gordon
Modified: 2008-06-04 03:06 UTC (History)
0 users

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 kate.g.gordon 2008-05-30 07:03:26 UTC
Version:            (using KDE 4.0.3)
Installed from:    Ubuntu Packages
OS:                Linux

From within konqueror, I clicked on file "filename.kilepr" (a Kile project file) to open it, and then plasma crashed.  In retrospect it was stupid to try and open it that way anyway -- I hadn't set up a file association in konqueror, although it seems like I can't.  

N.B. Don't know if it's related, but KDEInit seems to have baulk at files anyway, especially if the associated application is already open (I nearly always get at least one message telling me that KDEInit can't open the application, even as I start reading/writing the file from within the application it's talking about), but that's a separate issue.

I don't seem to have a lot of debugging installed, but here's the crashlog:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb6368940 (LWP 5590)]
[New Thread 0xad984b90 (LWP 8098)]
[New Thread 0xb494db90 (LWP 5592)]
(no debugging symbols found)
/* 203 lines of "(no debugging symbols found)" */
0xb7f80410 in __kernel_vsyscall ()
[Current thread is 0 (LWP 5590)]

Thread 3 (Thread 0xb494db90 (LWP 5592)):
#0  0xb7f80410 in __kernel_vsyscall ()
#1  0xb7b49aa5 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7ef0cdd in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7b99924 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#4  0xb4d7e5b4 in ?? ()
   from /usr/lib/kde4/lib/kde4/plasma_containment_desktop.so
#5  0x0812ff34 in ?? ()
#6  0x0812ff30 in ?? ()
#7  0xffffffff in ?? ()
#8  0x00000000 in ?? ()

Thread 2 (Thread 0xad984b90 (LWP 8098)):
#0  0xb7f80410 in __kernel_vsyscall ()
#1  0xb7b49dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7ef0d34 in pthread_cond_timedwait () from /lib/tls/i686/cmov/libc.so.6
#3  0xb3e9cbbb in ?? () from /usr/lib/libxine.so.1
#4  0x0856f580 in ?? ()
#5  0x0856f568 in ?? ()
#6  0xad98433c in ?? ()
#7  0x0856f580 in ?? ()
#8  0xad98433c in ?? ()
#9  0x0856f568 in ?? ()
#10 0xad984344 in ?? ()
#11 0x483f77fa in ?? ()
#12 0x36516540 in ?? ()
#13 0x483f77f5 in ?? ()
#14 0x000de7c8 in ?? ()
#15 0xb7b54ff4 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#16 0x00000000 in ?? ()

Thread 1 (Thread 0xb6368940 (LWP 5590)):
#0  0xb7f80410 in __kernel_vsyscall ()
#1  0xb7ea2cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7ea2ac7 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0xb78887d0 in ?? () from /usr/lib/kde4/lib/libkdeui.so.5
#4  0x00000001 in ?? ()
#5  0x00000000 in ?? ()
#0  0xb7f80410 in __kernel_vsyscall ()

HTH
Comment 1 Sebastian Sauer 2008-06-03 19:19:09 UTC
Can you please try to provide a useful backtrace like explained on http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports ? Thanks in advance :)
Comment 2 kate.g.gordon 2008-06-04 01:20:06 UTC
Unfortunately I can't reproduce this crash -- my apologies.  I'm better prepared to report any other crashes though; thanks :)
Comment 3 Sebastian Sauer 2008-06-04 03:06:06 UTC
Then let's mark the report as worksforme since without proper backtrace it's not easy if not near to impossible to find the reason for it. Anyway, thanks for your feedback kate! and please feel free to reopen the report if you run again into at (hopefully this time with a nice backtrace we are able to use to solve the issue, thx :)