Summary: | Dragon player crashed after opening a downloaded mov file | ||
---|---|---|---|
Product: | [Applications] dragonplayer | Reporter: | makd <tommytwotone> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED UPSTREAM | ||
Severity: | crash | CC: | aakashrajdahal, hugo.pereira.da.costa, hugo, kwin-bugs-null |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
makd
2010-10-26 00:01:29 UTC
The bug is not specific and is not occurring in the current version. Please remove the bug. I recall there actually was an issue in that query but I think that Hugo fixed it some time ago. 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. mmmm. reopening. In fact, XGetSelectionOwner is what causes the crash :) But then it is likely an upstream bug (which I can't reproduce anyway) 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. 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) |