[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: Getting help debugging X client crashes
From: Aaron Plattner <aplattner () nvidia ! com>
Date: 2016-08-09 17:27:39
Message-ID: 0fa7632e-5c43-1ed0-73bf-f33d2a624af3 () nvidia ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 08/08/2016 03:01 AM, Michael Titke wrote:
> 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 ...
The code for that is here:
https://cgit.freedesktop.org/xorg/xserver/tree/dix/resource.c#n1180
Bool
LegalNewID(XID id, ClientPtr client)
{
*void* *val;
*int* rc;
#ifdef PANORAMIX
XID minid, maxid;
*if* (!noPanoramiXExtension) {
minid = client->clientAsMask | (client->index ?
SERVER_BIT : SERVER_MINID);
maxid = (clientTable[client->index].fakeID | RESOURCE_ID_MASK) + 1;
*if* ((id >= minid) && (id <= maxid))
*return* TRUE;
}
#endif /* PANORAMIX */
*if* (client->clientAsMask == (id & ~RESOURCE_ID_MASK)) {
rc = dixLookupResourceByClass(&val, id, RC_ANY, serverClient,
DixGetAttrAccess);
*return* rc == BadValue;
}
*return* FALSE;
}
So the possibilities for BadIDChoice from the server here (aside from
some Xinerama weirdness) are 1) XID from the wrong client's range, or 2)
XID already in use. This definitely smells like a client-side issue.
~/hdd/git/x/xserver/dix/resource.c.html
> Regards,
> Michael
>
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/08/2016 03:01 AM, Michael Titke
wrote:<br>
</div>
<blockquote cite="mid:57A85885.2040900@o2online.de" type="cite">
<div class="moz-cite-prefix">On 05/08/2016 20:17, Matt Lauria
wrote:<br>
</div>
<blockquote
cite="mid:00e401d1ef45$9f202180$dd606480$@interactivebrokers.com"
type="cite">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Courier
New"">Can someone direct me where to get help
tracking down a bug in X?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"">I’ve built a GUI (python3.4 using tkinter
running gnome on RHEL 6.8) which crashes daily with \
a:<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
<pre>X Error of failed request: BadIDChoice (invalid resource ID chosen \
for this connection)<o:p></o:p></pre>
<pre> Major opcode of failed request: 139 (RENDER)<o:p></o:p></pre>
<pre> Minor opcode of failed request: 4 \
(RenderCreatePicture)<o:p></o:p></pre>
<pre> Resource id in failed request: 0x4181254<o:p></o:p></pre>
<pre> Serial number of failed request: 33776134<o:p></o:p></pre>
<pre> Current serial number in output stream: 33776143<o:p></o:p></pre>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"">I’ve installed symbols/debuginfo and using gdb
tried inspecting some of the objects.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New"">This seems similar to the bug at <a
moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=458092">https://bugzilla.mozilla.org/show_bug.cgi?id=458092</a>
but when I looked at xid.last/xid.max I didn’t see the
same issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
<br>
</div>
</blockquote>
<blockquote type="cite">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:<br>
<br>
13:03 < otaylor> vlad_: Trying to create two resources
with the ID of the <br>
second less than the ID of the first would
cause that<br>
<br>
<br>
But I have no idea how we'd get into that situation, unless the
IDs wrapped around?</blockquote>
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.<br>
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 ...<br>
BadIDChoice for no good reason is no good choice then ...<br>
</blockquote>
The code for that is here:<br>
<a class="moz-txt-link-freetext" \
href="https://cgit.freedesktop.org/xorg/xserver/tree/dix/resource.c#n1180">https://cgit.freedesktop.org/xorg/xserver/tree/dix/resource.c#n1180</a><br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<script type="text/javascript">
<!--
-->
</script><font face="monospace">
Bool<br>
LegalNewID(XID id, ClientPtr client)<br>
{<br>
<font color="#2e8b57"><b>void</b></font> *val;<br>
<font color="#2e8b57"><b>int</b></font> rc;<br>
<br>
<font color="#a020f0">#ifdef PANORAMIX</font><br>
XID minid, maxid;<br>
<br>
<font color="#a52a2a"><b>if</b></font> (!noPanoramiXExtension)
{<br>
minid = client->clientAsMask | (client->index ?<br>
SERVER_BIT :
SERVER_MINID);<br>
maxid = (clientTable[client->index].fakeID |
RESOURCE_ID_MASK) + <font color="#ff00ff">1</font>;<br>
<font color="#a52a2a"><b>if</b></font> ((id >= minid)
&& (id <= maxid))<br>
<font color="#a52a2a"><b>return</b></font> <font
color="#ff00ff">TRUE</font>;<br>
}<br>
<font color="#a020f0">#endif</font> <font
color="#0000ff">/*</font><font color="#0000ff"> PANORAMIX </font><font
color="#0000ff">*/</font><br>
<font color="#a52a2a"><b>if</b></font> (client->clientAsMask
== (id & ~RESOURCE_ID_MASK)) {<br>
rc = dixLookupResourceByClass(&val, id, RC_ANY,
serverClient,<br>
DixGetAttrAccess);<br>
<font color="#a52a2a"><b>return</b></font> rc == BadValue;<br>
}<br>
<font color="#a52a2a"><b>return</b></font> <font
color="#ff00ff">FALSE</font>;<br>
}<br>
</font>
<br>
So the possibilities for BadIDChoice from the server here (aside
from some Xinerama weirdness) are 1) XID from the wrong client's
range, or 2) XID already in use. This definitely smells like a
client-side issue.
<title>~/hdd/git/x/xserver/dix/resource.c.html</title>
<meta name="Generator" content="Vim/7.4">
<meta name="plugin-version" content="vim7.4_v2">
<meta name="syntax" content="c">
<meta name="settings"
content="no_pre,no_foldcolumn,expand_tabs,prevent_copy=">
<meta name="colorscheme" content="default">
<!-- vim: set foldmethod=manual : --><br>
<br>
<blockquote cite="mid:57A85885.2040900@o2online.de" type="cite">
Regards,<br>
Michael<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
</body>
</html>
[Attachment #6 (text/plain)]
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic