Bug#618622: xserver-xorg-core: crash when resizing screen while running a fullscreen application
On Don, 2011-03-17 at 11:07 +0100, Michal Suchanek wrote:
> 2011/3/17 Michel Dänzer <daenzer@debian.org>:
> > On Don, 2011-03-17 at 10:30 +0100, Michal Suchanek wrote:
> >> 2011/3/17 Michel Dänzer <daenzer@debian.org>:
> >> > On Don, 2011-03-17 at 09:31 +0100, Michal Suchanek wrote:
> >> >> 2011/3/17 Michel Dänzer <daenzer@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
Reply to: