Bug 12907

Created attachment 12169 [details]
xorg.conf

Created attachment 12170 [details]
Xorg.log

Roman: 1920x1200 with a dvi-i connector. Sweet :)
Egbert/Matthias: We've seen other people report crashes like this, and these crashes only turned up after libpciaccess support was added. The X version here seems quite recent too. This points clearly to something that was changed in X that our driver setup triggers, while vesa doesn't.

The location where this happens is strange. I would have to investigate this myself to get a more detailed backtrace.

Since I did libpciaccess i should take this one.

> I would have to investigate this myself to get a more detailed backtrace.
X server is current Debian sid. If there is anything I can do to help, feel free to ask.

Assinging this to myself.

Any advance?

Created attachment 12726 [details]
New Xorg.log

I've just updated X server and installed packaged radeonhd driver (0.0.4~git20071124). X crashed. But for another reason now, which is interesting.

Uff.

That should *never* *ever* happen. Seems like someone is happily overwriting memory...

Created attachment 12738 [details]
X crash log

For me X crashes immediately. This is using git master from today, Kubuntu Gutsy.

Created attachment 12739 [details]
xorg.conf that belongs to attachment 12738 [details]

Can you create a more meaningful stack trace?

Compile the driver with 'make CFLAGS="-O0 -g3"', install the xserver -debuginfo package (depending on the distribution you are using), and use the script I'll attach shortly for starting the server.

Created attachment 12740 [details]
stacktrace creator

Call this script for running Xorg. You might need to change the path to Xorg (/usr/bin/Xorg in the script).

Created attachment 12761 [details]
gdb log for rhd_cursor

Well, nothing new from me, unfortunately. No core, no backtrace.

Created attachment 12766 [details]
gdb output of stacktrace creator

Created attachment 12767 [details]
corefile from the gdb session above

Another effect of the X crash is that the monitor becomes black.
I can switch virtual terminals and type commands (ie. reboot the machine), but I am not able to see what I type.

> Another effect of the X crash is that the monitor becomes black.

Right. Just noticed that there is a bug in our xf86debug script. Add a new line containing "cont" just before the "quit" line, and your screen will (hopefully) be restored.


@B�rre:

Your issue is a completely unrelated one, and a severe one as well. Could you please open a different bug report for that? Assign it right to me.


@Roman:

Didn't notice that the crash was from a different user. For the ASSERT() xf86debug doesn't help. Still continue to use it, so if you get the crash of the initial bug report again, attach the gdb output file (core file not needed ATM).

I have yet to test radeonhd with a git Xserver.

Matthias, the original bug reported by Roman I Khimov refers to nother crash. It predates RandR support in the driver even.
Please open another ticket to track the other crash.

The second crash is now reported separately in https://bugs.freedesktop.org/show_bug.cgi?id=13420

Roman: Please clone
  git://anongit.freedesktop.org/~mhopf/radeonhd

and check whether the issue is gone. Last commit: 99feb9897

Done that, still the same, unfortunately. Just line number changed:

../../src/rhd_cursor.c:110: setCursorImage: Assertion '(Cursor->Height > 0) && (Cursor->Height <= MAX_CURSOR_HEIGHT)' failed.

Need full log?

Nope, thanks.

I just pushed some tests there, could you please git-pull and try it again? It will fail, but it will print out additional information, and give you a stack trace in Xorg.log. I would need both.

Got it.

============================================================
../../src/rhd_cursor.c:111: setCursorImage: Assertion '(Cursor->Width > 0) && (Cursor->Width <= MAX_CURSOR_WIDTH)' failed.
  Width=70, Height=26, Base=(nil)

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x47554a]
1: /lib/libc.so.6 [0x3f1a632040]
2: /lib/libc.so.6(kill+0x7) [0x3f1a632467]
3: /usr/lib/xorg/modules/drivers//radeonhd_drv.so(RhdAssertFailedFormat+0xb2) [0x2b947cd855e2]
4: /usr/lib/xorg/modules/drivers//radeonhd_drv.so [0x2b947cd80d58]
5: /usr/bin/X(xf86SetCursor+0xc3) [0x4b5803]
6: /usr/bin/X [0x4b5019]
7: /usr/bin/X(miPointerUpdateSprite+0x167) [0x4e0727]
8: /usr/bin/X [0x4e0812]
9: /usr/bin/X [0x4f5a05]
10: /usr/bin/X [0x5171c4]
11: /usr/bin/X [0x4559ac]
12: /usr/bin/X [0x458bd1]
13: /usr/bin/X(CoreProcessPointerEvent+0x37f) [0x45972f]
14: /usr/bin/X(ProcessPointerEvent+0xb2) [0x5420e2]
15: /usr/bin/X(mieqProcessInputEvents+0x109) [0x4d7b19]
16: /usr/bin/X(ProcessInputEvents+0x1c) [0x475cec]
17: /usr/bin/X(Dispatch+0x7d) [0x44e16d]
18: /usr/bin/X(main+0x47c) [0x436bcc]
19: /lib/libc.so.6(__libc_start_main+0xf4) [0x3f1a61e1c4]
20: /usr/bin/X(FontFileCompleteXLFD+0x261) [0x435f09]

Fatal server error:
Caught signal 11.  Server aborting
============================================================

And it looks like now I can reproduce it with 100% guarantee. It crashes when horizontal move cursor appears (or how to say it better? the one which appears on the right or left side of the window). I'm using "Chameleon-Pearl-Large" cursor theme from 'chameleon-cursor-theme' Debian package.

Hm, several symbols from the stack trace are missing, so I don't really know whether xf86CursorSetCursor() from the mi layer is called before xf86SetCursor().

xf86CursorSetCursor() is doing the size test.
Maybe Egbert has more old-school knowledge here.


Also, I just found this in your xorg.conf:
Section "ServerFlags"
	Option		"Xinerama"	"true"
EndSection

Xinerama doesn't work well together with RandR yet, and yes you have RandR disabled - but I haven't done much testing with Xinerama. Can you try and disable Xinerama for a test, please?

I also updated my test git repro, could you please git-pull and run the Xserver afterwards with the stacktrace creator (comment #14 and comment #19)?

> Also, I just found this in your xorg.conf:
> Section "ServerFlags"
>         Option          "Xinerama"      "true"
> EndSection
Nope, you have found it in B�rre's xorg.conf. :) Mine doesn't have Xinerama enabled.

 
> I also updated my test git repro, could you please git-pull and run the Xserver
> afterwards with the stacktrace creator (comment #14 and comment #19)?
I'll try. Although last time I tried the system freezed hard and I couldn't switch to console to see what's up. :)

(In reply to comment #28)
> > Also, I just found this in your xorg.conf:
> Nope, you have found it in B�rre's xorg.conf. :) Mine doesn't have Xinerama
> enabled.

Eek. :) Sorry.

> > I also updated my test git repro, could you please git-pull and run the Xserver
> > afterwards with the stacktrace creator (comment #14 and comment #19)?
> I'll try. Although last time I tried the system freezed hard and I couldn't
> switch to console to see what's up. :)

I guess you know that you can still use our driver (in between tests ;) with the Option "SWcursor"?
In the stacktrace creator you have to patch a line according to #19 to get the console lit up again.

> I guess you know that you can still use our driver (in between tests ;)
> with the Option "SWcursor"?
Hmm. Not thought of that. Thanks, I'll try. Maybe I'll be able to reproduce the crash that I've reported first.

> In the stacktrace creator you have to patch a line according to #19 to
> get the console lit up again.
OK.

Created attachment 12879 [details]
gdb log for rhd_cursor 2

This is the log for cursor crash, reproduced easily again as I've said above.

Regarding SWCursor - writing this from Konqueror under X with radeonhd driver and SWCursor enabled. So far so good. Yeah, 1920x1200, missed that with vesa. :)

BTW, I have core file if you need that (285 Mb :)).

> core file if you need that (285 Mb :)).
Or just one meg compressed.

BTW, I'm still running SWCursor session from November 30 here (almost 4 days), no problems.

Good to know.

I added some further tests in my own git repro. Can you please git-pull it once more and test it (w/o SWCursor)? I'd need both a gdb backtrace (from the stacktrace creator) and a full Xorg.0.log if it still fails.

> if it still fails.
Well, it doesn't. Running for two hours now, displayed all (or almost all) cursors from my theme, no crash.

So it seems we have found the issue:

Undocumented behavior of UseHWCursorARGB(). It has to verify the cursor size restrictions itself, while for UseHWCursor() this is not the case. Ugh.

Thanks for helping here.

Fixed in git affbdf54d68d8a36372a79ac2e631dfcbaf3897c