| Summary: | crash after enabling desktop effects | ||
|---|---|---|---|
| Product: | [Plasma] Oxygen | Reporter: | Olaf Bonorden <olaf> |
| Component: | win deco | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | hugo.pereira.da.costa, kwin-bugs-null |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Olaf Bonorden
2012-01-13 11:48:54 UTC
Looks like serious memory corruption, and from Qt. The crash is inside Qt, trying to access the ::isNull method on a 0x0 Pixmap. #6 isNull (this=0xf0) at image/qpixmapdata_p.h:131 #7 QPixmap::isNull (this=<optimized out>) at image/qpixmap.cpp:579 Now, the upstream code in oxygentileset from: #10 Oxygen::TileSet::render (this=0x9043d0, r=<optimized out>, p=<optimized out>, t=...) only deals with reference to Pixmaps, and not pointers and thus has no way to pass a 0x0 QPixmap* to Qt. So the pixmap must be lost along the way, outside of oxygen. Oh and naturally I can't reproduce (here with Qt 4.8.0, nor with Qt 4.7), using kde from sources ... Nothing I can do about it :( Lets wait and see if others have similar issue. Question: the crash does _not_ happen if you don't enable desktop effects ? Question 2: graphics card and driver ? - no crash if desktop effects are disabled - crash immediately if desktop effects are enabled and I click on a window in the background - no difference if I change style (e.g., from oxygen to Air) - graphics card: NV43GL [Quadro FX 550] - driver: nvida 285.05.09 - kernel 3.2 The null pointer doesn't refer the QPixmap but it's internal QPixmapData. I recall that this is a dupe (i think) - i think we've the same bug with the same trace around. (it must be *somewhere* in bugzilla) It's possibly because of the raster graphicssystem and QPixmap sn't backed by a Pixmap / Picture @Olaf please run "kwin --graphicssystem native --replace &" instead and check whether the issue still occurs @Olaf "no difference if I change style (e.g., from oxygen to Air)" You mean "desktop theme" ? Or actually "window decoration" style ? (I don't know about an "air" window decoration, but ...) (In reply to comment #4) > please run "kwin --graphicssystem native --replace &" instead and check whether > the issue still occurs same crash. (In reply to comment #5) > "no difference if I change style (e.g., from oxygen to Air)" > You mean "desktop theme" ? Or actually "window decoration" style ? > (I don't know about an "air" window decoration, but ...) I've tried to change a) window decoration theme b) style of applications because both are using a style called oxygen. I see no difference - but I have not tried to change a and b at the same time. It cannot be the *same* crash since it's not the same decoration, the entrance vector MUST differ.
Please
- try the "KDE2" decoration (kcmshell4 kwindecoration) and
- the "palstique" Qt style.
- Restart kwin ("kwin --graphicssystem native --replace &") from konsole
- post the output and ultimately
- the backtrace from the crash that occurs with this setup (iff it does so)
- no crash for KDE2 window decorations (or some others) - crash for oxygen In my first try I changed the desktop style instead of the window decoration, sorry. Workaround for me: do not use oxygen window declaration, that helps a lot, thank you for your fast responses! @Hugo
do you possibly hand out a local var as reference, ie code like
QPixmap &stuff() {
QPixmap pix;
doSome(pix);
return pix;
}
nope. Actually, won't the compiler complain about such construct ? (warning: returning reference to a temporary) shouldn't one get a warning? "warning: reference to local variable '...' returned"? Ok, no one is looking for warnings... I played with -Werror=... but it looks like there is no switch for enabling that warning :-(, it is enabled by default, thus one cannot create an error using -Werror=... I actually am looking at warnings at compile time. And there are none (at least with my compiler version) for the whole oxygen code. Yes, a warning there would be.
No, most ppl. don't look at them ;-)
ok, the crashy code in qpixmap.cpp is
bool QPixmap::isNull() const
{
return !data || data->isNull();
}
since data apparently *is* NULL (so says the trace) "data->isNull();" should never be touched anyway => the stack is junk.
@Olaf
I start to suspect that the plugin or oxygen library is "the wrong one", ie. your stable copy (is there?) of (most likely the plugin) it shadows the intended (RC2) one, causing an ABI gap.
-> "lsof | grep -i oxygen" - esp look for kwin3_oxygen
kwin loads: /usr/lib64/kde4/kwin3_oxygen /usr/lib64/liboxygenstyle.so.4.8.0 /usr/lib64/kde4/plugins/styles/oxygen.so kwin3_oxygen is part of the package kwin-4.7.97, the other libs are part of kdebase4-workspace-liboxygenstyle-4.7.97. Thanks, and yes libraries looks ok. What about qt ? Do you only have Qt4.8.0 installed ? Indeed with the code pointed to by Thomas, the crash you experience should definitly _not_ happen. Meaning that there is something broken (in your system) with library symbols. I've installed the source and attached a debugger.
#0 QPixmap::isNull (this=<optimized out>) at image/qpixmap.cpp:579
579 return !data || data->isNull();
Look into registers & asm code shows: this is not null, but data is 240 => crash
Question: Why is the pixmap corrupted?
#1 0x00007ffe5643158a in QPainter::drawPixmap (this=0x7fff3d366ff0, r=..., pm=..., sr=...)
at painting/qpainter.cpp:5407
5407 if (!d->engine || pm.isNull())
If I print pm here:
(gdb) p pm
$3 = (QPaintDevice &) @0x4643870: {
_vptr.QPaintDevice = 0x7ffe56da4990,
painters = 0
}
(gdb) x 0x7ffe56da4990
0x7ffe56da4990 <_ZTV12QPaintDevice+16>: 0x56417ba0
pm is not a QPixmap anymore, it is an instance of it's base class, looks like ~QPixmap has been already run.
So let's look where pm comes from.
#3 Oxygen::TileSet::render (this=0xff0500, r=<optimized out>, p=<optimized out>, t=...)
at /usr/src/debug/kde-workspace-4.7.97/libs/oxygen/oxygentileset.cpp:157
157 if( bits(t, Bottom|Right) ) p->drawPixmap(x2, y2, _pixmaps.at(8), _w3-wRight, _h3-hBottom, wRight, hBottom );
_pixmaps is a QVector of QPixmaps... or at least should be.
(gdb) p & ((QPixmap*) &_pixmaps.p[1])[7]
$24 = (QPaintDevice *) 0x4643870
which is the same address as this in frame 0 (register rdi). All other entries of the vector I checked are also no valid QPixmaps but detected as QPaintDevices.
Maybe the whole vector is already destroyed? The tileset that contains the vector comes from a shadowCache() one frame above.
Is the cache in memory? or are there any outdated cache files on my disk?
whoa. Thanks a lot for all the debug hunting. The cache in question is only in memory and not saved on disk. (its a QCache). So no need for you to delete any "file". Then, well, the purpose of the cache is that it gets re-filled automatically, whenever its being cleared. (meaning: there is no mecanism by Qt that you can access and entry in the cache that has been cleared). Something "else" is deleting the pixmaps, without notifying the cache (and removing the corresponding entry): There is no explicit qpixmap deletion in the code - just double checked); Nor are there any explicit deletion of the parent class (Oxygen::TileSet), since this should be dealt with by the QCache, e.g. QCache::clear ); nor are there pointers to TileSet that are kept around, and could be invalidated before use, due to a cache clear. So that I am a lost :( sth. like Foo *bar = QCache<int, Foo>::object(i); QCache<int, Foo>::insert(i, Foo(p)); // floods cache, cache kicks oldest object, being "bar" bar->crashMe(); i.e *any* "insert" has the pot. to invalidate *any* cache pointer, therefore the above calling order is dangerous to wrong Try raising the maxCost (INT_MAX ;-) or inserting with no costs at all (0 ;-) @Thomas Agreed. I dont 'think' I do that (being aware of the issue you mention), though I will double check cause it might be well hidden. ... nope. Only place where shadowcache is actually used (in the decoration code) is:
kwin/clients/oxygen/oxygenclient.cpp l1507 or so:
if( configuration().useOxygenShadows() && glowIsAnimated() && !isForcedActive() )
{
tileSet = shadowCache().tileSet( key, glowIntensity() );
} else {
tileSet = shadowCache().tileSet( key );
}
tileSet->render( frame, &painter, TileSet::Ring);
Sounds pretty safe to me.
For the record, place where maxCost is set is in kde-workspace/libs/oxygen/oxygenshadowcache.h l58. Places where cache objects are inserted is: kde-workspace/libs/oxygen/oxygenshadowcache.cpp l136 and l184 (in case Olaf wants to try one of Thomas suggestions). Here, I can't really help, since I can't reproduce. Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |