Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
and again... reminder... On 28 October 2014 12:51, Jan Smout smout@gmail.com wrote: reminder... On 21 October 2014 12:49, Jan Smout smout@gmail.com wrote: Keith, we are approaching the one year anniversary of this bug already. Maybe it is time to finish the patch and leave the issue behind? fyi, I have been running my application with the first version of Jonas's patch for 65 days straight now without a glitch (it used to crash in less than 20 hours). I also intend to restart this long duration test once the final patch will be released On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
I already forked it for myself a couple of months ago. As long as I control the packages which get installed on the machines I have no real issue... except for an uncomfortable feeling that if things like this don't get fixed, what other dragons might be hiding deep down in the xlib library? Now, when somebody would want to run the application on their own install, that's where the shit hits the fan. I'll be forced to tell them to downgrade their xlib to 1.3.3 and file a complaint on this list :-) On 4 November 2014 10:49, Alexander E. Patrakov patra...@gmail.com wrote: Just fork it. I am sure that such antisocial step is the only way forward, because I also have a patch that was not looked at for too long, and then rejected because it breaks keystone correction (which was broken in a different way before the patch). 04.11.2014 13:23, Jan Smout wrote: and again... reminder... On 28 October 2014 12:51, Jan Smout smout@gmail.com wrote: reminder... On 21 October 2014 12:49, Jan Smout smout@gmail.com wrote: Keith, we are approaching the one year anniversary of this bug already. Maybe it is time to finish the patch and leave the issue behind? fyi, I have been running my application with the first version of Jonas's patch for 65 days straight now without a glitch (it used to crash in less than 20 hours). I also intend to restart this long duration test once the final patch will be released On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
Hi Christian, thank you for having a look. The original patch is from Jonas Petersen. You will find all necessary information in the links below: orginal:https://freedesktop.org/patch/16753/ latest: https://freedesktop.org/patch/33513/ I got involved just because I happen to have a critical application which is not allowed to crash, let alone after less than 24 hrs: http://lists.x.org/archives/xorg-devel/2014-August/043661.html other references: https://bugs.freedesktop.org/show_bug.cgi?id=71338 http://lists.x.org/archives/xorg-devel/2013-October/038370.html https://freedesktop.org/patch/15500/ best regards, Jan On 4 November 2014 13:55, Christian Linhart ch...@demorecorder.com wrote: Hi Jan, Can you please repost your patch together with a description of the problem and your approach to fix it. I was not subscribed to that list back when you have posted it, and so may some others, who may be able to move this thing forward. You may also post a link to the specific mails/threads in the mailinglist-archives if that'll help with understanding your patch. I'll look at that then. I have some other issues with sequence numbers, and I think we need to solve that on a design level. The essential thing is that the protocol transports only 16-bit sequence numbers, but server and client work with at least 32-bit, sometimes 64-bit sequence numbers. What I've seen so far in the code looks like heuristics which may fail in some cases. Maybe I am missing something. In any case, I want to see your problem analysis and your proposed fix before I propose something. Chris On 11/04/14 13:14, Jan Smout wrote: I already forked it for myself a couple of months ago. As long as I control the packages which get installed on the machines I have no real issue... except for an uncomfortable feeling that if things like this don't get fixed, what other dragons might be hiding deep down in the xlib library? Now, when somebody would want to run the application on their own install, that's where the shit hits the fan. I'll be forced to tell them to downgrade their xlib to 1.3.3 and file a complaint on this list :-) On 4 November 2014 10:49, Alexander E. Patrakov patra...@gmail.com wrote: Just fork it. I am sure that such antisocial step is the only way forward, because I also have a patch that was not looked at for too long, and then rejected because it breaks keystone correction (which was broken in a different way before the patch). 04.11.2014 13:23, Jan Smout wrote: and again... reminder... On 28 October 2014 12:51, Jan Smout smout@gmail.com wrote: reminder... On 21 October 2014 12:49, Jan Smout smout@gmail.com wrote: Keith, we are approaching the one year anniversary of this bug already. Maybe it is time to finish the patch and leave the issue behind? fyi, I have been running my application with the first version of Jonas's patch for 65 days straight now without a glitch (it used to crash in less than 20 hours). I also intend to restart this long duration test once the final patch will be released On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Life is complex, it has a real part and an imaginary part. ___xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
Hi Christian, thank you for having a look. The original patch is from Jonas Petersen. You will find all necessary information in the links below: orginal:https://freedesktop.org/patch/16753/ latest: https://freedesktop.org/patch/33513/ I got involved just because I happen to have a critical application which is not allowed to crash, let alone after less than 24 hrs: http://lists.x.org/archives/xorg-devel/2014-August/043661.html other references: https://bugs.freedesktop.org/show_bug.cgi?id=71338 http://lists.x.org/archives/xorg-devel/2013-October/038370.html https://freedesktop.org/patch/15500/ best regards, Jan On 4 November 2014 13:55, Christian Linhart ch...@demorecorder.com wrote: Hi Jan, Can you please repost your patch together with a description of the problem and your approach to fix it. I was not subscribed to that list back when you have posted it, and so may some others, who may be able to move this thing forward. You may also post a link to the specific mails/threads in the mailinglist-archives if that'll help with understanding your patch. I'll look at that then. I have some other issues with sequence numbers, and I think we need to solve that on a design level. The essential thing is that the protocol transports only 16-bit sequence numbers, but server and client work with at least 32-bit, sometimes 64-bit sequence numbers. What I've seen so far in the code looks like heuristics which may fail in some cases. Maybe I am missing something. In any case, I want to see your problem analysis and your proposed fix before I propose something. Chris On 11/04/14 13:14, Jan Smout wrote: I already forked it for myself a couple of months ago. As long as I control the packages which get installed on the machines I have no real issue... except for an uncomfortable feeling that if things like this don't get fixed, what other dragons might be hiding deep down in the xlib library? Now, when somebody would want to run the application on their own install, that's where the shit hits the fan. I'll be forced to tell them to downgrade their xlib to 1.3.3 and file a complaint on this list :-) On 4 November 2014 10:49, Alexander E. Patrakov patra...@gmail.com wrote: Just fork it. I am sure that such antisocial step is the only way forward, because I also have a patch that was not looked at for too long, and then rejected because it breaks keystone correction (which was broken in a different way before the patch). 04.11.2014 13:23, Jan Smout wrote: and again... reminder... On 28 October 2014 12:51, Jan Smout smout@gmail.com wrote: reminder... On 21 October 2014 12:49, Jan Smout smout@gmail.com wrote: Keith, we are approaching the one year anniversary of this bug already. Maybe it is time to finish the patch and leave the issue behind? fyi, I have been running my application with the first version of Jonas's patch for 65 days straight now without a glitch (it used to crash in less than 20 hours). I also intend to restart this long duration test once the final patch will be released On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Life is complex, it has a real part and an imaginary part. ___xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
* I think we should have xcb expose 64-bit sequence numbers in its API. This can be probably done in a backward compatible way by introducing new functions. The old functions can then be wrappers around the new functions. This needs to be looked at in more detail however. That way, we'll need less workaround-style code in xcb-io.c and the remaining patch will be simpler. Therefore more likely to be correct, and easier to understand. If xcb's design allows you to expose 64-bit seq nb, then it could be a viable solution * We still have the unimplemented case throw_thread_fail_assert(Sequence number wrapped in xcb_io.c line 81. Wouldn't that part of become obsolete? This can probably also be resolved if we expose 64-bit sequence numbers in the XCB-API. I'll need to look into more details of all of this. So far, does anyone have any comments to my comments? Chris P.S: I also have a mission-critical software that must not crash under any circumstances. I still use old non-XCB libX11 from X11R6.9 with some modifications in the most mission-critical component of my application. So this component will not be affected. But some not-so-mission-critical components may be affected. And that's not nice either. So this has rather high priority for me. I'll probably make a new patch which fixes those issues, by making xcb expose 64-bit sequence numbers. This may take some time however because this is a very critical piece of code, so I have to think it through very carefully. Until this is fixed with an official version, I suggest that you either * statically link versions of libX11 and libxcb which work reliably with your application to your application, * or that you ship shared libs which you redirect to by setting LD_LIBRARY_PATH accordingly in the startup-scripts of your application. The LD_LIBRARY_PATH trick would probably work in my case (the first option I'm not sure: the program is dynamically linked to a 3rd party library which links dynamically to libX11). P.P.S.: The 16-bit sequence-number issue which I have mentioned before is a different issue. I have to look into that in more depth, too. On 11/04/14 14:24, Jan Smout wrote: Hi Christian, thank you for having a look. The original patch is from Jonas Petersen. You will find all necessary information in the links below: orginal:https://freedesktop.org/patch/16753/ latest: https://freedesktop.org/patch/33513/ I got involved just because I happen to have a critical application which is not allowed to crash, let alone after less than 24 hrs: http://lists.x.org/archives/xorg-devel/2014-August/043661.html other references: https://bugs.freedesktop.org/show_bug.cgi?id=71338 http://lists.x.org/archives/xorg-devel/2013-October/038370.html https://freedesktop.org/patch/15500/ best regards, Jan On 4 November 2014 13:55, Christian Linhart ch...@demorecorder.com mailto:ch...@demorecorder.com wrote: Hi Jan, Can you please repost your patch together with a description of the problem and your approach to fix it. I was not subscribed to that list back when you have posted it, and so may some others, who may be able to move this thing forward. You may also post a link to the specific mails/threads in the mailinglist-archives if that'll help with understanding your patch. I'll look at that then. I have some other issues with sequence numbers, and I think we need to solve that on a design level. The essential thing is that the protocol transports only 16-bit sequence numbers, but server and client work with at least 32-bit, sometimes 64-bit sequence numbers. What I've seen so far in the code looks like heuristics which may fail in some cases. Maybe I am missing something. In any case, I want to see your problem analysis and your proposed fix before I propose something. Chris On 11/04/14 13:14, Jan Smout wrote: I already forked it for myself a couple of months ago. As long as I control the packages which get installed on the machines I have no real issue... except for an uncomfortable feeling that if things like this don't get fixed, what other dragons might be hiding deep down in the xlib library? Now, when somebody would want to run the application on their own install, that's where the shit hits the fan. I'll be forced to tell them to downgrade their xlib to 1.3.3 and file a complaint on this list :-) On 4 November 2014 10:49, Alexander E. Patrakov patra...@gmail.com mailto:patra...@gmail.com wrote: Just fork it. I am sure that such antisocial step is the only way forward, because I also have a patch that was not looked at for too long, and then rejected because it breaks keystone correction (which was broken in a different way before the patch). 04.11.2014 13:23, Jan Smout wrote: and again
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
reminder... On 21 October 2014 12:49, Jan Smout smout@gmail.com wrote: Keith, we are approaching the one year anniversary of this bug already. Maybe it is time to finish the patch and leave the issue behind? fyi, I have been running my application with the first version of Jonas's patch for 65 days straight now without a glitch (it used to crash in less than 20 hours). I also intend to restart this long duration test once the final patch will be released On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
Keith, we are approaching the one year anniversary of this bug already. Maybe it is time to finish the patch and leave the issue behind? fyi, I have been running my application with the first version of Jonas's patch for 65 days straight now without a glitch (it used to crash in less than 20 hours). I also intend to restart this long duration test once the final patch will be released On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
I also spent some time trying to assess all possible cases (with very limited knowledge on xlib internals), and I'm pretty sure Jonas has dedicated even more time than the both of us did, but that's not the issue here. I agree the patch is hard, and maybe a more satisfactory solution could be imagined by redesigning the 32-bit sequence numbers so that it aligns better with xcb, but at some point a decision needs to be taken. In that sense it *is* probably better to push the patch than to leave the current situation as is where the application program just simply crashes... On 27 September 2014 05:23, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote: Keith Packard doesn't seem very responsive (as in 'completely ignoring the subject') Perhaps you should try Ccing him? (now Cc'd) The problem is that reviewing this patch is *really hard*. The last time, I think I spent a solid couple of days thinking about this and making sure I'd caught all of the cases. I'm still not sure it's right, but I guess it's probably better than what we have? -- keith.pack...@intel.com -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues
Keith Packard doesn't seem very responsive (as in 'completely ignoring the
subject')
Thank you for persisting, Jonas.
On 24 September 2014 21:13, Jonas Petersen jnsptr...@gmail.com wrote:
By design, on 32-bit systems, the Xlib internal 32-bit request sequence
numbers may wrap. There is some locations within xcb_io.c that are not
wrap-safe though. The value of last_flushed relies on request to be
sequential all the time. This is not given in the moment when the
sequence has just wrapped. Applications may then crash with a
Fatal IO error 11 (Resource temporarily unavailable).
This patch fixes this by unwrapping the sequence number when needed to
retain the sequence relative to last_flushed. It also contains some
additional optimizations.
Signed-off-by: Jonas Petersen jnsptr...@gmail.com
---
src/Xxcbint.h | 2 +-
src/xcb_io.c | 27 +--
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/src/Xxcbint.h b/src/Xxcbint.h
index bf41c23..feee775 100644
--- a/src/Xxcbint.h
+++ b/src/Xxcbint.h
@@ -31,7 +31,7 @@ typedef struct _X11XCBPrivate {
char *reply_data;
int reply_length;
int reply_consumed;
- uint64_t last_flushed;
+ unsigned long last_flushed;
enum XEventQueueOwner event_owner;
XID next_xid;
diff --git a/src/xcb_io.c b/src/xcb_io.c
index 5987329..03af1f9 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -59,15 +59,19 @@ static void require_socket(Display *dpy)
{
if(dpy-bufmax == dpy-buffer)
{
- uint64_t sent;
+ uint64_t sent64;
+ unsigned long sent;
int flags = 0;
/* if we don't own the event queue, we have to ask XCB
* to set our errors aside for us. */
if(dpy-xcb-event_owner != XlibOwnsEventQueue)
flags = XCB_REQUEST_CHECKED;
if(!xcb_take_socket(dpy-xcb-connection, return_socket,
dpy,
- flags, sent))
+ flags, sent64))
_XIOError(dpy);
+
+ sent = sent64;
+
/* Xlib uses unsigned long for sequence numbers. XCB
* uses 64-bit internally, but currently exposes an
* unsigned int API. If these differ, Xlib cannot track
@@ -77,7 +81,7 @@ static void require_socket(Display *dpy)
* 64-bit sequence numbers. */
if (sizeof(unsigned long) sizeof(unsigned int)
dpy-xcb-event_owner == XlibOwnsEventQueue
- (sent - dpy-last_request_read = (UINT64_C(1)
32))) {
+ (long) (sent - dpy-last_request_read) 0) {
throw_thread_fail_assert(Sequence number wrapped
beyond 32 bits while
Xlib
did not own the socket,
@@ -455,7 +459,7 @@ void _XSend(Display *dpy, const char *data, long size)
static const xReq dummy_request;
static char const pad[3];
struct iovec vec[3];
- uint64_t requests;
+ uint64_t requests, unwrapped_request;
_XExtension *ext;
xcb_connection_t *c = dpy-xcb-connection;
if(dpy-flags XlibDisplayIOError)
@@ -464,6 +468,13 @@ void _XSend(Display *dpy, const char *data, long size)
if(dpy-bufptr == dpy-buffer !size)
return;
+ unwrapped_request = dpy-request;
+ /* If there was a sequence number wrap since our last flush,
+* make sure the sequence number we use, stays in sequence
+* with dpy-xcb-last_flush. */
+ if (sizeof(uint64_t) sizeof(unsigned long) dpy-request
dpy-xcb-last_flushed)
+ unwrapped_request += UINT64_C(1) 32;
+
/* iff we asked XCB to set aside errors, we must pick those up
* eventually. iff there are async handlers, we may have just
* issued requests that will generate replies. in either case,
@@ -471,10 +482,14 @@ void _XSend(Display *dpy, const char *data, long
size)
if(dpy-xcb-event_owner != XlibOwnsEventQueue ||
dpy-async_handlers)
{
uint64_t sequence;
- for(sequence = dpy-xcb-last_flushed + 1; sequence =
dpy-request; ++sequence)
+ for(sequence = (uint64_t) dpy-xcb-last_flushed + 1;
sequence = unwrapped_request; ++sequence)
+ /* On systems where unsigned long is 32 bits, the
64-bit sequence
+* passed to append_pending_request might get
trimmed off.
+* This is logically correct and expected, as it's
simply
+* 're-wrapping' the 'unwrapped' sequence number.
*/
append_pending_request(dpy, sequence);
}
- requests = dpy-request -
libX11: 32-bit request number wrapping bug
Hello Keith, Trying one more time with a changed subject line... On 20 August 2014 14:19, Jan Smout smout@gmail.com wrote: Dear Keith, thought I'd ping you again. Please fix your spam filter! Regarding this patch: http://patchwork.freedesktop.org/patch/16753/ my question is very simple: is this patch good enough to be put in a distro release? Or are there things to be clarified? I'm trying to get it into the upcoming Mageia 5 release (I assume it will be released before Xorg releases it's next libX11 version) I cannot stress enough the seriousness of this bug. An application that gets killed by a library without any way to recover is not something to be taken lightly. In a certain sense I got lucky that my app is so heavy on graphics, so I was able to find a solution rather quickly (as did Jonas btw). I suspect most people just see (seemingly) random crashes, shrug and restart whatever they were running and then blame the application programmer for writing shitty software. I find that hard to accept... best regards, Jan On 6 August 2014 17:14, Jan Smout smout@gmail.com wrote: Hello Keith, my previous mails probably got lost in the noise. Please see my question below: On 29 July 2014 18:56, Jan Smout smout@gmail.com wrote: Hi all, I recently stumbled into an application that crashed because of this: https://bugs.freedesktop.org/show_bug.cgi?id=71338 and quickly found the following patch: http://patchwork.freedesktop.org/patch/16753/ which seems to work fine (the application used to crash in less than 24 hrs. Has been running for 5 days straight with the patch). Now my question: what is the status of this patch? Are there still details to be clarified before it can be put into the main tree? best regards, Jan -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] [PATCH libX11] xcb_io: Fix Xlib 32-bit request number wrapping bug
Dear Keith, thought I'd ping you again. Please fix your spam filter! Regarding this patch: http://patchwork.freedesktop.org/patch/16753/ my question is very simple: is this patch good enough to be put in a distro release? Or are there things to be clarified? I'm trying to get it into the upcoming Mageia 5 release (I assume it will be released before Xorg releases it's next libX11 version) I cannot stress enough the seriousness of this bug. An application that gets killed by a library without any way to recover is not something to be taken lightly. In a certain sense I got lucky that my app is so heavy on graphics, so I was able to find a solution rather quickly (as did Jonas btw). I suspect most people just see (seemingly) random crashes, shrug and restart whatever they were running and then blame the application programmer for writing shitty software. I find that hard to accept... best regards, Jan On 6 August 2014 17:14, Jan Smout smout@gmail.com wrote: Hello Keith, my previous mails probably got lost in the noise. Please see my question below: On 29 July 2014 18:56, Jan Smout smout@gmail.com wrote: Hi all, I recently stumbled into an application that crashed because of this: https://bugs.freedesktop.org/show_bug.cgi?id=71338 and quickly found the following patch: http://patchwork.freedesktop.org/patch/16753/ which seems to work fine (the application used to crash in less than 24 hrs. Has been running for 5 days straight with the patch). Now my question: what is the status of this patch? Are there still details to be clarified before it can be put into the main tree? best regards, Jan -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] [PATCH libX11] xcb_io: Fix Xlib 32-bit request number wrapping bug
Hi Jonas,
the reason I am asking this is that I'm trying to push the patch into the
Mageia xlib package - mainly because it is the candidate for putting
realtime applications the next coming 6/7 years. The requirements are
quite strong: it needs to run 24/7 and is heavy on graphics (one of them
would crash after less than 24 hrs).
Now, even though the application is entirely under my control, the compiler
is not, so I'm stuck with a deprecated 32-bit compiler for this iteration
(before migrating to another compiler).
Now, I had already traced it down to xlib and was traversing the library
code when I found that you had already went down that road. I reviewed your
patch and - provided there are no other hidden dragons - found that it
worked as advertised (using XNoOp as proof of concept and by running my
app). Thanks for the good work btw.
Regarding the seriousness I completely agree. It is an important bug. Other
applications might crash after weeks or months, in which case users will
have a hard time understanding why and might conclude the OS is not
stable or anything.
Anyway, for my apps I have no problem - we have custom installs anyways -
but other people might...
So, the only question I have for Keith is: is the patch good enough to be
put into an official linux distribution, while the next xlib release has
not yet been released?
best regards,
Jan
On Aug 6, 2014 10:49 PM, Jonas Petersen jnsptr...@gmail.com wrote:
Hi Jan,
thanks for pushing this.
I spent really a lot of time (weeks) tracking this down and finding a
solution. Digging down the depths of the operating system, while actually
writting application software. The result is the mentioned patch. I then
posted it here. I think there is approval that the fix actually does work.
Then there was starting some discussion about implementation details,
optimization and possible further problems at other locations.
At some point I had to take a break, since this had cost me already so
much time. Sorry about that. It's to bad this is still pending.
If nothing happens I might be willing to spend another small amount of
time to help completing this. But my time is limited. I can not promise
anything.
I think this bug is quite serious. It suddenly kills programs without
asking out of nowhere. And it's patient.
By the way, my software now runs on 64-bit, so luckily I'm not affected
anymore (hopefully). But there's probably still plenty of 32-bit systems
endangered by this.
Have you seen? Keith posted a program to reproduce the bug (or confirm
that the patch works) as fast as possible:
/* cc -o nop nop.c `pkg-config --cflags --libs x11` */
#includestdio.h
#includestdint.h
#includeX11/Xlib.h
int
main (int argc, char **argv)
{
uint64_ti = 0;
Display *dpy = XOpenDisplay(NULL);
for (;;) {
++i;
if ((i 0xfff) == 0) {
XFlush(dpy);
printf (0x%llx\n, i);
}
XNoOp(dpy);
}
}
Regards
Jonas
Am 29.07.2014 um 18:56 schrieb Jan Smout:
Hi all,
I recently stumbled into an application that crashed because of this:
https://bugs.freedesktop.org/show_bug.cgi?id=71338
and quickly found the following patch:
http://patchwork.freedesktop.org/patch/16753/
which seems to work fine (the application used to crash in less than 24
hrs. Has been running for 5 days straight with the patch).
Now my question: what is the status of this patch? Are there still details
to be clarified before it can be put into the main tree?
best regards,
Jan
--
Life is complex, it has a real part and an imaginary part.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xcb_io: Fix Xlib 32-bit request number wrapping bug
Hello, can somebody have a look at my question below please? thanks, On 31 July 2014 18:05, Jan Smout smout@gmail.com wrote: Hello again, just thought I should ask again. Probably the message got lost in the noise ;-) On 29 July 2014 18:56, Jan Smout smout@gmail.com wrote: Hi all, I recently stumbled into an application that crashed because of this: https://bugs.freedesktop.org/show_bug.cgi?id=71338 and quickly found the following patch: http://patchwork.freedesktop.org/patch/16753/ which seems to work fine (the application used to crash in less than 24 hrs. Has been running for 5 days straight with the patch). Now my question: what is the status of this patch? Are there still details to be clarified before it can be put into the main tree? best regards, Jan -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] [PATCH libX11] xcb_io: Fix Xlib 32-bit request number wrapping bug
Hello Keith, my previous mails probably got lost in the noise. Please see my question below: On 29 July 2014 18:56, Jan Smout smout@gmail.com wrote: Hi all, I recently stumbled into an application that crashed because of this: https://bugs.freedesktop.org/show_bug.cgi?id=71338 and quickly found the following patch: http://patchwork.freedesktop.org/patch/16753/ which seems to work fine (the application used to crash in less than 24 hrs. Has been running for 5 days straight with the patch). Now my question: what is the status of this patch? Are there still details to be clarified before it can be put into the main tree? best regards, Jan -- Life is complex, it has a real part and an imaginary part. -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xcb_io: Fix Xlib 32-bit request number wrapping bug
Hello again, just thought I should ask again. Probably the message got lost in the noise ;-) On 29 July 2014 18:56, Jan Smout smout@gmail.com wrote: Hi all, I recently stumbled into an application that crashed because of this: https://bugs.freedesktop.org/show_bug.cgi?id=71338 and quickly found the following patch: http://patchwork.freedesktop.org/patch/16753/ which seems to work fine (the application used to crash in less than 24 hrs. Has been running for 5 days straight with the patch). Now my question: what is the status of this patch? Are there still details to be clarified before it can be put into the main tree? best regards, Jan -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] [PATCH libX11] xcb_io: Fix Xlib 32-bit request number wrapping bug
Hi all, I recently stumbled into an application that crashed because of this: https://bugs.freedesktop.org/show_bug.cgi?id=71338 and quickly found the following patch: http://patchwork.freedesktop.org/patch/16753/ which seems to work fine (the application used to crash in less than 24 hrs. Has been running for 5 days straight with the patch). Now my question: what is the status of this patch? Are there still details to be clarified before it can be put into the main tree? best regards, Jan -- Life is complex, it has a real part and an imaginary part. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
