Thanks for taking the time to report this bug.
Without a backtrace it will be hard for the developers to fix that crash. 
Can you get us a backtrace with debugging symbols? 
Please see http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports for more information on how to do so. 

Thanks in advance!

OK, I have it but forgot to attach it...

Application: KWin (kwin), signal SIGABRT
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread -1235126608 (LWP 6615)]
0xb6a6b72b in nanosleep () from /lib/libc.so.6
[Current thread is 0 (process 6615)]

Thread 1 (Thread -1235126608 (LWP 6615)):
[KCrash Handler]
#5  0xb6a08917 in raise () from /lib/libc.so.6
#6  0xb6a0a038 in abort () from /lib/libc.so.6
#7  0xb6a0200c in __assert_fail () from /lib/libc.so.6
#8  0xb667b967 in xcb_xlib_lock (c=0x805f3d0) at xcb_xlib.c:73
#9  0xb6d26e18 in _XCBLockDisplay (dpy=0x8059d18) at xcb_lock.c:21
#10 0xb6c29d41 in XRenderFreePicture () from /usr/lib/libXrender.so.1
#11 0xb6fc2a57 in QX11PixmapData::release (this=0x805a810) at image/qpixmap_x11.cpp:1179
#12 0xb6fc2e7d in ~QX11PixmapData (this=0x8123ef0) at image/qpixmap_x11.cpp:1155
#13 0xb6fb8c1b in QPixmap::deref (this=0x8156bc8) at image/qpixmap.cpp:1264
#14 0xb6fb9450 in ~QPixmap (this=0x8156bc8) at image/qpixmap.cpp:326
#15 0xb70a5682 in ~QX11PaintEnginePrivate (this=0x8156b90) at ../../include/QtGui/private/../../../src/gui/painting/qpaintengine_x11_p.h:144
#16 0xb6feea9f in ~QPaintEngine (this=0x8105068) at painting/qpaintengine.cpp:676
#17 0xb7098d82 in ~QX11PaintEngine (this=0x8105068) at painting/qpaintengine_x11.cpp:451
#18 0xb6f7e296 in __tcf_2 () at ../../include/QtCore/../../src/corelib/global/qglobal.h:1563
#19 0xb6a0b47b in exit () from /lib/libc.so.6
#20 0xb6d1ff34 in _XDefaultError (dpy=0x8059d18, event=0xbfe7a5cc) at XlibInt.c:2860
#21 0xb6d20013 in _XError (dpy=0x8059d18, rep=0x8222880) at XlibInt.c:2912
#22 0xb6d2770c in process_responses (dpy=0x8059d18, wait_for_first_event=0, current_error=0xbfe7a6c8, current_request=847608) at xcb_io.c:138
#23 0xb6d27aca in _XReply (dpy=0x8059d18, rep=0xbfe7a6f0, extra=0, discard=1) at xcb_io.c:370
#24 0xb6d1bc9a in XSync (dpy=0x8059d18, discard=1) at Sync.c:48
#25 0xb6cfcf6e in XCloseDisplay (dpy=0x8059d18) at ClDisplay.c:67
#26 0xb6f617e0 in qt_cleanup () at kernel/qapplication_x11.cpp:2325
#27 0xb6f00689 in ~QApplication (this=0xbfe7a8d4) at kernel/qapplication.cpp:1019
#28 0xb7daf5aa in ~KApplication (this=0xbfe7a8d4) at /tmp/portage/kde-base/kdelibs-4.2.0/work/kdelibs-4.2.0/kdeui/kernel/kapplication.cpp:928
#29 0xb7fe93e0 in ~Application (this=0xbfe7a8d4) at /tmp/portage/kde-base/kwin-4.2.0/work/kwin-4.2.0/kwin/main.cpp:346
#30 0xb7feace7 in kdemain (argc=3, argv=0xbfe7aaa4) at /tmp/portage/kde-base/kwin-4.2.0/work/kwin-4.2.0/kwin/main.cpp:519
#31 0x08048842 in main (argc=) at /tmp/portage/kde-base/kwin-4.2.0/work/kwin_build/kwin/kwin_dummy.cpp:3

*** Bug 182765 has been marked as a duplicate of this bug. ***

Hi,

Tried to do memchecking with valgrind, but with valrgind attached kwin does not crash. Meanwhile I updated to a new libxcb en libXrender that match with xorg-server 1.5.x, but the problem persists.

Could it be a Qt bug? I use 4.4.2, and A.F.A.I.K. that is the latest version with real bugfixes.

Best Regards,
Erik

P.S. Should this bug now get status confirmed?

I have the exact same crash happening on Gentoo. In KDE 4.1.x also kopete, akregator and nepomukserver had the same crash, but not on every logout. In KDE 4.2.0 only kwin is left crashing.

It seems to be a Gentoo-specific bug (3 out of 3). Binary distributions tend to modify xcb to make it sloppier, so xcb might be the place to look at.

I am using 4.2.1 for a few weeks now and the issue seems to have gone...

Can we mark this as WORKSFORME ?

I experience the same now and again on Gentoo using kwin 3.5.10. I'd say about 10% of the times I shut my computer down, the crash handler pops up with this. Some addresses change, but otherwise the backtrace is completely the same in recent occurrences, and very similar with *__GI_ prepended to function names in older backtraces.
This might be a relevant Gentoo bug: http://bugs.gentoo.org/176839

[Thread debugging using libthread_db enabled]
[New Thread 0xb800d700 (LWP 4533)]
[KCrash handler]
#6  0xffffe424 in __kernel_vsyscall ()
#7  0x4441c670 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#8  0x4441deb8 in abort () at abort.c:88
#9  0x444156ee in __assert_fail (assertion=<value optimized out>, 
    file=<value optimized out>, line=<value optimized out>, 
    function=<value optimized out>) at assert.c:78
#10 0x445bb948 in xcb_xlib_lock (c=<value optimized out>) at xcb_xlib.c:73
#11 0x44601d70 in _XCBLockDisplay (dpy=<value optimized out>) at xcb_lock.c:21
#12 0x445de996 in XFreePixmap (dpy=<value optimized out>, 
    pixmap=<value optimized out>) at FreePix.c:40
#13 0x454d59c6 in QPixmap::deref (this=<value optimized out>)
    at kernel/qpixmap_x11.cpp:383
#14 0x4558f2a8 in ~QPixmap (this=) at kernel/qpixmap.cpp:389
#15 0x44b6508b in ~QBitmap (this=) at /usr/qt/3/include/qbitmap.h:50
#16 0x454d593e in QPixmap::deref (this=<value optimized out>)
    at kernel/qpixmap_x11.cpp:368
#17 0x4558f26e in ~QPixmap (this=) at kernel/qpixmap.cpp:389
#18 0x44b65ea6 in __tcf_0 () at client.cpp:2171
#19 0x4441f551 in exit (status=<value optimized out>) at exit.c:75
#20 0x445faba9 in _XDefaultError (dpy=<value optimized out>, 
    event=<value optimized out>) at XlibInt.c:2860
#21 0x445fac7e in _XError (dpy=<value optimized out>, 
    rep=<value optimized out>) at XlibInt.c:2912
#22 0x446026a2 in process_responses (dpy=<value optimized out>, 
    wait_for_first_event=<value optimized out>, 
    current_error=<value optimized out>, 
    current_request=<value optimized out>) at xcb_io.c:138
#23 0x44602a37 in _XReply (dpy=<value optimized out>, 
    rep=<value optimized out>, extra=<value optimized out>, 
    discard=<value optimized out>) at xcb_io.c:370
#24 0x445f6898 in XSync (dpy=<value optimized out>, 
    discard=<value optimized out>) at Sync.c:48
#25 0x445d8077 in XCloseDisplay (dpy=<value optimized out>) at ClDisplay.c:67
#26 0x454ad06b in qt_cleanup () at kernel/qapplication_x11.cpp:2413
#27 0x45522bc2 in ~QApplication (this=<value optimized out>)
    at kernel/qapplication.cpp:1087
#28 0x45c946db in ~KApplication (this=<value optimized out>)
    at kapplication.cpp:1682
#29 0x44b7686e in ~Application (this=<value optimized out>) at main.cpp:153
#30 0x44b76f95 in kdemain (argc=<value optimized out>, 
    argv=<value optimized out>) at main.cpp:298
#31 0x08048742 in main (argc=) at kwin.la.cpp:2

Should the workaround:
"export LIBXCB_ALLOW_SLOPPY_LOCK=1"
do the trick ?
http://www.linuxfromscratch.org/blfs/view/svn/x/libxcb.html

(In reply to comment #9)
> Should the workaround: "export LIBXCB_ALLOW_SLOPPY_LOCK=1" do the trick ?

I've just set it here, will see if that avoids the abort. Will know in a month.
A proper fix would still be better than this kind of workaround, though.

(In reply to comment #10)
> A proper fix would still be better than this kind of workaround, though.

I know but the workaround it's just for testing purposes

This could be a Qt bug too

This looks like http://bugs.freedesktop.org/show_bug.cgi?id=20254

Using 'export LIBXCB_ALLOW_SLOPPY_LOCK=1' in kde 4.2.3 across the system makes the crash disappear for me at least.

(In reply to comment #12)
> This looks like http://bugs.freedesktop.org/show_bug.cgi?id=20254
And seems to be an upstream bug. If anyone with a new version is still able to reproduce, please reopen.