Bug#618622: xserver-xorg-core: crash when resizing screen while running a fullscreen application
2011/3/17 Michel Dänzer <daenzer@debian.org>:
> 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)
>
It does not offer to attach a debugger at this error.
Thanks
Michal
Reply to: