On Don, 2011-03-17 at 11:07 +0100, Michal Suchanek wrote: > 2011/3/17 Michel Dänzer <daen...@debian.org>: > > On Don, 2011-03-17 at 10:30 +0100, Michal Suchanek wrote: > >> 2011/3/17 Michel Dänzer <daen...@debian.org>: > >> > On Don, 2011-03-17 at 09:31 +0100, Michal Suchanek wrote: > >> >> 2011/3/17 Michel Dänzer <daen...@debian.org>: > >> >> > On Don, 2011-03-17 at 00:46 +0100, Michal Suchanek wrote: > >> >> >> > >> >> >> Running a fullscreen d3d application that changes screen mode (such > >> >> >> as > >> >> >> Vazteroids, in Wine) causes one screen to go blank and the other to > >> >> >> switch to the resolution the application requested. > >> >> >> > >> >> >> When I run my script that sets the main screen to native resolution > >> >> >> and > >> >> >> reenables the other screen and exit the d3d application X crashes. > >> >> > > >> >> > Please try to provide more information about the crash. Preferably a > >> >> > full gdb backtrace, but at least an X log file with a backtrace. > >> >> > >> >> It's a double free (abort) so there is no backtrace in the log. There > >> >> is a gdb backtrace attached to the original report. > >> > > >> > Oh, I didn't notice the attachment, and you didn't mention it. > >> > > >> > Probably the fastest way to track down the problem would be to run the X > >> > server in valgrind. > >> > >> A valgrind log showing some (probably unrelated) issues. > >> > >> As I need to run the X server as root to run in valgrind the > >> environment is different and there is probably some piece missing. > >> > >> I can't reproduce the crash as root with valgrind or without. > > > > The X server always runs as root. You can run the clients from the same > > user accounts as before. > > There are some issues like the Xsession script not making sure that > there is at least one client running so that the X server does not > reset and X server crashing instead of resetting but now valgrind > aborts the X server as soon as I run the xrandr script, not after > quitting the application as glibc does.
[...] > ==28521== Invalid write of size 1 > ==28521== at 0x4C26044: memcpy (mc_replace_strmem.c:497) > ==28521== by 0x8FF277A: RADEONDownloadFromScreenCS (radeon_exa_funcs.c:667) > ==28521== by 0x9693326: exaCopyDirty (exa_migration_classic.c:220) > ==28521== by 0x9695D79: exaPrepareAccessReg_mixed > (exa_migration_mixed.c:247) > ==28521== by 0x969ED93: ExaCheckImageGlyphBlt (exa_unaccel.c:326) > ==28521== by 0x56766D: miImageText8 (mipolytext.c:114) > ==28521== by 0x4D07C6: damageImageText8 (damage.c:1547) > ==28521== by 0x4399CC: doImageText (dixfonts.c:1559) > ==28521== by 0x439A4F: ImageText (dixfonts.c:1604) > ==28521== by 0x430342: ProcImageText8 (dispatch.c:2290) > ==28521== by 0x4334D0: Dispatch (dispatch.c:431) > ==28521== by 0x42575A: main (main.c:287) > ==28521== Address 0xd4c0040 is 0 bytes after a block of size 5,242,880 Can you run valgrind with --db-attach=yes and get a full gdb backtrace at this point? (With xserver-xorg-core-dbg and xserver-xorg-video-radeon-dbg installed) -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1300357893.9075.44.camel@thor.local
