Getting help debugging X client crashes

[Michael Titke]

On 05/08/2016 20:17, Matt Lauria wrote:
>
> Can someone direct me where to get help tracking down a bug in X?
>
> I’ve built a GUI (python3.4 using tkinter running gnome on RHEL 6.8) 
> which crashes daily with a:
>
> X Error of failed request:  BadIDChoice (invalid resource ID chosen for this connection)
>    Major opcode of failed request:  139 (RENDER)
>    Minor opcode of failed request:  4 (RenderCreatePicture)
>    Resource id in failed request:  0x4181254
>    Serial number of failed request:  33776134
>    Current serial number in output stream:  33776143
>
> I’ve installed symbols/debuginfo and using gdb tried inspecting some 
> of the objects.
>
> This seems similar to the bug at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=458092 but when I looked 
> at xid.last/xid.max I didn’t see the same issue.
>
>
> Likely not -- the minor number corresponds to RenderCreatePicture, not 
> FreePicture.  Might have to dig into the X code to see what generates 
> BadID; owen was suggesting that it might be due due to IDs getting out 
> of sync somehow:
>
> 13:03 < otaylor> vlad_: Trying to create two resources with the ID of the
>                  second less than the ID of the first would cause that
>
>
> But I have no idea how we'd get into that situation, unless the IDs 
> wrapped around?
Address the X powers to be: I hope the above inlined comment is just a 
bad guess and not the reality: it's very xlib centric to check for 
bigger than on the RID bits and an actual binary tree of resource IDs 
might jump around as hell (because it might produce bit reversed RIDs 
initially) without any possibility to reuse an already used ID.
The core protocol standards are more terse on how to interpret RID bits 
and I hope one can still rely on that. Even XC-MISC would provide a free 
list which ...
BadIDChoice for no good reason is no good choice then ...

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20160808/49749f8f/attachment.html>