Bug 55260

There's no crash recorded. Looked for a capture of the stderr perhaps.

Created attachment 67632 [details]
lightdm logs

Found something in the lightdm logs for X. 

X: ../../include/privates.h:116: dixGetPrivateAddr: Assertion `key->initialized' failed.

Here's privates.h for my machine:

113 static inline void *
114 dixGetPrivateAddr(PrivatePtr *privates, const DevPrivateKey key)
115 {
116     assert(key->initialized);
117     return (char *) (*privates) + key->offset;
118 }

I attached the lightdm logs as well.

Hmm, can you attach gdb and get a full bt? Hopefully I'll be able to test tomorrow but if you can grab that full backtrace I should be able to find the bug. Thanks.

Created attachment 67698 [details]
GDB Backtrace

Here you go, the full backtrace. Let me know if you need anything else!

Forgot to mention, this particular backtrace is for the act of plugging in the displayport adapter, although I think the action may be irrelevant.

Odd, can't spot a means for that assertion to be triggered. Tried reproducing locally, with no success so far, with and without server regeneration (and confirmed that sna_handle_uevents is being invoked). Is there a required step before it crashes?

There are no additional steps. It will crash no matter where I am in X. For that matter, this backtrace was done while I was at the login screen. 

Here's some additional information:

Ubuntu 12.04
Linux tigger 3.5.0-15-generic #20-Ubuntu SMP Mon Sep 17 21:37:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Display manager: Lightdm

Intel driver commit: 74f930fd80c3f97a1b6213e9e79e02f8f51c64b9

Hardware:
Dell XPS 13
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
Intel HD Graphics 3000

I ended up upgrading to xorg-server 1.13 and it still crashes with SIGABRT (on different lines, of course)

Xorg: ../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed.

Are there any updates to this bug? The issue still occurs with 2.20.12. Thanks!

No, I haven't see this locally at all. Can you please try to reproduce the issue with --enable-debug=full and attach the Xorg.log?

Created attachment 68919 [details]
Full xorg debug logs

I attached the debug logs, let me know if you need anything else.

Xorg.7.log contains everything from start to the hotplug event. Xorg.8.log is the restarted session.

Everything was done on the Ubuntu login screen.

Created attachment 68920 [details]
Full xorg debug logs updated

Sorry about that, just noticed there are more debug statements in git. I pulled in the commit and reran the steps. Here are the updated logs.

Xorg.1.log contains everything from start to hotplug event
Xorg.2.log contains the restarted session

Again, everything was done on the Ubuntu login screen with the Displayport adapter already in there and removed to trigger the restart.

Hmm, everything points towards rrPrivKeyRec being initialised -- it is used in the function that is called before the assert (and the initialisation code itself looks solid). So presumably we then have some corruption inside RRGetInfo(). In particular the function calls pScrPriv->rrGetInfo() between passing its own assertion on rrPrivKeyRec and just before calling RRScanOldConfig() and failing.

Can you attach gdb and set a watchpoint on *&rrPrivKeyRec.initialized?

Created attachment 68940 [details]
Watchpoint on rrPrivKeyRec.initialized

Attached the logs, hope that helps.

Created attachment 68941 [details]
Second watch, this time while unplugged then plug

I just observed something very interesting. In the watch log I attached above, this was following this scenario:

1. Have displayport already plugged in
2. Launch gdb for Xorg
3. Set watchpoint & run
4. No watchpoints encountered until I unplugged the displayport adapter

In this scenario, I attached a log where I followed these steps:

1. Have displayport not already plugged in
2. Launch gdb for Xorg
3. Set watchpoint & run
4. I encounter a watchpoint almost immediately (I followed this up with a bt full)
5. Plug in the displayport adapter
6. Nothing happens

When running X as usual, I repeated the steps above. In the first scenario, X crashes and restarts. In the second scenario, nothing happens but the second monitor does not display anything. Upon restarting X (essentially following the first scenario), the second monitor begins displaying like a second monitor would but would crash again like the first scenario.

This is the one that is obviously an issue:

Hardware access (read/write) watchpoint 1: *&rrPrivKeyRec.initialized
Num     Type           Disp Enb Address    What
1       acc watchpoint keep y              *&rrPrivKeyRec.initialized
Starting program: /usr/bin/Xorg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
Hardware access (read/write) watchpoint 1: *&rrPrivKeyRec.initialized

Value = 0
dixGetPrivate (privates=0x5555559ccec0, key=<optimized out>)
    at ../../randr/rrinfo.c:323
323	../../randr/rrinfo.c: No such file or directory.
Continuing.


line 323 of rrinfo.c is bogus. Can you attach the complete transcript, starting X under gdb? I expect to see the bt as we initialize the Screens and Crtcs, and never this second one. I just want to verify that we get the first bt and then nothing in between before it reads 0 - everytime it hits the watchpoint grab the bt. Also a good thing to check would be 'p &rrPrivKeyRec.initialized', I suspect that is not constant...

Alternatively, you could 'p &rrPrivKeyRec.initialized' and then 'watch *<address>'

Hmm, 'p &rrPrivKeyRec.initialized; watch *$'

Created attachment 68953 [details]
Test run 2 with more info

Reran the test scenarios with the steps provided. 

Some additional info:

In scenario 1 (already plugged in then unplug):

I noticed it would not break until I pulled the displayport. I set a new watchpoint on (Bool *) 0x55555598d388 <rrPrivKeyRec+8> but it never tripped that watchpoint.

In scenario 2 (not plugged in then plug in):

I noticed it would almost immediately break on the watchpoint just like above. I printed & set a new watchpoint but no new breakpoints were ever encountered. Plugging in the DP did nothing and unplugging it did nothing.

Can you please keep experimenting? My fear is that this is a build issue.

How about if you break on RRGetInfo() and manually step through p rrScrPriv.initialized at each point?

Created attachment 68966 [details]
Step through of rrScrPriv.initialized

I ended up breaking on RRGetInfo() and printed out the value of rrPrivKeyRec.initialized step-by-step using:

p rrPrivKeyRec.initialized

Hopefully I'm doing this correctly. There is no rrScrPriv but there is a rrScrPrivPtr (so I just assumed it was rrPrivKeyRec.initialized, which is what I'm printing out here)

This is using only Scenario 1.

Is there a chance you can come onto IRC (irc.freenode.net #intel-gfx) and I can ask you check a few more things in gdb? (I'm ickle on #intel-gfx)

Unfortunately, not for another couple of hours. 3-4 hours. If that's not too good for you, just let me know what to run for now and I can grab the data later today.

(In reply to comment #23)
> Unfortunately, not for another couple of hours. 3-4 hours. 

Heh, had been planning on an early night.

> If that's not too
> good for you, just let me know what to run for now and I can grab the data
> later today.

For scenario 1, I really want to sanity check that RRInit() is being called during sna_pre_init() [that's right at the very start of X loading]. That initalizes the rrPrivKeyRec and so should be preventing the assertions. If it is being called, then the question is where does it get cleared and so triggering the assertion. Which is partly why I'm wondering if that memory address is being clobbered elsewhere.

If you could build X with -O0 -g3, that would be a big help when running it through gdb. And also running it under valgrind.

Created attachment 68970 [details] [review]
Disable RandR hotplug events with Xinerama

Created attachment 68971 [details] [review]
Disable RandR hotplug events with Xinerama

Better patch, no ifdef required.

Patch works. There is another bug that I'm noticing but I will open new bugs for those. Thanks for your patience while working through this! :)

commit 1a489142c8e6a4828348cc9afbd0f430d3b1e2d8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Oct 23 23:43:50 2012 +0100

    sna: Disable RandR hotplug events if Xinerama is enabled
    
    Since RandR itself is disabled if Xinerama is enabled, for example with
    ZaphodHeads, calling RRGetInfo() upon a hotplug event generates an
    assertion.
    
    Reported-by: Stephen Liang <inteldriver@angrywalls.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55260
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>