compiz-0.7.8-18.fc11.x86_64 xorg-x11-drv-intel-2.7.0-7.fc11.x86_64 I get regular core dumps with compiz. The backtrace looks like: Core was generated by `compiz --ignore-desktop-hints glib gconf'. Program terminated with signal 11, Segmentation fault. #0 strcmp () at ../sysdeps/x86_64/strcmp.S:29 29 L(oop): movb (%rdi), %al (gdb) backtrace #0 strcmp () at ../sysdeps/x86_64/strcmp.S:29 #1 0x00000000004146a0 in otherScreenGrabExist (s=0x1484a90) at screen.c:2817 #2 0x00007fee59e79537 in rotate (d=0x1410470, option=0x7fff21b6fe70, state=<value optimized out>, action=<value optimized out>, nOption=<value optimized out>) at rotate.c:726 #3 0x00007fee59e7a63b in rotateRight (d=0x1410470, action=<value optimized out>, state=<value optimized out>, option=0x7fff21b70020, nOption=8) at rotate.c:915 #4 0x0000000000422090 in triggerKeyPressBindings ( argument=<value optimized out>, event=<value optimized out>, nOption=38, option=0x1576668, d=<value optimized out>, nArgument=<value optimized out>) at event.c:422 #5 handleActionEvent (argument=<value optimized out>, event=<value optimized out>, nOption=38, option=0x1576668, d=<value optimized out>, nArgument=<value optimized out>) at event.c:915 #6 handleEvent (argument=<value optimized out>, event=<value optimized out>, nOption=38, option=0x1576668, d=<value optimized out>, nArgument=<value optimized out>) at event.c:1247 #7 0x00007fee5c10c0c5 in glibHandleEvent (d=0x1410470, event=0x7fee5945c4c5) at glib.c:185 #8 0x00007fee5b0ab0a2 in videoHandleEvent (d=0x1410470, event=0x7fff21b71050) at video.c:973 #9 0x00007fee5aea73c5 in shotHandleEvent (d=0x1410470, event=0x7fff21b71050) at screenshot.c:395 #10 0x00007fee5aca311b in decorHandleEvent (d=0x1410470, event=0x7fff21b71050) at decoration.c:1014 #11 0x00007fee5aa9d219 in wobblyHandleEvent (d=0x1410470, event=0x7fff21b71050) at wobbly.c:2158 #12 0x00007fee5a895773 in cloneHandleEvent (d=0x1410470, event=0x7fff21b71050) at clone.c:643 #13 0x00007fee5a48c4e4 in fadeHandleEvent (d=0x1410470, event=0x7fff21b71050) at fade.c:606 #14 0x00007fee5a288c7b in minHandleEvent (d=0x1410470, event=0x7fff21b71050) at minimize.c:659 #15 0x00007fee59e7a0de in rotateHandleEvent (d=0x1410470, event=0x7fff21b71050) at rotate.c:1571 #16 0x00007fee59c72f05 in zoomHandleEvent (d=0x1410470, event=0x7fff21b71050) at zoom.c:918 #17 0x00007fee59a6eb44 in moveHandleEvent (d=0x1410470, event=0x7fff21b71050) at move.c:747 #18 0x00007fee59869fdf in resizeHandleEvent (d=0x1410470, event=0x7fff21b71050) at resize.c:983 #19 0x00007fee59663d46 in switchHandleEvent (d=0x7fff00000000, event=0x7fee5945c4c5) at switcher.c:1092 #20 0x00007fee5945bd0b in scaleHandleEvent (d=0x1410470, event=0x7fff21b71050) at scale.c:1807 #21 0x000000000041085f in eventLoop () at display.c:1559 #22 0x000000000040bc4b in main (argc=2, argv=0x7fff21b711a0) at main.c:446 Current language: auto; currently asm (gdb)
I get almost the same backtrace when I hit a "wrong" keyboard combo. One difference between the reported backtrace here and my, is that the rotateRight(...) function is rotateLeft(...) in my trace. On CTRL + ALT + Arrow Down I trigger the Expo wall feature. And CTRL + ALT + Arrow left/right rotates the cube. If I trigger the Expo wall and then try to rotate the cube via keyboard short cuts, it crashes - always. So it's probably a conflict between the rotate cube and the expo compiz plug-ins. After digging into this .... (gdb) Continuing. Breakpoint 1, otherScreenGrabExist (s=0x1c40710) at screen.c:2820 2820 if( s && s->grabs[i].name 2: name = 0x7fec00000000 <Address 0x7fec00000000 out of bounds> 1: s->grabs[i] = {active = 1, cursor = 0, name = 0x7fec3da6b21d "expo"} (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. strcmp () at ../sysdeps/x86_64/strcmp.S:29 29 L(oop): movb (%rdi), %al Current language: auto; currently asm (gdb) So it seems like the char *name pointer suddenly points to a place it should not point at. From the man page of va_arg(): If there is no next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), random errors will occur. So a very different implementation is needed in this section and not just loop va_arg() until you get a hit. And you cannot trust that the result of va_arg() is NULL, or else the loop would work as expected.
Sorry for the unclear message, it would need a bit better explanation. This is the function which fails. I added an extra check to be sure *s is not NULL, because I initially suspected the s->grab[i].name to be NULL. But that was not the case, it was the char *name which was a stray pointer. -------------------------------------------------------------------------------- Bool otherScreenGrabExist (CompScreen *s, ...) { va_list ap; char *name; int i; for (i = 0; i < s->maxGrab; i++) { if (s->grabs[i].active) { va_start (ap, s); name = va_arg (ap, char *); while (name) /* this check is useless, as va_arg() do not return NULL on failure nor on end-of-list */ { if( s && s->grabs[i].name && strcmp (name, s->grabs[i].name) == 0) break; name = va_arg (ap, char *); } va_end (ap); if (!name) return TRUE; } } return FALSE; } --------------------------------------------------------------------------------
Recompiling compiz related packages from F12 to F11 solved the issue. I downloaded compiz-0.8.2-10.fc12.src.rpm, compiz-bcop-0.8.2-2.fc12.src.rpm, compiz-fusion-0.8.2-4.fc12.src.rpm from Koji and installed the recompiled packages without any issues. The crash seems to have disappeared. According to upstream developers, this might have been caused due to a stack smashing bug somewhere in Compiz, which has been fixed in later versions.
*** Bug 517562 has been marked as a duplicate of this bug. ***
This bug has been triaged. So, as stated in the bug triager workflow: " If the bug can be reproduced in the same Fedora release as the reporter, but not in later releases despite trying, this is strong evidence that the bug has already been fixed. Offer the reporter the option of upgrading to a newer release (or waiting until the next release if it is only fixed in Rawhide). The bug should stay open; you can add a comment leaving it up to the package maintainer whether or not they wish to backport a fix. If not, they will close the bug. If there is consensus to close the bug, it should be marked as CLOSED/CURRENTRELASE, CLOSED/RAWHIDE, or CLOSED/NEXTRELEASE as appropriate. " So in our case, as reported by david, compiz-0.8.2-10.fc12 fixes the issue. So let's decide if the maintainers want to push for an compiz upgrade in order to fix this. Many thanks to all for reporting the issue and for the troubleshooting. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I have been running the F12 packages from mid august as mentioned in comment #3, not being upgraded at all. I have experienced a couple of times after this a similar crash as reported, connected to when several compiz plug-ins gets called in approximately the same time. But it's not been as easy to reproduce this error as before, and it's been so infrequent (in total 3-4 times since the upgrade, compared to at least once an hour with the original F11 version) that I have not spent time debugging it further. But it happened under similar conditions as before, when two plug-ins was activated at the same time, and I have the feeling it is the Expo plug-in which is the culprit this time, and not rotate cube which triggered the new crash. Anyhow, the F12 packages do make it better than it was.
I upgraded compiz to the F12 packages, and it fixes the issue.
I just had to try today to see if I could manage to still make it crash. And I did manage, but it's harder, as mentioned earlier. * How to do it - Trigger Expo - Do rotate cube Sometimes I had to try this over and over again a number of times before trigging it, other times it hits in immediately. But it happens more reliable when Expo wall is activated. This is on compiz-0.8.2-10.fc11.x86_64 (recompiled F12 packages on F11 from mid august, as stated in comment #8) It is far better than it was with the compiz-0.7.8, but still not perfect. * gdb backtrace of the crash ------------------------------------------------------------------------------ (gdb) bt #0 strcmp () at ../sysdeps/x86_64/strcmp.S:29 #1 0x0000000000414998 in otherScreenGrabExist (s=0x1e16e60) at screen.c:2837 #2 0x00007f38e6d59fdd in rotate (d=0x1b88ac0, action=<value optimized out>, state=<value optimized out>, option=0x7fff8edd9b90, nOption=4) at rotate.c:726 #3 0x00007f38e6d5a6e5 in rotateLeft (d=0x1b88ac0, action=<value optimized out>, state=<value optimized out>, option=0x7fff8edd9d40, nOption=8) at rotate.c:885 #4 0x00000000004228d0 in triggerKeyPressBindings ( argument=<value optimized out>, event=<value optimized out>, nOption=40, option=0x24481e8, d=<value optimized out>, nArgument=<value optimized out>) at event.c:422 #5 handleActionEvent (argument=<value optimized out>, event=<value optimized out>, nOption=40, option=0x24481e8, d=<value optimized out>, nArgument=<value optimized out>) at event.c:915 #6 handleEvent (argument=<value optimized out>, event=<value optimized out>, nOption=40, option=0x24481e8, d=<value optimized out>, nArgument=<value optimized out>) at event.c:1247 #7 0x00007f38e94000c5 in glibHandleEvent (d=0x1b88ac0, event=0x7f38e5f251cd) at glib.c:185 #8 0x00007f38e83990c2 in videoHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at video.c:973 #9 0x00007f38e8194962 in placeHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at place.c:1550 #10 0x00007f38e7f903f5 in shotHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at screenshot.c:395 #11 0x00007f38e7d8c02f in resizeHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at resize.c:987 #12 0x00007f38e798211b in decorHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at decoration.c:1017 #13 0x00007f38e777c1f9 in wobblyHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at wobbly.c:2158 #14 0x00007f38e716ac9b in minHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at minimize.c:667 #15 0x00007f38e6d5b4be in rotateHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at rotate.c:1571 #16 0x00007f38e6b54ef5 in zoomHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at zoom.c:918 #17 0x00007f38e674b1a6 in infoHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at resizeinfo.c:572 #18 0x00007f38e653eae4 in shiftHandleEvent (d=0x7f3800000000, event=0x7f38e5f251cd) at shift.c:2090 #19 0x00007f38e6332644 in fadeHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at fade.c:622 #20 0x00007f38e612deab in scaleHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at scale.c:1850 #21 0x00007f38e5f233a4 in expoHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at expo.c:604 #22 0x00007f38e5d165c5 in scaleaddonHandleEvent (d=0x7f3800000000, event=0x7f38e5f251cd) at scaleaddon.c:509 #23 0x00007f38e5b0fb74 in moveHandleEvent (d=0x1b88ac0, event=0x7fff8eddaf90) at move.c:751 #24 0x00007f38e590ad26 in switchHandleEvent (d=0x7f3800000000, event=0x7f38e5f251cd) at switcher.c:1109 #25 0x000000000041093f in eventLoop () at display.c:1402 #26 0x000000000040c091 in main (argc=-1898073888, argv=0x2) at main.c:473 ------------------------------------------------------------------------------
Switching incorrect assignees to the default one.
Just a title modification : removed the mention "fixed in F12" and putting "Improved in F12", as per comment https://bugzilla.redhat.com/show_bug.cgi?id=511921#c8 Regards. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 545090 has been marked as a duplicate of this bug. ***
*** Bug 555617 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I have not seen the issue with Fedora 12. Resolved with newer version for me.
I have actually seen it a couple of times. But it is very hard to reproduce now - but I think more than two plug-ins needs to be triggered at approximately the same time for it to trigger. So I agree, this can be closed as "fixed" for now. Better to re-open this with more fresher info if needed. We're hitting F-13 soon with newer packages all over and to debug this we'll need fresher backtraces.
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.