apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.

StacktraceTop:raise () from /lib/libc.so.6
abort () from /lib/libc.so.6
__assert_fail () from /lib/libc.so.6
process_responses (dpy=0x248ae40,
_XEventsQueued (dpy=0x248ae40,

This hardly looks like a bug in apport itself, more likely in pyqt or libxcb. Anyway, do you have a recipe how to reproduce this? What did you do exactly and how far did you get?

This is a daily occurance.

Firefox crashed, apport tried to report the bug and it crashed itself,
leading to around 30 some odd apport-kde instances running. Each
instance consumes 2.6 or 2.7% of 1.5G of ram.

It normally happens about twice a day, though today it's crashed four
times this morning alone and once required a reboot.

All I do is click to send bug reports.

Dennis Stout

On Wed, Sep 2, 2009 at 10:52 AM, Martin Pitt<email address hidden> wrote:
> This hardly looks like a bug in apport itself, more likely in pyqt or
> libxcb. Anyway, do you have a recipe how to reproduce this? What did you
> do exactly and how far did you get?
>
> ** Changed in: apport (Ubuntu)
>       Status: Confirmed => Incomplete
>
> --
> apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> https://bugs.launchpad.net/bugs/419501
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “apport” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: apport
>
> Description:    Ubuntu karmic (development branch)
> Release:        9.10
>
> ProblemType: Crash
> Architecture: amd64
> AssertionMessage: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> CrashCounter: 1
> Date: Wed Aug 26 16:14:40 2009
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/share/apport/apport-kde
> InterpreterPath: /usr/bin/python2.6
> NonfreeKernelModules: nvidia
> Package: apport-kde 1.8-0ubuntu1
> PackageArchitecture: all
> ProcCmdline: /usr/bin/python /usr/share/apport/apport-kde
> ProcEnviron:
>  PATH=(custom, no user)
>  LANG=en_US.UTF-8
>  LANGUAGE=
>  SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
> Signal: 6
> SourcePackage: apport
> StacktraceTop:
>  raise () from /lib/libc.so.6
>  abort () from /lib/libc.so.6
>  __assert_fail () from /lib/libc.so.6
>  ?? () from /usr/lib/libX11.so.6
>  _XEventsQueued () from /usr/lib/libX11.so.6
> Title: apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> Uname: Linux 2.6.31-3-generic x86_64
> UserGroups:
>

This happened to me when some updates were running. Not sure if apport-kde was among them. Suddenly it apport-kde asked for password twice, at same time. Following that it got this crash.

I didn't "do" anything other than tell KPackageKit to install the 200+ updates
which were waiting (and took all (^)(*&)(*&ing day to pull down) Part way
through it started gagging. I then used Synaptic to fix the packages
KPackageKit broke (none were broke before the updates started) and apply the
updates.

On Wednesday 02 September 2009 10:52:37 am Martin Pitt wrote:
> This hardly looks like a bug in apport itself, more likely in pyqt or
> libxcb. Anyway, do you have a recipe how to reproduce this? What did you
> do exactly and how far did you get?
>
> ** Changed in: apport (Ubuntu)
> Status: Confirmed => Incomplete
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

Could be related to bug 405378

Yuriy, indeed, seems that these two are duplicates.

This is not related to bug 405378. This crash occurs in various other programs.

This bug is also affecting other packages, such as python-gasp (in bug 409001). The reproduction steps in there are simple, run the following in a python interpreter:
>>> import gasp
>>> gasp.begin_graphics()

I am also getting several apport-kde crashes when something else crashes, the latest one with the message of the title. most make them unable to send reports in about the crash.

same problem on i386

I have this problem on amd64.
It occured while a submitting a bug with no debug information (no stacktrace) on kwin.

Is it possible that this only affects me when attempting to checkout a subversion repository in netbeans?

Also have the same problem on Karmic - amd64, but I can give no further information.

I tried to file a bug report on a fatal error in karmic (both amd64 and i386) for the package python-gasp. The reply came that it is a duplicate of this bug. To reproduce it:

1. sudo apt-get install python-gasp (from universe)
2. from a python shell:
>>> from gasp import *
>>> begin_graphics()

This will cause python to die and give a core dump.

This bug effects gasp on Fedora 12 as well. Also, it appears to involve changes other than just libxcb. When libxcd 1.2-4 (the one from Fedora 11, on which gasp runs without problems), is installed on Fedora 12, the same problem occurs.

This happened to me in Kubuntu Karmic 9.10 on amd64 after reporting two other crashes

Me too, Kubuntu Karmic 9.10 on amd64, same as Patrick Dawkins. I get two or three apport alerts every time I resume from standby that all request sudo, then I get a bunch more KDESudo alerts, then I kill most of them because my system is reduced to a crawl with all the "Collecting data" windows, finally get to reporting to one of them, but then apport-kde itself crashes. Agggh.

And the bugs.launchpad "Yes, this is the bug I'm trying to report" dialog fails in Konqueror, the green checkmark doesn't do anything. Aggggggggggh.

That's exactly the string of events that happened to me, minus the
"every time I resume" bit. It would happen to me for no patterned
reason.

Eric

On Sun, Nov 1, 2009 at 3:45 PM, skierpage <email address hidden> wrote:
> Me too, Kubuntu Karmic 9.10 on amd64, same as Patrick Dawkins.  I get
> two or three apport alerts every time I resume from standby that all
> request sudo, then I get a bunch more KDESudo alerts, then I kill most
> of them because my system is reduced to a crawl with all the "Collecting
> data" windows, finally get to reporting to one of them, but then apport-
> kde itself crashes.  Agggh.
>
> And the bugs.launchpad "Yes, this is the bug I'm trying to report"
> dialog fails in Konqueror,  the green checkmark doesn't do anything.
> Aggggggggggh.
>
> --
> apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> https://bugs.launchpad.net/bugs/419501
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in GASP Core Code: New
> Status in “libxcb” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: apport
>
> Description:    Ubuntu karmic (development branch)
> Release:        9.10
>
> ProblemType: Crash
> Architecture: amd64
> AssertionMessage: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> CrashCounter: 1
> Date: Wed Aug 26 16:14:40 2009
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/share/apport/apport-kde
> InterpreterPath: /usr/bin/python2.6
> NonfreeKernelModules: nvidia
> Package: apport-kde 1.8-0ubuntu1
> PackageArchitecture: all
> ProcCmdline: /usr/bin/python /usr/share/apport/apport-kde
> ProcEnviron:
>  PATH=(custom, no user)
>  LANG=en_US.UTF-8
>  LANGUAGE=
>  SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
> Signal: 6
> SourcePackage: apport
> StacktraceTop:
>  raise () from /lib/libc.so.6
>  abort () from /lib/libc.so.6
>  __assert_fail () from /lib/libc.so.6
>  ?? () from /usr/lib/libX11.so.6
>  _XEventsQueued () from /usr/lib/libX11.so.6
> Title: apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> Uname: Linux 2.6.31-3-generic x86_64
> UserGroups:
>

Bryce, Jeff Elkner escalated this bug to me and I think it's worth a closer look given the widespread impact. Can you comment on the likely cause? Seems easy to reproduce.

I have no further information. I have recently updated to everything current
and it appears the work around now is for Apport to absolutely refuse to file
any bug unless you click on "Yes" you can provide step by step instructions
for reproduction. I have had 9 such crashes in less than 24 hours since the
upgrade. I only know of _one_ product which was behind such a crash and that
was Kontact. All of the others were mystery package failures.

On Saturday 07 November 2009 04:43:02 pm Mark Shuttleworth wrote:
> Bryce, Jeff Elkner escalated this bug to me and I think it's worth a
> closer look given the widespread impact. Can you comment on the likely
> cause? Seems easy to reproduce.
>

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.logikalsolutions.com

bump

Hello everybody,

it is hard to give the root cause for this bug.

It appears quite frequently, e.g. after rebooting.
So I suspect it has to do with KDE/plasma startup.
The Device (USB Stick) notification mechanism could be involved as well.

Note: My Kubuntu system was upgraded - not freshly installed.

Let me know if I can do anything to further analyze the problem - it's
quite annoying.

Thanks

Christian

seasoned_geek schrieb:
> I have no further information. I have recently updated to everything current
> and it appears the work around now is for Apport to absolutely refuse to file
> any bug unless you click on "Yes" you can provide step by step instructions
> for reproduction. I have had 9 such crashes in less than 24 hours since the
> upgrade. I only know of _one_ product which was behind such a crash and that
> was Kontact. All of the others were mystery package failures.
>
>
> On Saturday 07 November 2009 04:43:02 pm Mark Shuttleworth wrote:
>
>> Bryce, Jeff Elkner escalated this bug to me and I think it's worth a
>> closer look given the widespread impact. Can you comment on the likely
>> cause? Seems easy to reproduce.
>>
>>
>
>

In the light of that opinion, I'll toss in that plasma frequently
crashes on my system with an error that says something along the lines
of "we were being asked to do too much and we lost track of what we
were trying to do, so here's a pair of lips going *plblblblblblblb*".

Also, I thought it was an unrelated hardware problem, but on
infrequent occasions (once a month or so) my system will suddenly stop
recognising anything USB. I ignored it as an unrelated hardware
problem because one of the reviews for the chassis I have specifically
stated "due to the riser slot design and case air flow dynamics, heat
tends to build up around the support bar and slowly edges the card out
of the slot. This eventually causes a large volume of trash to be
tossed out over the PCI bus confusing the USB host enough to make it
commit suicide."

Granted I don't know exactly which motherboard the guy used, nor even
what OS, but I am using a fairly popular motherboard for HTPC systems
and it's an HTPC specific case, so the probability we're using the
same motherboard is decently high (5 or 8% likely).

Habst du ein Guten Tag,
Eric

On Sun, Nov 8, 2009 at 3:18 PM, cparg <email address hidden> wrote:
> Hello everybody,
>
> it is hard to give the root cause for this bug.
>
> It appears quite frequently, e.g. after rebooting.
> So I suspect it has to do with KDE/plasma startup.
> The Device (USB Stick) notification mechanism could be involved as well.
>
> Note: My Kubuntu system was upgraded - not freshly installed.
>
> Let me know if I can do anything to further analyze the problem - it's
> quite annoying.
>
> Thanks
>
> Christian
>
>
> seasoned_geek schrieb:
>> I have no further information.  I have recently updated to everything current
>> and it appears the work around now is for Apport to absolutely refuse to file
>> any bug unless you click on "Yes" you can provide step by step instructions
>> for reproduction.  I have had 9 such crashes in less than 24 hours since the
>> upgrade.  I only know of _one_ product which was behind such a crash and that
>> was Kontact.  All of the others were mystery package failures.
>>
>>
>> On Saturday 07 November 2009 04:43:02 pm Mark Shuttleworth wrote:
>>
>>> Bryce, Jeff Elkner escalated this bug to me and I think it's worth a
>>> closer look given the widespread impact. Can you comment on the likely
>>> cause? Seems easy to reproduce.
>>>
>>>
>>
>>
>
> --
> apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> https://bugs.launchpad.net/bugs/419501
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in GASP Core Code: New
> Status in “libxcb” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: apport
>
> Description:    Ubuntu karmic (development branch)
> Release:        9.10
>
> ProblemType: Crash
> Architecture: amd64
> AssertionMessage: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
> CrashCounter: 1
> Date: Wed Aug 26 16:14:40 2009
> DistroRelease: Ubuntu 9.10
> Execu...

On Sun, Nov 8, 2009 at 16:18, cparg <email address hidden> wrote:

> it is hard to give the root cause for this bug.

The root cause for the bug is probably not any hardware issue. This is a bug
that has a very simple testcase and affects multiple applications, and is a
bug in libxcb or one of its dependents.

--
Luke Faraone
http://luke.faraone.cc

you need to install libqt4-dbg and get a new backtrace, the current one is not complete enough.

I just submitted bug #518269, in which this same error is seen in a PyGTK application. I don't know if it is the same bug as this one. But I did manage to put together a rather simple test case. If these turn out to be the same bug, please mark mine as a duplicate.

Here is the test case that I originally posted in #518269. It is a PyGTK app with a vte Terminal. It uses forkpty() to create a child process inside the terminal. That child process dies with this assertion error when it reaches the raw_input() statement. (Actually, it seems to need some action, a mouse movement or keypress, before the error is thrown.) The parent process survives.

This error occurs in an up-to-date Karmic install, but not on Jaunty. Perhaps someone can try it on Lucid?

The nominations may not be appropriate. Please investigate and fix as appropriate.

I don't know if this helps or not, but I've found a work-around for my test case. The trick is to hold off on importing gtk and vte until after the child process forks off. I'm guessing that the error is due to two separate processes holding the same objects. (This affects both gtk and vte, but I suspect the problem with vte is that it imports gtk within itself.)

Unfortunately, this is likely not a feasible solution for most real cases. If the fork is triggered by some user action, the UI must be up before the fork. I tried to delete all references to the module in the child process, but that didn't work. Some online sources claim that this will only work for pure python modules; I'm guessing that GTK isn't.

I want to emphasize that my test case does not fail on Jaunty. Is there any evidence of this bug prior to Karmic?

Simple test case for many xcb-based libX11 bugs:

ico -threads 10

You will likely get a deadlock, "_XAllocID: Assertion `ret != inval_id' failed." or the error mentioned here.

Locally we have problems with any X program that uses multi-threading since the switch to libxcb X11. Sometimes one or two bugs will be fixed but then others will turn up. We have resorted to maintaining our own compile of pre-xcb libX11 in order to make our in-house programs reliable.

At this point I think libxcb libX11 is a failed experiment. If the threading bugs haven't been fixed after a couple years now, will they ever be? Should we simply revert to the old libX11? Last time this was suggested the answer was that compiz depended on xcb, but is some desktop eye-candy really more important than real applications working that people use to get real work done?

Someone found the root cause of another of these bugs recently, so maybe there is hope:
http://lists.freedesktop.org/archives/xcb/2009-October/005102.html

Hey,

    Sorry I haven't had any free time to work on this and it doesn't look
like I'm going to have any time until spring break. That's only a week and
a half away and I should be able to spend a lot of time on this then. I'm
not sure if I'll be back in Arlington or not, but I should have plenty of
time to do my best to fix this by March 15th, when Luke said we needed to
have something done. I hope this is acceptable, I just don't have any time
between school and pledging.

Jamie

On Tue, Feb 23, 2010 at 9:05 AM, Michael Babcock <email address hidden> wrote:

> Simple test case for many xcb-based libX11 bugs:
>
> ico -threads 10
>
> You will likely get a deadlock, "_XAllocID: Assertion `ret != inval_id'
> failed." or the error mentioned here.
>
> Locally we have problems with any X program that uses multi-threading
> since the switch to libxcb X11. Sometimes one or two bugs will be fixed
> but then others will turn up. We have resorted to maintaining our own
> compile of pre-xcb libX11 in order to make our in-house programs
> reliable.
>
> At this point I think libxcb libX11 is a failed experiment. If the
> threading bugs haven't been fixed after a couple years now, will they
> ever be? Should we simply revert to the old libX11? Last time this was
> suggested the answer was that compiz depended on xcb, but is some
> desktop eye-candy really more important than real applications working
> that people use to get real work done?
>
> Someone found the root cause of another of these bugs recently, so maybe
> there is hope:
> http://lists.freedesktop.org/archives/xcb/2009-October/005102.html
>
> --
> apport-kde assert failure: python: ../../src/xcb_io.c:242:
> process_responses: Assertion `(((long) (dpy->last_request_read) - (long)
> (dpy->request)) <= 0)' failed.
> https://bugs.launchpad.net/bugs/419501
> You received this bug notification because you are subscribed to GASP
> Core.
>
> Status in GASP Core Code: Confirmed
> Status in “libxcb” package in Ubuntu: Confirmed
> Status in “libxcb” source package in Lucid: Confirmed
>
> Bug description:
> Binary package hint: apport
>
> Description: Ubuntu karmic (development branch)
> Release: 9.10
>
> ProblemType: Crash
> Architecture: amd64
> AssertionMessage: python: ../../src/xcb_io.c:242: process_responses:
> Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)'
> failed.
> CrashCounter: 1
> Date: Wed Aug 26 16:14:40 2009
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/share/apport/apport-kde
> InterpreterPath: /usr/bin/python2.6
> NonfreeKernelModules: nvidia
> Package: apport-kde 1.8-0ubuntu1
> PackageArchitecture: all
> ProcCmdline: /usr/bin/python /usr/share/apport/apport-kde
> ProcEnviron:
> PATH=(custom, no user)
> LANG=en_US.UTF-8
> LANGUAGE=
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
> Signal: 6
> SourcePackage: apport
> StacktraceTop:
> raise () from /lib/libc.so.6
> abort () from /lib/libc.so.6
> __assert_fail () from /lib/libc.so.6
> ?? () from /usr/lib/libX11.so.6
> _XEventsQueued () from /usr/lib/libX11.so.6
> Title: apport-kde assert failure: python: ../../src/xcb_io.c:242:
> process_responses: Assertion `(((l...

Pledging and partying are a lot more important. You are only young once!

On Tuesday 23 February 2010 07:32:34 pm jboisture wrote:
> Hey,
>
> Sorry I haven't had any free time to work on this and it doesn't look
> like I'm going to have any time until spring break. That's only a week and
> a half away and I should be able to spend a lot of time on this then. I'm
> not sure if I'll be back in Arlington or not, but I should have plenty of
> time to do my best to fix this by March 15th, when Luke said we needed to
> have something done. I hope this is acceptable, I just don't have any time
> between school and pledging.
>
> Jamie
>
> On Tue, Feb 23, 2010 at 9:05 AM, Michael Babcock <email address hidden> wrote:
> > Simple test case for many xcb-based libX11 bugs:
> >
> > ico -threads 10
> >
> > You will likely get a deadlock, "_XAllocID: Assertion `ret != inval_id'
> > failed." or the error mentioned here.
> >
> > Locally we have problems with any X program that uses multi-threading
> > since the switch to libxcb X11. Sometimes one or two bugs will be fixed
> > but then others will turn up. We have resorted to maintaining our own
> > compile of pre-xcb libX11 in order to make our in-house programs
> > reliable.
> >
> > At this point I think libxcb libX11 is a failed experiment. If the
> > threading bugs haven't been fixed after a couple years now, will they
> > ever be? Should we simply revert to the old libX11? Last time this was
> > suggested the answer was that compiz depended on xcb, but is some
> > desktop eye-candy really more important than real applications working
> > that people use to get real work done?
> >
> > Someone found the root cause of another of these bugs recently, so maybe
> > there is hope:
> > http://lists.freedesktop.org/archives/xcb/2009-October/005102.html
> >
> > --
> > apport-kde assert failure: python: ../../src/xcb_io.c:242:
> > process_responses: Assertion `(((long) (dpy->last_request_read) - (long)
> > (dpy->request)) <= 0)' failed.
> > https://bugs.launchpad.net/bugs/419501
> > You received this bug notification because you are subscribed to GASP
> > Core.
> >
> > Status in GASP Core Code: Confirmed
> > Status in “libxcb” package in Ubuntu: Confirmed
> > Status in “libxcb” source package in Lucid: Confirmed
> >
> > Bug description:
> > Binary package hint: apport
> >
> > Description: Ubuntu karmic (development branch)
> > Release: 9.10
> >
> > ProblemType: Crash
> > Architecture: amd64
> > AssertionMessage: python: ../../src/xcb_io.c:242: process_responses:
> > Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <=
> > 0)' failed.
> > CrashCounter: 1
> > Date: Wed Aug 26 16:14:40 2009
> > DistroRelease: Ubuntu 9.10
> > ExecutablePath: /usr/share/apport/apport-kde
> > InterpreterPath: /usr/bin/python2.6
> > NonfreeKernelModules: nvidia
> > Package: apport-kde 1.8-0ubuntu1
> > PackageArchitecture: all
> > ProcCmdline: /usr/bin/python /usr/share/apport/apport-kde
> > ProcEnviron:
> > PATH=(custom, no user)
> > LANG=en_US.UTF-8
> > LANGUAGE=
> > SHELL=/bin/bash
> > ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
> > Signal: 6
> > SourcePackage: apport
> > StacktraceTop:
> > ...

Just remember, the point of spring break is to TAKE A BREAK.

has anyone tried to reproduce this on lucid?

On lucid I have the problem with any program I am stopping with an click on the x. Seems that more programs are sharing the seem process and than have an collision.

> has anyone tried to reproduce this on lucid?

I just tried the test case and got the same error as before. (Although now, it's caught by apport, so I have to wait for that think before I can see the problem. Progress!) This is on a VM image of lucid that is about 2 weeks old. libxcb isn't listed in the available updates, but if you have reason to believe this has been fixed through another package, let me know and I'll try it on an up-to-date image.

The testcase still fails on the daily ISO.

 unsubscribe

This bug was fixed in the package python-gasp - 0.3.3-0ubuntu1

---------------
python-gasp (0.3.3-0ubuntu1) lucid; urgency=low

  * New upstream release. (LP: #419501)
 -- Luke Faraone <email address hidden> Fri, 12 Mar 2010 09:19:17 -0500

There has recently been work done upstream to fix these sort of bugs. I've pushed some testing packages incorporating these fixes to https://edge.launchpad.net/~raof/+archive/aubergine/+packages.

These changes look pretty extensive, so it might not be possible to push an SRU fixing this, but it would be good to get some testing.

Chris Halse Rogers wrote:
> There has recently been work done upstream to fix these sort of bugs.
> I've pushed some testing packages incorporating these fixes to
> https://edge.launchpad.net/~raof/+archive/aubergine/+packages.

I've tried installing packages from this PPA, and the test case still fails for me. This is on a VM running an up-to-date Lucid install.

Some details: After adding the PPA to my sources, I found I had 11 packages upgradable. I first tried upgrading just four of them: libxcb1, libxcb1-dev, libxcb-render0, and libxcb-render0-dev. After restarting X, the test case failed, but in a different way than before. A keypress would result in the familiar error being printed to the VTE, whereas mouse motion would cause to VTE to freeze (so that the window would not repaint if obscured and then revealed). Before, either would cause the error message.

Then, I tried installing the remaining seven packages: libx11-6, libx11-data, libx11-dev, libxau6, libxau-dev, libxdmcp6, and libxdmcp-dev. After restarting X, the original error behavior was restored.

Just to be sure, I rebooted the (virtual) machine and tried the test case again. Now the error behavior has flipped: mouse movement will trigger the error message while a keypress will trigger a freeze. I have no idea what to make of any of this, so I thought I would just throw it out there.

The PPA definitely fixes the “ico -threads 10” testcase for me locally. I'm not sure about the python testcase; I can't see anything immediately wrong with it, but I recall an unrelated bug in Lucid with python, glib and forking which which makes me slightly suspicious of it.

OK, I'm not having any problems with "ico -threads 10" with the PPA.

BUT: Is there any reason to believe that the problems with ico are the same as this bug? As far as I can tell, the problem here is that Python programs using X which execute a fork reliably throw a specific assertion error. (I'm guessing about the details of apport-kde, but this seems to be the pattern with Gasp and my test case. Please correct me if I'm wrong.) Meanwhile, one drive-by commenter mentioned that "ico -threads 10" will occasionally produce this error. The fact that the PPA has fixed "ico" and not the Python problems suggests to me that these are not the same bug. It may be that the "unrelated bug in Lucid with python, glib and forking" is very much relevant here (though this bug also occurs in Karmic).

Jamey Sharp, an X.org upstream, has taken a look at this and said:

"All those I could find look like one of two cases: Either the app called Xlib from multiple threads without calling XInitThreads first; or it opened a Display, fork()ed, and used the Display from both processes. Both would be bugs in the application."

A few duplicates were reported against python-gasp, which was fixed recently. By far the majority of duplicates are against apport-kde, so I tentatively open a Qt task for this and close the libxcb one.

> "Both would be bugs in the application."

I would like to point out my test case again (comment 31), a simple pyGTK app that displays the same problem. While it may have a bug (please point it out if you see it!), I find that unlikely given how short and simple it is, and because it works perfectly in Ubuntu < Karmic. (FWIW, I tried scattering gtk and gobject threads_init() calls throughout the test case, to no avail.)

As best I can tell from their diffs, python-gasp did not fix this problem; they worked around it by holding off on importing gtk. I think this is similar to the work-around in comment 33. From their NEWS file ["* Work around xlib threadinb bug (LP: #41950)"], it seems that they don't consider this a real bug fix. I don't think that this method will work in any application that must fork in response to user action.

Thus, it seems to me that the bug is lower than the application level -- it could be in the language bindings (pyGTK, in my case), the toolkit (GTK), or in X. The only one shared between my test case and apport-kde is X. But I suppose it is possible that both GTK and QT introduced the same bug at the same time.

If I may present a hypothesis unfettered by evidence: Perhaps (py)GTK and (py)QT have long been doing something technically illegal but practically benign. This went undetected until Karmic, when an upgrade to libxcb tested for this condition in an assert statement. Obviously, the correct long-term fix is to find what the toolkits are doing wrong and fix that, but in the short term it might make sense to relax the assertion checking in libxcb. The obvious way to test this is to comment out the assertion, run it, and see if anything breaks. But I can't even figure out which package has xcb_io.c in it, so I'm probably not the person to check this.

Anyway, should I reopen bug #518269 and file it against GTK, should this bug also be linked to GTK, or should I just wait until we have firm evidence that the problem is at the toolkit level instead of X?

From what I can tell the python program in comment 31 appears to open an X connection, fork, and then use that X connection from both the child and the parent. That can't possibly work.

On 06/30/2010 05:14 AM, Julien Cristau wrote:
> From what I can tell the python program in comment 31 appears to open an
> X connection, fork, and then use that X connection from both the child
> and the parent. That can't possibly work.

And yet it does, in Ubuntu < Karmic.

All that the child process is running is (or should be):
    time.sleep(1)
    while True:
        line = raw_input("> ")
        sys.stdout.write("< " + line + '\n')
    os._exit(0)
Though I may be mistaken, none of this appears to use the X connection. Comparison to the code in comment 33 shows that this same code executes just fine in the child process so long as the child process doesn't have the gtk or vte objects. It's certainly possible that there's a problem in GTK, VTE, or their python bindings, but it seems strange to me that this problem was introduced at the same time as a similar one in Qt.

This has only ever effected PyQt applications. (though I'm not really convinced it's a pyqt bug)

Not only. This bug affects GTK applications too.

I am facing this bug with Exaile 0.3.2 in Maverick.

By the way, you might consider it as duplicate : https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/510225

Sorry for double-posting, I meant https://bugs.launchpad.net/exaile/+bug/596227

(As of natty, test code still produces the warning, so setting status to Triaged. Upstream seems to feel the issue needs to be resolved by modifying calling clients to limit how multi-threaded processes utilize the XCB event queue.)

As per my previous message, these types of errors are generally client problems.

This past week apport got a fix for an xcb threading assert it hits; possibly this issue is resolved by that.

So, against what should this bug be filed? GTK/Qt? Vte? Python? All of them? Something else?

I'm sorry - I no longer even have that system

On 17 March 2012 15:37, Robert Schroll <email address hidden> wrote:

> So, against what should this bug be filed? GTK/Qt? Vte? Python? All
> of them? Something else?
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (455029).
> https://bugs.launchpad.net/bugs/419501
>
> Title:
> apport-kde assert failure: python: ../../src/xcb_io.c:242:
> process_responses: Assertion `(((long) (dpy->last_request_read) -
> (long) (dpy->request)) <= 0)' failed.
>
> Status in GASP Core Code:
> Fix Released
> Status in “libxcb” package in Ubuntu:
> Won't Fix
> Status in “python-gasp” package in Ubuntu:
> Fix Released
> Status in “python-qt4” package in Ubuntu:
> Invalid
> Status in “libxcb” source package in Lucid:
> Won't Fix
> Status in “python-gasp” source package in Lucid:
> Fix Released
> Status in “python-qt4” source package in Lucid:
> Invalid
>
> Bug description:
> Binary package hint: apport
>
> TEST CASE:
>
> https://bugs.launchpad.net/ubuntu/+source/python-gasp/+bug/419501/comments/31
>
>
> Description: Ubuntu karmic (development branch)
> Release: 9.10
>
> ProblemType: Crash
> Architecture: amd64
> AssertionMessage: python: ../../src/xcb_io.c:242: process_responses:
> Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <=
> 0)' failed.
> CrashCounter: 1
> Date: Wed Aug 26 16:14:40 2009
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/share/apport/apport-kde
> InterpreterPath: /usr/bin/python2.6
> NonfreeKernelModules: nvidia
> Package: apport-kde 1.8-0ubuntu1
> PackageArchitecture: all
> ProcCmdline: /usr/bin/python /usr/share/apport/apport-kde
> ProcEnviron:
> PATH=(custom, no user)
> LANG=en_US.UTF-8
> LANGUAGE=
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
> Signal: 6
> SourcePackage: apport
> StacktraceTop:
> raise () from /lib/libc.so.6
> abort () from /lib/libc.so.6
> __assert_fail () from /lib/libc.so.6
> ?? () from /usr/lib/libX11.so.6
> _XEventsQueued () from /usr/lib/libX11.so.6
> Title: apport-kde assert failure: python: ../../src/xcb_io.c:242:
> process_responses: Assertion `(((long) (dpy->last_request_read) - (long)
> (dpy->request)) <= 0)' failed.
> Uname: Linux 2.6.31-3-generic x86_64
> UserGroups:
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gasp-core/+bug/419501/+subscriptions
>

--
Aaron Stromas
Mobile: +1 703 203 9169

I reported this back in August of '09.

While I commend the dedication to fixing it, don't prod along on my
account - I just kept trying successively newer versions of Ubuntu as
they came out, and got more powerful hardware as well... and the
problems eventually stopped.

Don't ask me which change solved it, as most every hardware upgrade
was accompanied by a fresh install, so it could have been anything.

For what it's worth, I think the hardware I had installed in '09 was
unstable. I have the motherboard in a box if anyone wants it, I'm not
doing anything with it...

Dennis

On Sun, Mar 18, 2012 at 8:31 AM, passogiau <email address hidden> wrote:
> I'm sorry - I no longer even have that system
>
> On 17 March 2012 15:37, Robert Schroll <email address hidden> wrote:
>
>> So, against what should this bug be filed?  GTK/Qt?  Vte?  Python?  All
>> of them?  Something else?
>>
>> --
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (455029).
>> https://bugs.launchpad.net/bugs/419501
>>
>> Title:
>>  apport-kde assert failure: python: ../../src/xcb_io.c:242:
>>  process_responses: Assertion `(((long) (dpy->last_request_read) -
>>  (long) (dpy->request)) <= 0)' failed.
>>
>> Status in GASP Core Code:
>>  Fix Released
>> Status in “libxcb” package in Ubuntu:
>>  Won't Fix
>> Status in “python-gasp” package in Ubuntu:
>>  Fix Released
>> Status in “python-qt4” package in Ubuntu:
>>  Invalid
>> Status in “libxcb” source package in Lucid:
>>  Won't Fix
>> Status in “python-gasp” source package in Lucid:
>>  Fix Released
>> Status in “python-qt4” source package in Lucid:
>>  Invalid
>>
>> Bug description:
>>  Binary package hint: apport
>>
>>  TEST CASE:
>>
>> https://bugs.launchpad.net/ubuntu/+source/python-gasp/+bug/419501/comments/31
>>
>>
>>  Description:  Ubuntu karmic (development branch)
>>  Release:      9.10
>>
>>  ProblemType: Crash
>>  Architecture: amd64
>>  AssertionMessage: python: ../../src/xcb_io.c:242: process_responses:
>> Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <=
>> 0)' failed.
>>  CrashCounter: 1
>>  Date: Wed Aug 26 16:14:40 2009
>>  DistroRelease: Ubuntu 9.10
>>  ExecutablePath: /usr/share/apport/apport-kde
>>  InterpreterPath: /usr/bin/python2.6
>>  NonfreeKernelModules: nvidia
>>  Package: apport-kde 1.8-0ubuntu1
>>  PackageArchitecture: all
>>  ProcCmdline: /usr/bin/python /usr/share/apport/apport-kde
>>  ProcEnviron:
>>   PATH=(custom, no user)
>>   LANG=en_US.UTF-8
>>   LANGUAGE=
>>   SHELL=/bin/bash
>>  ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
>>  Signal: 6
>>  SourcePackage: apport
>>  StacktraceTop:
>>   raise () from /lib/libc.so.6
>>   abort () from /lib/libc.so.6
>>   __assert_fail () from /lib/libc.so.6
>>   ?? () from /usr/lib/libX11.so.6
>>   _XEventsQueued () from /usr/lib/libX11.so.6
>>  Title: apport-kde assert failure: python: ../../src/xcb_io.c:242:
>> process_responses: Assertion `(((long) (dpy->last_request_read) - (long)
>> (dpy->request)) <= 0)' failed.
>>  Uname: Linux 2.6.31-3-generic x86_64
>>  UserGroups:
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/gasp-core/+bug/419501/+subscript...

This was not a hardware specific problem. It may have been a hardware _class_ problem where somebody ASS-U-MEd something would get done in a certain amount of time or some other resource level, but the duplicate count is lengthy. It appears to cover most motherboards for most brands.

I have no idea if this bug "went away". It and several other nasty bugs caused me to move to OpenSuSE.