After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575887 - Crash with the X video output code, XvQueryExtension
Crash with the X video output code, XvQueryExtension
Status: RESOLVED NOTGNOME
Product: ekiga
Classification: Applications
Component: general
GIT master
Other All
: Normal critical
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-18 22:08 UTC by Mark Carroll
Modified: 2009-07-25 20:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backtrace with breakpoint set (277.22 KB, text/plain)
2009-04-01 00:37 UTC, Mark Carroll
Details
additional debug output without breakpoint set (249.84 KB, text/plain)
2009-04-01 00:39 UTC, Mark Carroll
Details
Bad Window error from X during a call (377.57 KB, text/plain)
2009-04-27 07:55 UTC, Mark Carroll
Details
Bad Window error from X upon call hangup (383.92 KB, text/plain)
2009-04-27 07:56 UTC, Mark Carroll
Details
Bad Window error from X upon call hangup (463.40 KB, text/plain)
2009-05-18 05:34 UTC, Mark Carroll
Details
Bad Window error from X upon call hangup (397.31 KB, text/plain)
2009-06-09 02:44 UTC, Mark Carroll
Details
backtrace of crash-on-startup from ssh -CX to remote Debian computer to use its Ekiga (81.40 KB, text/plain)
2009-07-05 22:49 UTC, Mark Carroll
Details

Description Mark Carroll 2009-03-18 22:08:13 UTC
Steps to reproduce:
Call 500@ekiga.net
Wait until echoing starts
Hang up

(doesn't always crash, bug is intermittent)


Stack trace:
Recorded at http://pastebin.com/m327c8621


Other information:
I was using Debian ekiga-snapshot 0-20090315-1.

Without the breakpoint on gdk_x_error, X crashes with a BadWindow (invalid Window parameter) and gdb doesn't report anything useful, as seen at http://pastebin.com/m20224abe (though I think that crash happened during the call, not at hangup).
Comment 1 André Klapper 2009-03-31 17:30:04 UTC
(In reply to comment #0)
> Stack trace:
> Recorded at http://pastebin.com/m327c8621

... please attach it here instead so it does not get lost.
Comment 2 Mark Carroll 2009-04-01 00:37:59 UTC
Created attachment 131817 [details]
backtrace with breakpoint set

attachment requested in previous comment
Comment 3 Mark Carroll 2009-04-01 00:39:38 UTC
Created attachment 131818 [details]
additional debug output without breakpoint set

other output mentioned in original report
Comment 4 Snark 2009-04-01 12:56:46 UTC
Changing the title of the bug report, in order to make it more descriptive.

I hope Matthias (Schneider) will be able to help there, since it's in his part of the woods.
Comment 5 Snark 2009-04-21 12:16:41 UTC
Can you still reproduce it reliably? I may try to fix it if you can help.
Comment 6 Snark 2009-04-21 19:02:08 UTC
I committed a few potential threading-related fixes this evening, so it would be worth a try to see if I got that one down.
Comment 7 Mark Carroll 2009-04-23 13:02:59 UTC
I'll give it another try once Eugen builds the snapshot debs again so that your fixes are included - so it'll probably be a couple days. Thanks!
Comment 8 Eugen Dedu 2009-04-23 13:09:14 UTC
Tomorrow!
Comment 9 Mark Carroll 2009-04-27 07:54:25 UTC
Yes, the bug's still reproducible with the 20090423 Debian snapshot. Exactly /when/ varies - sometimes it's during the call, but if not then always on hangup.

I'll now provide a backtrace of each with the 20090423 snapshot.
Comment 10 Mark Carroll 2009-04-27 07:55:44 UTC
Created attachment 133396 [details]
Bad Window error from X during a call
Comment 11 Mark Carroll 2009-04-27 07:56:29 UTC
Created attachment 133397 [details]
Bad Window error from X upon call hangup
Comment 12 Snark 2009-04-27 09:37:08 UTC
Sigh... I'm wondering if we're not doing X operations in a thread, while gtk+ does them in another... which is of course bad.
Comment 13 Mark Carroll 2009-05-18 05:32:50 UTC
I still see the Bad Window error from X upon call hangup.

Here's a new backtrace using the 20090517 build.
Comment 14 Mark Carroll 2009-05-18 05:34:33 UTC
Created attachment 134845 [details]
Bad Window error from X upon call hangup
Comment 15 Eugen Dedu 2009-05-21 10:45:00 UTC
It seems to me that it is a crash in libxv, look at the first thread:
  • #4 XvQueryExtension
    from /usr/lib/libXv.so.1
  • #5 XVWindow::Init
    at ../../lib/gui/xvwindow.cpp line 144

The line generating the crash is lib/gui/xvwindow.cpp:144, as shown by gdb (see above) and by the last line of the -d 4 output:
2009/05/18 01:29:33.574	  0:48.788	GMVideoOut...0x5c837950	XVideo	Initializing XV window with 320x240 at 6,95
[crash]
[Switching to Thread 0x7fa65c837950 (LWP 14500)]

"Initializing..." is a printf before line 144 and the printf at line 145 is not executed.

Line 144 is:
  ret = XvQueryExtension (_display, &ver, &rel, &req, &ev, &err);
The bug is one of the following:
- either _display is not valid anymore, so an ekiga bug
- or it is a bug in libxv

Conclusion: I propose that you install libxv1-dbg and redo the gdb output.  Tell us also if you were hanging up or quitting ekiga.  We will see if the problem is with _display or not.
Comment 16 Mark Carroll 2009-06-09 02:44:38 UTC
Created attachment 136182 [details]
Bad Window error from X upon call hangup

Sorry for the delay - I was away for a couple weeks. I installed the 20090603 snapshot and libxv1-dbg and the gdb output does indeed give more detail, enclosed. This crash happened when I hit the call hangup button.
Comment 17 Snark 2009-06-09 14:04:11 UTC
I have an idea : I notice that you have an X error, while I'm using XV.

Could it be that all developpers and testers are using XV -- and that the X code has always been broken without us knowing?

I'll write to the devel mailing-list to find the answer to that question.
Comment 18 Eugen Dedu 2009-06-09 20:54:01 UTC
I do not have XVideo (hw acceleration) => I use X (sw acceleration) also, and it works...
Comment 19 Mark Carroll 2009-07-05 22:47:24 UTC
From my regular computer, from which my previous comments and attachments were generated, I tried ssh -CX to a remote system that has a Debian installation of Ekiga (not latest SVN snapshot):

Package: ekiga
Version: 3.2.1~git20090515.9d0263-1

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (900, 'stable'), (50, 'testing'), (40, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ekiga depends on:
ii  evolution-data-se 2.26.2-1               evolution database backend server
ii  gconf2            2.26.2-1               GNOME configuration database syste
ii  libatk1.0-0       1.22.0-1               The ATK accessibility toolkit
ii  libavahi-client3  0.6.23-3lenny1         Avahi client library
ii  libavahi-common3  0.6.23-3lenny1         Avahi common library
ii  libavahi-glib1    0.6.23-3lenny1         Avahi glib integration library
ii  libc6             2.9-13                 GNU C Library: Shared libraries
ii  libdbus-glib-1-2  0.80-4                 simple interprocess messaging syst
ii  libebook1.2-9     2.26.2-1               Client library for evolution addre
ii  libedataserver1.2 2.26.2-1               Utility library for evolution data
ii  libgcc1           1:4.3.2-1.1            GCC support library
ii  libgconf2-4       2.26.2-1               GNOME configuration database syste
ii  libglib2.0-0      2.20.3-1               The GLib library of C routines
ii  libgtk2.0-0       2.16.4-1               The GTK+ graphical user interface 
ii  libldap-2.4-2     2.4.11-1               OpenLDAP libraries
ii  libnotify1 [libno 0.4.5-1                sends desktop notifications to a n
ii  libopal3.6.1      3.6.1~dfsg-1           Open Phone Abstraction Library - s
ii  libpango1.0-0     1.20.5-5               Layout and rendering of internatio
ii  libpt2.6.1        2.6.1-2                Portable Tools Library
ii  libpt2.6.1-plugin 2.6.1-2                PTLib audio plugin for the ALSA In
ii  libpt2.6.1-plugin 2.6.1-2                Portable Tools Library video plugi
ii  libsasl2-2        2.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra
ii  libsigc++-2.0-0c2 2.0.18-2               type-safe Signal Framework for C++
ii  libstdc++6        4.3.2-1.1              The GNU Standard C++ Library v3
ii  libx11-6          2:1.1.5-2              X11 client-side library
ii  libxext6          2:1.0.4-1              X11 miscellaneous extension librar
ii  libxml2           2.6.32.dfsg-5          GNOME XML library
ii  libxv1            2:1.0.4-1              X11 Video extension library

Versions of packages ekiga recommends:
ii  gvfs                         1.2.3-1     userspace virtual filesystem - ser
ii  yelp                         2.22.1-8+b1 Help browser for GNOME 2

I shall now attach the gdb backtrace I got from when it crashed on startup from that remote computer with display expected to occur on mine over ssh X forwarding. I don't know if it's relevant or helpful but, hey, it's more information.
Comment 20 Mark Carroll 2009-07-05 22:49:36 UTC
Created attachment 137893 [details]
backtrace of crash-on-startup from ssh -CX to remote Debian computer to use its Ekiga
Comment 21 Eugen Dedu 2009-07-17 20:43:32 UTC
Hi Mark,

Sorry for the delay.

Your last two comments are about another bug.  I still think they are related, X errors.

Let's try to solve the original bug first.
Comment 22 Mark Carroll 2009-07-17 21:04:12 UTC
Ah, okay then, sorry for introducing any confusion!
Comment 23 Eugen Dedu 2009-07-18 08:17:31 UTC
In both cases, a call to _XReply is made (in the first case, it's
XvQueryExtension which calls it).

_XReply, from libx11, calls process_responses, from libx11 too, which waits
until all the X events are processed.  One of these events it seems is an
error, and the program finishes in this case (even if the error is not a
critical one).
Comment 24 Eugen Dedu 2009-07-22 10:39:20 UTC
After a few tests, I cannot reproduce it anymore.  I think it was fixed in libx11-6 version 1.2.2, look at http://cgit.freedesktop.org/xorg/lib/libX11/log/ for generic events.

If you already have libx11-6 version 1.2.2, could you try again ekiga to see if the bug still happens?

We will close this bug if it does not reappear.
Comment 25 Mark Carroll 2009-07-22 13:42:11 UTC
I did indeed only have libx11-6 1.2.1. I have now upgraded to 1.2.2 and shall give Ekiga another try tonight. Thank you.
Comment 26 Mark Carroll 2009-07-24 00:29:50 UTC
Ha, it indeed seems to be fixed, at least with the echo test! Thank you very much indeed.


There's still a BadWindow when I quit but I really don't care about that. (Though if you'd like help debugging that I'll happily oblige.)

(Right now I'm using Debian sid's Ekiga 3.2.5, not SVN, hope that's okay.)

I'm expecting to have a long call with somebody else on Saturday with it so that'll be a good roadtest.
Comment 27 Eugen Dedu 2009-07-24 06:40:35 UTC
Thanks for the info!

What BadWindow do you receive?  Is it
  (Details: serial 1420 error_code 3 request_code 10 minor_code 0)
?

We wait until tomorrow then to see if the bug still appears.
Comment 28 Mark Carroll 2009-07-24 14:25:27 UTC
Yes, that looks rather similar -

  (Details: serial 1446 error_code 3 request_code 10 minor_code 0)

I guess you already have that one reported then. (-:
Comment 29 Mark Carroll 2009-07-25 19:47:08 UTC
I'm afraid that call was all a bit of a failure - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538418

You can go ahead and close this bug if you like and I'll just reopen it if I later discover that the problem remains.
Comment 30 Eugen Dedu 2009-07-25 20:18:54 UTC
This bug does not appear anymore since libx11-6 has been upgraded from 1.2.1 to 1.2.2, so closing as notgnome.