Latest Ubuntu Karmic, KDM login for an NTA thin client under LTSP. When trying to start a KDE session the thin client's X server dies with: X: main/renderbuffer.c:2159: _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed There is plenty of memory, and Ratpoison and WindowMaker logins do not encounter this failure. There was no sign of this assertion failure in any logs; I had to run X manually from a RS-232 session connected to the thin client to see this failure message.
Please attach X config and logs.
Created attachment 34001 [details] X server log
This is a thin client, so there's no xorg.conf file. I've attached the X server log, gleaned from the thin client RAM filesystem after the failure, with the X server aborted.
This bug was also found in debian, see: http://bugs.debian.org/562585 The problem seam to come from the via_renderbuffer structs in the via_context struct that get freed twice... See http://bugs.debian.org/562585#57 for details (including gdb traces).
Usually this is a result of updating your build tree without running 'make clean' before rebuilding.
Well I don't think 'make clean' will rewrite the code, also I did build it by rebuilding the debian package, and generally this starts by a 'make clean'. Note that I did rebuild the debian package, not the latest of your code, but according to git [1] today's struct via_context has not changed much. [1] http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/unichrome/via_context.h#n154 The problem come from the 'struct via_renderbuffer' inside this structure (line 160-164) also line 159 explicitly says it should not be here, so the writer somehow new this was not that clean. What my gdb session showed is that the 'struct via_context' get freed while there are still some reference to the 'struct via_renderbuffer'. So when the references gets cleared, the assert occurs because the referenced 'struct via_renderbuffer' has already been freed. (for more details, go and actually read my post on debian bts). Maybe the caller should not make the 'struct via_context' be freed in the first place, however 'struct via_renderbuffer' use a smart reference counting (inherited from the 'struct gl_renderbuffer') so if it was referenced properly this would not append. I propose to replace the 'struct via_renderbuffer' inside 'struct via_context' by pointers and use the proper reference counting. If this is the right direction, I'll try to provide a patch. However the comment on line 159 sound more like there should not be 'via_renderbuffer' here at all... So if someone can point me to the relevant documentation (to get more insight on how it should be done) I'll work on it.
Well done Julien, thanks very much. I hit this bug with KDE on Fedora 13; I'm happy to help with testing on Fedora.
Created attachment 38132 [details] [review] preliminary patch Here is a first patch I tried to make, There are still a lot of rework to do to make a nice cleaning of the driver. Anyway with this patch, KDE starts ;) And I hope there is no memory leaks (if some memory tracking setup has been done on mesa, some doc and links would be appreciated here). I'm mostly looking at intel and radeon dri drivers for inspiration, hope they are model in good shape, or I would be following the wrong line... If someone wants to test this, please do so ! If you find bugs, send me a mail with reproduction scenario (and gdb backtrace if you can), thanks. Especially if you can crash it with something smaller than KDE ! ;)
> If someone wants to test this, please do so ! If you find bugs, send me a mail > with reproduction scenario (and gdb backtrace if you can), thanks. Especially > if you can crash it with something smaller than KDE ! ;) Hello, Best regards in advance, I'm trying to get it to work too on kde, got the error of this bug, grab your patch and now there is another error: /usr/bin/X: symbol lookup error: /usr/lib/dri/unichrome_dri.so: undefined symbol: _mesa_free tuxi686 ~ # startx xauth: creating new authority file /root/.serverauth.3805 X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-gentoo-tux i686 Gentoo Current Operating System: Linux tuxi686 2.6.35.4-smp #1 SMP Mon Sep 13 16:37:28 CDT 2010 i686 Kernel command line: root=0805 vga=0x317 splash=silent mtrr:1 driversonly pause Build Date: 13 September 2010 10:18:31PM Current version of pixman: 0.18.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Sep 21 23:51:52 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Fulfilled via DRI at 20976640 Freed 20976640 (pool 2) which: no keychain in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.4:/usr/lib/subversion/bin) /etc/X11/xinit/xinitrc: línea 59: xclock: no se encontró la orden /usr/bin/X: symbol lookup error: /usr/lib/dri/unichrome_dri.so: undefined symbol: _mesa_free login: fatal IO error 11 (Recurso no disponible temporalmente) or KillClient on X server ":0.0" xterm: fatal IO error 11 (Recurso no disponible temporalmente) or KillClient on X server ":0.0" xterm: fatal IO error 104 (Conexión reinicializada por la máquina remota) or KillClient on X server ":0.0" xinit: connection to X server lost. tuxi686 ~ #
Julien, I'm unable to build mesa with provided patch too. Any pointers? Thank you!
Unfortunately, I didn't get time to work on that yet... I still plan too, but I really don't know when ;)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/openchrome/old-bug-database/issues/9.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.