hi, first of all, many thanks for your great job !! i had this error : X Error of failed request : BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 148 (RENDER) Minor opcode of failed request: 4 (RenderCreatePicture) Resource id in failed request: 0xa876d1 Serial number of failed request: 2704569 Current serial number in output stream: 2704572 this error happens sometimes, with no particular reason, and that's a very bad point!!! it lead my app to close immediately. i'm using XQuartz with TK. this error happened with 2.3.2.1 and 2.3.3 rc3 can you please have a look to this and guide me to find the bug because i don't know wich one of my C code, or TK or XQuartz is faulty.... best regards nico
Quoted nico <sl1200mk2@gmail.com>:
hi, first of all, many thanks for your great job !!
i had this error : X Error of failed request : BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 148 (RENDER) Minor opcode of failed request: 4 (RenderCreatePicture) Resource id in failed request: 0xa876d1 Serial number of failed request: 2704569 Current serial number in output stream: 2704572
this error happens sometimes, with no particular reason, and that's a very bad point!!! it lead my app to close immediately. i'm using XQuartz with TK. this error happened with 2.3.2.1 and 2.3.3 rc3
can you please have a look to this and guide me to find the bug because i don't know wich one of my C code, or TK or XQuartz is faulty....
best regards nico __________________________
Hi Nico, I believe I may have seen this error before in the context of Tk. I'm a Tk maintainer/developer on SourceForge. Are you trying to draw text with something like Tk_DrawChars? Be aware that Tk for X11 will fail if you try to draw to a 1-bit deep Pixmap. This is a regression in Tk that occurred in 8.5, when the libXft-based text rendering was added. libXft IIRC uses Render. I wrote a patch for this issue that solved the problem for some users that used BLT and other extensions, but the other Tk developers thought the fix was too costly, and believed it would harm network Tk performance. Unfortunately there isn't a better way of solving the problem, and it certainly hasn't been solved by the other developers, so if this is the problem, you should use a deeper Pixmap, or --disable-xft. An easy way to confirm if the problem is caused by what I suspect it is, is to configure Tk with --disable-xft. This is from the tk/unix/README: --disable-xft Disable support for antialiased fonts via the Freetype/xft library. By default, this is switched on whenever the configure script can detect the required libraries. If the problem goes away, then look for pixmaps with limited depth, and try to use 8 or more as a depth. The patch I seem to have deleted, but it basically worked by using a different libXft function for 1-bit deep pixmaps, based on the XGetGeometry depth result for a drawable. The unfortunate problem was that there wasn't a way of exposing or caching the depth, because XIDs (used for Pixmap identifiers) are reused after destruction, and there wasn't enough information passed to the text drawing code. The XC-MISC extension provides the reuse of XIDs to clients automatically. It used to be that X11 didn't reuse XIDs (before XC-MISC was added as an extension), and apps that ran a long time would eventually exhaust all space, but for the last 10-15 years that hasn't been so. George -- http://people.freedesktop.org/~gstaplin/
hi George, and thank ou for your answer. George Peter Staplin a écrit :
Quoted nico <sl1200mk2@gmail.com>:
i had this error : X Error of failed request : BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 148 (RENDER) Minor opcode of failed request: 4 (RenderCreatePicture) Resource id in failed request: 0xa876d1 Serial number of failed request: 2704569 Current serial number in output stream: 2704572
Hi Nico,
I believe I may have seen this error before in the context of Tk. I'm a Tk maintainer/developer on SourceForge.
Are you trying to draw text with something like Tk_DrawChars? Be aware that Tk for X11 will fail if you try to draw to a 1-bit deep Pixmap. This is a regression in Tk that occurred in 8.5, when the libXft-based text rendering was added. libXft IIRC uses Render. I wrote a patch for this issue that solved the problem for some users that used BLT and other extensions, but the other Tk developers thought the fix was too costly, and believed it would harm network Tk performance. Unfortunately there isn't a better way of solving the problem, and it certainly hasn't been solved by the other developers, so if this is the problem, you should use a deeper Pixmap, or --disable-xft. all my app is built over display and changing canvas text.... a shame !! i don't use any extension exept Tk, and all text update are interpreted via itemconfigure. i never call Tk command directly, i always use the Tcl side.
if i use --disable-xft, font won't be aliased.... not so good
An easy way to confirm if the problem is caused by what I suspect it is, is to configure Tk with --disable-xft.
This is from the tk/unix/README: --disable-xft Disable support for antialiased fonts via the Freetype/xft library. By default, this is switched on whenever the configure script can detect the required libraries.
If the problem goes away, then look for pixmaps with limited depth, and try to use 8 or more as a depth.
as i'm using Tcl to update Tk's canvas, how can i determine if they're 1 bits or 8 bits depth ?? also, how can i try your patch because i'm not aware of Tcl network ?
George
++ nico
Quoted nico <sl1200mk2@gmail.com>:
hi George, and thank ou for your answer.
George Peter Staplin a écrit :
Quoted nico <sl1200mk2@gmail.com>:
i had this error : X Error of failed request : BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 148 (RENDER) Minor opcode of failed request: 4 (RenderCreatePicture) Resource id in failed request: 0xa876d1 Serial number of failed request: 2704569 Current serial number in output stream: 2704572
Hi Nico,
I believe I may have seen this error before in the context of Tk. I'm a Tk maintainer/developer on SourceForge.
Are you trying to draw text with something like Tk_DrawChars? Be aware that Tk for X11 will fail if you try to draw to a 1-bit deep Pixmap. This is a regression in Tk that occurred in 8.5, when the libXft-based text rendering was added. libXft IIRC uses Render. I wrote a patch for this issue that solved the problem for some users that used BLT and other extensions, but the other Tk developers thought the fix was too costly, and believed it would harm network Tk performance. Unfortunately there isn't a better way of solving the problem, and it certainly hasn't been solved by the other developers, so if this is the problem, you should use a deeper Pixmap, or --disable-xft. all my app is built over display and changing canvas text.... a shame !! i don't use any extension exept Tk, and all text update are interpreted via itemconfigure. i never call Tk command directly, i always use the Tcl side.
if i use --disable-xft, font won't be aliased.... not so good
An easy way to confirm if the problem is caused by what I suspect it is, is to configure Tk with --disable-xft.
This is from the tk/unix/README: --disable-xft Disable support for antialiased fonts via the Freetype/xft library. By default, this is switched on whenever the configure script can detect the required libraries.
If the problem goes away, then look for pixmaps with limited depth, and try to use 8 or more as a depth.
as i'm using Tcl to update Tk's canvas, how can i determine if they're 1 bits or 8 bits depth ??
It seems I may have been mistaken about the BadIDChoice cause... This may actually be an X.org bug. See: http://bugs.freedesktop.org/show_bug.cgi?id=20254 It could have something to do with using the newer libX11 with the older xorg-server-1.4-apple branch. I'm not sure if the XQuartz libX11 has the fix for the xcb code that was broken, or what specific version of the libX11 release has the fix, if any. The changes appear to be in git though now (the last update was March 30, 2009) for a March 24, 2009 commit. Jeremy, do you have any thoughts on this? George -- http://people.freedesktop.org/~gstaplin/
On Apr 7, 2009, at 12:16, George Peter Staplin wrote:
It seems I may have been mistaken about the BadIDChoice cause...
This may actually be an X.org bug.
See: http://bugs.freedesktop.org/show_bug.cgi?id=20254
It could have something to do with using the newer libX11 with the older xorg-server-1.4-apple branch.
Actually, that patch has nothing to do with libX11... that's entirely libxcb: http://cgit.freedesktop.org/xcb/libxcb/commit/?id=beccb0be15f5699c942a0af333... Is the build of tk in question using xcb? Or is it using a libX11 that is using xcb (the one we provide does not, but if you enable the +xcb variant in MacPorts it will).
I'm not sure if the XQuartz libX11 has the fix for the xcb code that was broken, or what specific version of the libX11 release has the fix, if any. The changes appear to be in git though now (the last update was March 30, 2009) for a March 24, 2009 commit.
Jeremy, do you have any thoughts on this?
libxcb is still not mature enough in my opinion. I think that it is definitely getting there, but not there yet. Can you try rebuilding your code to not use libxcb and try again?
Jeremy Huddleston a écrit :
On Apr 7, 2009, at 12:16, George Peter Staplin wrote:
It seems I may have been mistaken about the BadIDChoice cause...
This may actually be an X.org bug.
See: http://bugs.freedesktop.org/show_bug.cgi?id=20254
It could have something to do with using the newer libX11 with the older xorg-server-1.4-apple branch.
Actually, that patch has nothing to do with libX11... that's entirely libxcb:
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=beccb0be15f5699c942a0af333...
Is the build of tk in question using xcb? Or is it using a libX11 that is using xcb (the one we provide does not, but if you enable the +xcb variant in MacPorts it will).
I'm not sure if the XQuartz libX11 has the fix for the xcb code that was broken, or what specific version of the libX11 release has the fix, if any. The changes appear to be in git though now (the last update was March 30, 2009) for a March 24, 2009 commit.
Jeremy, do you have any thoughts on this?
libxcb is still not mature enough in my opinion. I think that it is definitely getting there, but not there yet.
Can you try rebuilding your code to not use libxcb and try again?
i rebuilt Tk with --disable-xft and things are fine, but i'm afraid i can't tell your more about libxcb and so.... ++ nico
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Quoted Jeremy Huddleston <jeremyhu@apple.com>:
On Apr 7, 2009, at 12:16, George Peter Staplin wrote:
It seems I may have been mistaken about the BadIDChoice cause...
This may actually be an X.org bug.
See: http://bugs.freedesktop.org/show_bug.cgi?id=20254
It could have something to do with using the newer libX11 with the older xorg-server-1.4-apple branch.
Actually, that patch has nothing to do with libX11... that's entirely libxcb:
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=beccb0be15f5699c942a0af333...
Does XQuartz use a libX11 built with --disable-xcb (if I recall the option correctly) still? There is a layer in libX11 that will use the xcb code if possible for implementing parts of libX11. From what I see in an older configure the option is --with-xcb. I'm not sure if it's a default when the libxcb is available. If I recall correctly I ran into this problem on the Mac before, because recent libX11 try to use libxcb by default, and that was causing an assertion to fail somewhere in libxcb with one of the GLX tests, and from all appearances the code path and LockDisplay() usage appeared correct in that path.
Is the build of tk in question using xcb? Or is it using a libX11 that is using xcb (the one we provide does not, but if you enable the +xcb variant in MacPorts it will).
I'm not sure if the XQuartz libX11 has the fix for the xcb code that was broken, or what specific version of the libX11 release has the fix, if any. The changes appear to be in git though now (the last update was March 30, 2009) for a March 24, 2009 commit.
Jeremy, do you have any thoughts on this?
libxcb is still not mature enough in my opinion. I think that it is definitely getting there, but not there yet.
I agree. libxcb is also missing an extension or 2, and the API is very different than Xlib/libX11. It's supposed to have much better thread support, a more async API, and they have used the Z formal method to prove the code correct in some areas. There was an interesting usenix paper about how the XCB developers used Z. http://www.usenix.org/events/usenix02/tech/freenix/full_papers/massey/massey... George -- http://people.freedesktop.org/~gstaplin/
Actually, that patch has nothing to do with libX11... that's entirely libxcb:
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=beccb0be15f5699c942a0af333...
Does XQuartz use a libX11 built with --disable-xcb (if I recall the option correctly) still? There is a layer in libX11 that will use the xcb code if possible for implementing parts of libX11. From what I see in an older configure the option is --with-xcb. I'm not sure if it's a default when the libxcb is available.
Yes, we explicitly use --without-xcb to build libX11 just in case.
If I recall correctly I ran into this problem on the Mac before, because recent libX11 try to use libxcb by default, and that was causing an assertion to fail somewhere in libxcb with one of the GLX tests, and from all appearances the code path and LockDisplay() usage appeared correct in that path.
Yeah, we definitely don't use xcb. libxcb wasn't even working with the launchd DISPLAY socket until 2.3.2, I believe... so we would've seen major breakage if it was used in libX11.
libxcb is still not mature enough in my opinion. I think that it is definitely getting there, but not there yet.
I agree. libxcb is also missing an extension or 2, and the API is very different than Xlib/libX11.
I think most of the extensions in libxcb + xcb-util cover what most clients will want. It doesn't have AppleWM for example, but I don't plan on rewriting quartz-wm to use xcb, so /shrug.
It's supposed to have much better thread support, a more async API, and they have used the Z formal method to prove the code correct in some areas. There was an interesting usenix paper about how the XCB developers used Z.
http://www.usenix.org/events/usenix02/tech/freenix/full_papers/massey/massey...
Neato.
participants (3)
-
George Peter Staplin
-
Jeremy Huddleston
-
nico