From pheonix.sja at att.net Wed Dec 4 13:37:39 2024 From: pheonix.sja at att.net (Steven J Abner) Date: Wed, 04 Dec 2024 08:37:39 -0500 Subject: XCB_DESTROY_NOTIFY & SIGTERM References: Message-ID: Hoping to clarify or ensure that a xcb_generic_error_t error_code of 143 is a SIGTERM code. First time I received this and a non-xcb source claims this is so. I got the error on a 2 window 'app' after the XCB_DESTROY_NOTIFY of the first window. It appears only after what I'm guessing was a 'complete' clean up of first window's resources. By this I mean the 'last reference' to a cairo_surface_t is destroyed. I can comment out the 'finish/destroy' code to not receive code 143. I also assume I would get this code on a single window 'app', but don't see because on XCB_DESTROY_NOTIFY I exit the event loop and disconnect. If the non-xcb source is to be believed, the 143 SIGTERM is stating the X-server correctly terminated the 'process' of the first window, and only resources for the second window remain. Is this a correct interpretation of signals? Steve From pharris2 at rocketsoftware.com Wed Dec 4 15:31:36 2024 From: pharris2 at rocketsoftware.com (Peter Harris) Date: Wed, 4 Dec 2024 15:31:36 +0000 Subject: XCB_DESTROY_NOTIFY & SIGTERM In-Reply-To: References: Message-ID: > Hoping to clarify or ensure that a xcb_generic_error_t error_code of > 143 is a SIGTERM code. First time I received this and a non-xcb source claims this > is so. No, signals are in a different namespace from X11 error codes. Errors >= 128 are "extension errors", which are allocated dynamically. On my server, for example, 143 would be RENDER + 3, which is "BadGlyphSet" https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/master/src/render.xml?ref_type=heads#L138 BadGlyphSet probably isn't the error you are getting, you will have to check the extension error numbers of your server. From the command line, you can use "xdpyinfo -queryExt" to see the base error number of each extension. Programmatically, you can call xcb_get_extension_data for each of the extensions you used to find the relevant base error numbers. Peter Harris ================================ Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. From pheonix.sja at att.net Wed Dec 4 17:00:50 2024 From: pheonix.sja at att.net (Steven J Abner) Date: Wed, 04 Dec 2024 12:00:50 -0500 Subject: XCB_DESTROY_NOTIFY & SIGTERM In-Reply-To: References: Message-ID: On Wed, Dec 4 2024 at 03:31:36 PM +0000, Peter Harris wrote: > Errors >= 128 are "extension errors", which are allocated > dynamically. On my server, for example, 143 would be RENDER + 3, > which is "BadGlyphSet" Forgive give me for being newbie, but kinda lost me :( I have a list of extensions. They enumerate with a name, like RENDER. Then can include up to 3 subsets, (opcode, base event, base error). Looking at the linked xml/repository, I assume your RENDER is 140 for 'opcode' and per xml you used the = 3. My returned error lists major/minor codes. How do I choose which to use? If I use 'RENDER (opcode: 139, base error: 142)' do I get "BadGlyph" or use base and have "BadPicture"? My err is: error_code = 143, minor_code = 7, major_code = 139 and I assume major_code == opcode?? In the extension list I do have: DAMAGE (opcode: 143, base event: 91, base error: 152) I can + 0 for "BadDamage". But why on XCB_DESTROY_NOTIFY would getting rid of a reference cause glyph or damage? here is offending code: if (iface->vid_buffer != NULL) { cairo_surface_finish(iface->vid_buffer); cairo_surface_destroy(iface->vid_buffer); } which was created from: iface->vid_buffer = cairo_xcb_surface_create(connection, window, visual, iface->draw_box.w, iface->draw_box.h); Apologies for me being so lost :( Steve From psychon at znc.in Wed Dec 4 17:32:06 2024 From: psychon at znc.in (Uli Schlachter) Date: Wed, 4 Dec 2024 18:32:06 +0100 Subject: XCB_DESTROY_NOTIFY & SIGTERM In-Reply-To: References: Message-ID: <28fa253a-571e-433c-b3c6-ecde9fa98b43@znc.in> Hi, Am 04.12.24 um 14:37 schrieb Steven J Abner: > Hoping to clarify or ensure that a xcb_generic_error_t error_code of 143 > is a SIGTERM code. First time I received this and a non-xcb source > claims this is so. Uhm. No idea what this source is, but it is wrong. What would be a SIGTERM error? The core X11 protocol (the stuff from xproto.h) has "hardcoded" error numbers. These are errors 1 to 17. The error codes for extensions are dynamically assigned at runtime and need to be looked up with QueryExtension. Example for my current X11 server: $ xdpyinfo -queryExtensions | grep 'base error' DAMAGE (opcode: 143, base event: 91, base error: 152) DOUBLE-BUFFER (opcode: 145, base error: 153) GLX (opcode: 152, base event: 95, base error: 158) MIT-SHM (opcode: 130, base event: 65, base error: 128) RANDR (opcode: 140, base event: 89, base error: 147) RECORD (opcode: 146, base error: 154) RENDER (opcode: 139, base error: 142) SECURITY (opcode: 137, base event: 86, base error: 138) SYNC (opcode: 134, base event: 83, base error: 134) XFIXES (opcode: 138, base event: 87, base error: 140) XFree86-DGA (opcode: 154, base event: 112, base error: 179) XFree86-VidModeExtension (opcode: 153, base error: 172) XInputExtension (opcode: 131, base event: 66, base error: 129) XKEYBOARD (opcode: 135, base event: 85, base error: 137) XVideo (opcode: 151, base event: 93, base error: 155) I now have to check for the highest "base error" that is >= the error code we are interested in. In my case, error 143 would be the base code of RENDER (142) + 1. With this information I can now check what error 1 in the RENDER extension is, which would be BadPicture. I looked this up in xcb-proto's XML description: > I got the error on a 2 window 'app' after the XCB_DESTROY_NOTIFY of the > first window. It appears only after what I'm guessing was a 'complete' > clean up of first window's resources. By this I mean the 'last > reference' to a cairo_surface_t is destroyed. I can comment out the > 'finish/destroy' code to not receive code 143. I also assume I would get > this code on a single window 'app', but don't see because on > XCB_DESTROY_NOTIFY I exit the event loop and disconnect. > If the non-xcb source is to be believed, the 143 SIGTERM is stating the > X-server correctly terminated the 'process' of the first window, and > only resources for the second window remain. > Is this a correct interpretation of signals? Assuming error 143 is also RENDER's BadPicture error code for you, this actually makes sense. Cairo tried to do something, but the window was already destroyed, so the picture for it was destroyed as well. So it causes a BadPicture error. How come you only get XCB_DESTROY_NOTIFY for your window? Normally, one uses the WM_DELETE_WINDOW to get a notification and destroy the window oneself. That way, you can clean up your cairo resources before the window is gone. Cheers, Uli -- ?I?m Olaf and I like warm hugs.? From pheonix.sja at att.net Wed Dec 4 19:00:29 2024 From: pheonix.sja at att.net (Steven J Abner) Date: Wed, 04 Dec 2024 14:00:29 -0500 Subject: XCB_DESTROY_NOTIFY & SIGTERM In-Reply-To: <28fa253a-571e-433c-b3c6-ecde9fa98b43@znc.in> References: <28fa253a-571e-433c-b3c6-ecde9fa98b43@znc.in> Message-ID: On Wed, Dec 4 2024 at 05:32:06 PM +0000, Uli Schlachter wrote: > How come you only get XCB_DESTROY_NOTIFY for your window? Normally, > one uses the WM_DELETE_WINDOW to get a notification and destroy the > window oneself. That way, you can clean up your cairo resources > before the window is gone. On WM_DELETE_WINDOW: /* check transients, appropriate branch */ xcb_unmap_window(connection, window); /* user save stuff, non-transient */ xcb_destroy_window(connection, window); xcb_flush(connection); which yields a XCB_DESTROY_NOTIFY at which point: free/destroy data that was attached to destroy->window (event), from list. But what you are implying is that cairo is wrong in that "The caller owns the surface and should call cairo_surface_destroy() when done with it.", and it's owned by xcb? Easy enuf to move after user save, I think?. Would create 2 locations for resource deletion. Maybe a cairo ownership issue? Insights, on cairo if any? And to both of you, thank you for explanation on how to decrypt generic error :) Steve From psychon at znc.in Wed Dec 4 19:21:45 2024 From: psychon at znc.in (Uli Schlachter) Date: Wed, 4 Dec 2024 20:21:45 +0100 Subject: XCB_DESTROY_NOTIFY & SIGTERM In-Reply-To: References: <28fa253a-571e-433c-b3c6-ecde9fa98b43@znc.in> Message-ID: <81e1e5d2-2b68-423c-bdfe-25463a73baaa@znc.in> Hi, Am 04.12.24 um 20:00 schrieb Steven J Abner: > On Wed, Dec 4 2024 at 05:32:06 PM +0000, Uli Schlachter > wrote: >> How come you only get XCB_DESTROY_NOTIFY for your window? Normally, >> one uses the WM_DELETE_WINDOW to get a notification and destroy the >> window oneself. That way, you can clean up your cairo resources before >> the window is gone. > > On WM_DELETE_WINDOW: > ?/* check transients, appropriate branch */ > xcb_unmap_window(connection, window); > ?/* user save stuff, non-transient */ > xcb_destroy_window(connection, window); > xcb_flush(connection); > which yields a XCB_DESTROY_NOTIFY at which point: > free/destroy data that was attached to destroy->window (event), from list. > > But what you are implying is that cairo is wrong in that "The caller > owns the surface and should call cairo_surface_destroy() when done with > it.", and it's owned by xcb? > Easy enuf to move after user save, I think?. Would create 2 locations > for resource deletion. Maybe a cairo ownership issue? Insights, on cairo > if any? I am not sure about what you are implying with ownership, but (with my cairo hat on), I would claim that you have to (at least) cairo_surface_finish() before the drawable is destroyed. It might also be possible to just flush it, but I would not count on it. Uli P.S.: cairo_surface_destroy() implicitly calls cairo_surface_finish() when the reference count hits zero. -- ?I?m Olaf and I like warm hugs.?