Bug 255268 - Dragon player crashed after opening a downloaded mov file
Summary: Dragon player crashed after opening a downloaded mov file
Status: RESOLVED UPSTREAM
Alias: None
Product: dragonplayer
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-26 00:01 UTC by makd
Modified: 2011-11-21 17:44 UTC (History)
4 users (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 makd 2010-10-26 00:01:29 UTC
Application: dragon (2.0)
KDE Platform Version: 4.4.2 (KDE 4.4.2)
Qt Version: 4.6.2
Operating System: Linux 2.6.32-21-generic i686
Distribution: Ubuntu 10.04 LTS

-- Information about the crash:
I haven't tried to start dragon player over as yet. I was trying to open an mov file from frostbite downloads, then the application crashed.

 -- Backtrace:
Application: Dragon Player (dragon), signal: Aborted
[Current thread is 1 (Thread 0xb785a710 (LWP 1965))]

Thread 10 (Thread 0xb567ab70 (LWP 1967)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x00840342 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x006d5a34 in pthread_cond_timedwait () from /lib/tls/i686/cmov/libc.so.6
#3  0x00198ce7 in ?? () from /usr/lib/libxine.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 9 (Thread 0xb4a6eb70 (LWP 1968)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x006c1971 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x001c25cc in xine_usec_sleep () from /usr/lib/libxine.so.1
#3  0x00000000 in ?? ()

Thread 8 (Thread 0xb426db70 (LWP 1969)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x006d5d33 in ?? () from /lib/tls/i686/cmov/libc.so.6
#2  0x0066c697 in ?? () from /lib/tls/i686/cmov/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 7 (Thread 0xafa6bb70 (LWP 1975)):
#0  0x006d5d9f in ?? () from /lib/tls/i686/cmov/libc.so.6
#1  0x006b8e34 in read () from /lib/tls/i686/cmov/libc.so.6
#2  0x02f6dde2 in ?? () from /usr/lib/libasound.so.2
#3  0x02f6ab8d in snd_ctl_read () from /usr/lib/libasound.so.2
#4  0x02f66f4f in snd_hctl_handle_events () from /usr/lib/libasound.so.2
#5  0x02f72dc1 in snd_mixer_handle_events () from /usr/lib/libasound.so.2
#6  0x061a5ad8 in ?? () from /usr/lib/xine/plugins/1.27/xineplug_ao_out_alsa.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 6 (Thread 0xaf26ab70 (LWP 1976)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x00840015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x006d59dd in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0x001a99ee in ?? () from /usr/lib/libxine.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 0xaea69b70 (LWP 1977)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x006d5d33 in ?? () from /lib/tls/i686/cmov/libc.so.6
#2  0x0066c697 in ?? () from /lib/tls/i686/cmov/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xb346cb70 (LWP 1978)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x00840015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x006d59dd in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0x0019c2aa in ?? () from /usr/lib/libxine.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 0xb2c6bb70 (LWP 1979)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x00840015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x006d59dd in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0x001ac9da in ?? () from /usr/lib/libxine.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 0xb1f5cb70 (LWP 1980)):
#0  0x007b5422 in __kernel_vsyscall ()
#1  0x006c1971 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x001c25cc in xine_usec_sleep () from /usr/lib/libxine.so.1
#3  0x00000000 in ?? ()

Thread 1 (Thread 0xb785a710 (LWP 1965)):
[KCrash Handler]
#6  0x007b5422 in __kernel_vsyscall ()
#7  0x00625651 in raise () from /lib/tls/i686/cmov/libc.so.6
#8  0x00628a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#9  0x0065c49d in ?? () from /lib/tls/i686/cmov/libc.so.6
#10 0x00666591 in ?? () from /lib/tls/i686/cmov/libc.so.6
#11 0x00669710 in ?? () from /lib/tls/i686/cmov/libc.so.6
#12 0x0066af9c in malloc () from /lib/tls/i686/cmov/libc.so.6
#13 0x03ec9e15 in ?? () from /usr/lib/libxcb.so.1
#14 0x03ec7dfb in ?? () from /usr/lib/libxcb.so.1
#15 0x03ec99b2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#16 0x0777af96 in _XReply (dpy=0x933e160, rep=0xbf8e2480, extra=0, discard=1) at ../../src/xcb_io.c:461
#17 0x07758729 in XGetSelectionOwner (dpy=0x933e160, selection=305) at ../../src/GetSOwner.c:43
#18 0x00c6fc21 in KWindowSystem::compositingActive () at ../../kdeui/windowmanagement/kwindowsystem_x11.cpp:761
#19 0x0488d9c5 in OxygenStyle::compositingActive (this=0x947a9b8, obj=0x9be7230, ev=0xbf8e2c50) at ../../../kstyles/oxygen/oxygen.cpp:6502
#20 OxygenStyle::eventFilter (this=0x947a9b8, obj=0x9be7230, ev=0xbf8e2c50) at ../../../kstyles/oxygen/oxygen.cpp:6133
#21 0x010accda in QCoreApplicationPrivate::sendThroughObjectEventFilters (this=0x932a478, receiver=0x9be7230, event=0xbf8e2c50) at kernel/qcoreapplication.cpp:819
#22 0x0332d4b9 in QApplicationPrivate::notify_helper (this=0x932a478, receiver=0x9be7230, e=0xbf8e2c50) at kernel/qapplication.cpp:4296
#23 0x033340f9 in QApplication::notify (this=0xbf8e2de4, receiver=0x9be7230, e=0xbf8e2c50) at kernel/qapplication.cpp:4265
#24 0x00b11f2a in KApplication::notify (this=0xbf8e2de4, receiver=0x9be7230, event=0xbf8e2c50) at ../../kdeui/kernel/kapplication.cpp:302
#25 0x010ada3b in QCoreApplication::notifyInternal (this=0xbf8e2de4, receiver=0x9be7230, event=0xbf8e2c50) at kernel/qcoreapplication.cpp:704
#26 0x033914a5 in QCoreApplication::sendEvent (this=0x9bda920) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#27 QWidgetPrivate::show_helper (this=0x9bda920) at kernel/qwidget.cpp:7196
#28 0x033916c3 in QWidgetPrivate::show_recursive (this=0x9bda920) at kernel/qwidget.cpp:7067
#29 0x033917bc in QWidgetPrivate::showChildren (this=0x948a3d8, spontaneous=false) at kernel/qwidget.cpp:7504
#30 0x033913a1 in QWidgetPrivate::show_helper (this=0x948a3d8) at kernel/qwidget.cpp:7143
#31 0x0339399b in QWidget::setVisible (this=0x9488220, visible=true) at kernel/qwidget.cpp:7418
#32 0x0806788b in QWidget::show (argc=2, argv=0xbf8e2f54) at /usr/include/qt4/QtGui/qwidget.h:485
#33 main (argc=2, argv=0xbf8e2f54) at ../../../../dragonplayer/src/app/main.cpp:56

Reported using DrKonqi
Comment 1 Aakash 2011-11-21 16:53:43 UTC
The bug is not specific and is not occurring in the current version. Please remove the bug.
Comment 2 Thomas Lübking 2011-11-21 17:06:13 UTC
I recall there actually was an issue in that query but I think that Hugo fixed it some time ago.
Comment 3 Hugo Pereira Da Costa 2011-11-21 17:10:38 UTC
yes. Or rather, Oxygen::compositingActive does not call KWindowsSystem::compositing active anymore, which was crashing when called too early (because of other stuff it would initialize at the same time).

We call XGetSelectionOwner now (as does bespin ;)) and it should be safe.

So closing.
Comment 4 Hugo Pereira Da Costa 2011-11-21 17:12:25 UTC
mmmm. reopening.
In fact, XGetSelectionOwner is what causes the crash :)
But then it is likely an upstream bug (which I can't reproduce anyway)
Comment 5 Thomas Lübking 2011-11-21 17:23:55 UTC
The problem is this line:
0x0066af9c in malloc () from /lib/tls/i686/cmov/libc.so.6
translates "memory corruption" - so either there's one cause by the oxygen style OR that particular xlib/xorg is broken - X11 calls are not supposed to crash (even if you pass them the latest junk) so *in case* oxygen isn't the dirty child for sure, it's clearly upstream.

By my impression i'd blame Xorg, resp. xcb since the crash is deep down and iff oxygen would pollute memory, you'd likely get "weird" crashes all over the place.
Comment 6 Hugo Pereira Da Costa 2011-11-21 17:44:00 UTC
Besides, last time (and every time) I checked oxygen with valgrind, there really was no leaking nor invalid memory read/write. So closing (for good)