<div dir="ltr"> <div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * 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. </blockquote><div> </div><div>If xcb's design allows you to expose 64-bit seq nb, then it could be a viable solution </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * We still have the unimplemented case throw_thread_fail_assert("Sequence number wrapped " in xcb_io.c line 81. </blockquote><div> Wouldn't that part of become obsolete? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> This can probably also be resolved if we expose 64-bit sequence numbers in the XCB-API. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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. </blockquote><div> 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). </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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:<a href="https://freedesktop.org/patch/16753/" target="_blank">https://freedesktop.org/patch/16753/</a> > latest: <a href="https://freedesktop.org/patch/33513/" target="_blank">https://freedesktop.org/patch/33513/</a> > > 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: > <a href="http://lists.x.org/archives/xorg-devel/2014-August/043661.html" target="_blank">http://lists.x.org/archives/xorg-devel/2014-August/043661.html</a> > > > other references: > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=71338" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=71338</a> > <a href="http://lists.x.org/archives/xorg-devel/2013-October/038370.html" target="_blank">http://lists.x.org/archives/xorg-devel/2013-October/038370.html</a> > <a href="https://freedesktop.org/patch/15500/" target="_blank">https://freedesktop.org/patch/15500/</a> > > best regards, > Jan > > On 4 November 2014 13:55, Christian Linhart <<a href="mailto:chris@demorecorder.com">chris@demorecorder.com</a> <mailto:<a href="mailto:chris@demorecorder.com">chris@demorecorder.com</a>>> 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 <<a href="mailto:patrakov@gmail.com">patrakov@gmail.com</a> <mailto:<a href="mailto:patrakov@gmail.com">patrakov@gmail.com</a>>> 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 <<a href="mailto:smout.jan@gmail.com">smout.jan@gmail.com</a> <mailto:<a href="mailto:smout.jan@gmail.com">smout.jan@gmail.com</a>>> wrote: >>> >>> reminder... >>> >>> On 21 October 2014 12:49, Jan Smout <<a href="mailto:smout.jan@gmail.com">smout.jan@gmail.com</a> <mailto:<a href="mailto:smout.jan@gmail.com">smout.jan@gmail.com</a>>> 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 <<a href="mailto:keithp@keithp.com">keithp@keithp.com</a> <mailto:<a href="mailto:keithp@keithp.com">keithp@keithp.com</a>>> wrote: >>> >>> Matt Turner <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a> <mailto:<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>>> writes: >>> >>> > On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout <<a href="mailto:smout.jan@gmail.com">smout.jan@gmail.com</a> <mailto:<a href="mailto:smout.jan@gmail.com">smout.jan@gmail.com</a>>> 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? >>> >>> -- >>> <a href="mailto:keith.packard@intel.com">keith.packard@intel.com</a> <mailto:<a href="mailto:keith.packard@intel.com">keith.packard@intel.com</a>> >>> >>> >>></blockquote></div> </div></div>