GNOME Bugzilla – Bug 333311
Ekiga crashes after a minute or so.
Last modified: 2008-06-18 06:28:53 UTC
Distribution: Debian testing/unstable Package: ekiga Severity: critical Version: GNOME2.12.3 HEAD Gnome-Distributor: Debian Synopsis: Ekiga crashes after a minute or so. Bugzilla-Product: ekiga Bugzilla-Component: general Bugzilla-Version: HEAD BugBuddy-GnomeVersion: 2.0 (2.12.1) Description: Description of the crash: Ekiga crashes after a minute or so. How often does this happen? Every time Additional Information: Using a MJPEG V4L2 webcam (Logitech Sphere) as video source This backtrace comes from running ekiga --sync Debugging Information: Backtrace was generated from '/usr/libexec/ekiga' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1227396896 (LWP 17170)] [New Thread -1245094992 (LWP 17200)] [New Thread -1244218448 (LWP 17199)] [New Thread -1243952208 (LWP 17198)] [New Thread -1243685968 (LWP 17197)] [New Thread -1243419728 (LWP 17196)] [New Thread -1242571856 (LWP 17194)] [New Thread -1242846288 (LWP 17193)] [New Thread -1241441360 (LWP 17189)] [New Thread -1241912400 (LWP 17186)] [New Thread -1241175120 (LWP 17184)] [New Thread -1240908880 (LWP 17183)] [New Thread -1240642640 (LWP 17182)] [New Thread -1231811664 (LWP 17177)] [New Thread -1231545424 (LWP 17176)] [New Thread -1231254608 (LWP 17175)] [New Thread -1229726800 (LWP 17173)] [New Thread -1229460560 (LWP 17172)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 66669
Thread 3 (Thread -1244218448 (LWP 17199))
------- Bug created by bug-buddy at 2006-03-03 23:02 -------
Does it also happen when video preview is disabled ?
I am getting a similar problem (although I cannot get a nice backttrace with GDB like you do...) Camera: Logitech Pro for Notebook (V4L2) and I use linux-uvc as a driver. OS: Linux from scratch on X86_64 I have the Ekiga runnning for a minute or so before it crashes. Usually, it is associated with a message like "Xlib: unexpected async reply (sequence 0x19beb)!" and then the app freeze. When I go to the menus in the gnome panel, the app crashes for good. From what I read, this could be thread issue (2 threads accessing X at once). Hope this helps, I tried to get a backtrace, but I can't seem to run Ekiga from gdb. Cheers
You can get the backtrace from the core dump. To enable coredump use this lines: # export GNOME_DISABLE_CRASH_DIALOG=1 # ulimit -c unlimited # ./ekiga After that you ill have a core dump, just do: # gdb ..../ekiga core.xxxx (gdb) bt [a lot of message] I need to known the address of this function: (gdb) p decode_MCU_2x1_3planes and the address of the crash, with some help i can find the problem. To quit gdb (gdb) quit The program is running. Exit anyway? (y or n) y
Ok, backtrace seem to indicate that ekiga crash in jpeg_idct_float(). But where ... i don't known, is it possible to send me the core, and the date of the snapshot you use (debian package).
I'll give it a go tonight. Incidentally, how am I supposed to use the debug packages to get a decent core dump with debug symbols? file /usr/lib/debug/usr/bin/ekiga-snapshot says ekiga-snapshot: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped but $ ldd /usr/lib/debug/usr/bin/ekiga-snapshot ldd: warning: you do not have execution permission for `./ekiga-snapshot' statically linked if I add +x bits, then I get: $ ldd /usr/lib/debug/usr/bin/ekiga-snapshot /usr/bin/ldd: line 117: ./ekiga-snapshot: cannot execute binary file nor can I run it at the command line. I'm confused :) cheers, Phil
I don't how to use the ekiga debug package. So use the normal one, and with the core dump and the library i can see why the jpeg decoder segfault. You say this crash after one minute, but do you see some picture before the crash ? I can get binary from http://snapshots.gnomemeeting.net/debian/, but i need to known which version you use to download, and to see exactly where the program code dump. Perhaps a null pointer, an invalid pointer (already free), ... I've tested the decoder using various image, and a logitech webcam fusion.
OK: Here's the top of the stack from the core dump, plus the value of the variable you were after: (gdb) bt
+ Trace 66737
$2 = { <text variable, no debug info>} 0xb7d6bd6a <decode_MCU_2x1_3planes(jdec_private*)> is that enough? This is with the Debian ekiga-cvs package version: Version: 20060302-02-sid.4 cheers, Phil
ok thanks, can you send me the core dump (by mail). Or print the value of the register. (gdb) info registers
From Version: 20060302-02-sid.6 (gdb) bt
+ Trace 66740
eax 0x20200a00 538970624 ecx 0x4313a 274746 edx 0x12 18 ebx 0xb7f471b0 -1208716880 esp 0xb67090f0 0xb67090f0 ebp 0xb6709110 0xb6709110 esi 0x850ffff 139526143 edi 0x850ffff 139526143 eip 0xb7dc53b7 0xb7dc53b7 <get_next_huffman_code(jdec_private*, huffman_table*)+83> eflags 0x10216 66070 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 core dump sent by email. cheers, Phil
NB. I'm using a Logitech sphere as a video source & the drivers are a teensy bit alpha. There aren't any oopsen in the kernel log, but it's possible that the code is getting a short read or something there are a couple of errors in the logs which seem to coincide with the ekiga crashes. So it's possible that the ekiga code is simply not robust against dodgy (short?) input. That might fit with the crash being in get_next_huffman_code() I guess. cheers, Phil
Is the luvcview working for you ? Can you record the jpeg frame from the camera using 176x144 as resolution and MJPEG for the format. Here a small patch i use to record data from luvcview: --- v4l2uvc.c.orig 2006-03-07 10:08:33.434832000 +0100 +++ v4l2uvc.c 2006-03-07 10:08:53.024832000 +0100 @@ -316,6 +316,17 @@ switch (vd->formatIn) { case V4L2_PIX_FMT_MJPEG: + if (1) + { + static int counter = 0; + char tempnam[256]; + FILE *F; + snprintf(tempnam, 256, "/tmp/webcam-%d.rawjpeg", counter++); + F = fopen(tempnam, "wb"); + fwrite(vd->mem[vd->buf.index], vd->buf.bytesused, 1, F); + fclose(F); + } + memcpy(vd->tmpbuffer, vd->mem[vd->buf.index], HEADERFRAME1); memcpy(vd->tmpbuffer + HEADERFRAME1, dht_data, DHT_SIZE); memcpy(vd->tmpbuffer + HEADERFRAME1 + DHT_SIZE, and send me by mail raw jpeg file. I've some program to test the decoder at http://saillard.org/programs_and_patches/tinyjpegdecoder/
luvciew works fine (possibly with the odd glitch). I'll see if I can get a file for you tonight. Might have to be tomorrow though. cheers, Phil
Ok i've found the bug, ekiga crash in this macro #define fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) do { \ while (nbits_in_reservoir<nbits_wanted) \ { \ unsigned char c = *stream++; \ <<== because stream is invalid. reservoir <<= 8; \ if (c == 0xff && *stream == 0x00) \ stream++; \ reservoir |= c; \ nbits_in_reservoir+=8; \ } \ } while(0); priv->stream point to invalid pointer, ecx that contains the value give 0x4313a So it's normal, but why ... i'll try to do some tests using bad jpeg (random data inside the stream), and a shorter jpeg.
I've sent to damien a patch to fix the problem. When a jpeg stream is too short, i don't try read more memory, and return to ekiga. Hope this will fix the problem. I've done some tests with corrupt jpeg and fix the problem. If you have time to rebuild pwlib, i can send you the patch.
I'm happy to test the patch! cheers, Phil
I have applied the patch to CVS. If it still is problematic for you, please reopen the bug. Luc, as usual, thanks a lot!
Created attachment 60865 [details] raw jpeg frame grabbed with lucview which tinyjpeg refuses to decode
Sadly, Luc's patch doesn't fix the problem. OK. Small correction; it may fix the problem, but in my case it does so by killing video input entirely (I get nothing but a green square for the video). So not entirely successful unfortunately!
At least, no more crash... OK reopening. Let's hope Luc can fix it before the release.
I've look quickly the rawjpeg file, but a lot of part is missing. It's not a jpeg file (so it's normal that you have a green image because ekiga don't decode it). Jpeg file contains block that is prefixed by 0xff 0x?? where ?? is the type of the block. But you rawjpeg file doesn't begin with a 0xff, the first 0xff found is 0xff 0xda which mean Start of Scan. Just after this tag, you have the rawstream to decode (huffman, DCT, ...). So i think the first usb frame is not recorded or missing somewhere .... Do you use some usb hub ? perhaps it's a problem using usb, network, ...
I thought these were jpeg data files without the headers? Regardless of whether it's a valid chunk of jpeg data, ekiga ought to be robust against bad data from the video source (or any source for that matter!) As I said before, the uvc drivers are a bit alpha, so it wouldn't surprise me if they were dropping usb packets or something. I'm not using a USB hub though -- the webcam is plugged straight into a PCI USB2 card. NB, ekiga is only using 1 V4L2 buffer to stream into. Could data be being lost whilst this single buffer is dequeued and copied? luvciew appears to use a chain of four buffers...
Well, if the video goes just green when receiving broken data, then I consider that being "robust against bad data"... or should it receive junk but still show perfect images !?
well, you need some jpeg header to known which quantizer you can use (in the mjpeg this is four (two for DC and two for AC), and other information like size, ... Ekiga has no concept of keeping the last good image (i think), so when you are seeing a green iamge, this is because the last frame is bad. If the image is too short, then you will see the begining of the image with good color (by 8x8 block), and after that a green bottom border. I'll try to modify the v4l2 plugin to support more than one buffer. The pwc driver always use multiple buffer internally, i don't known for the linux-uvc driver, i'll take a look.
(In reply to comment #22) > Well, if the video goes just green when receiving broken data, then I consider > that being "robust against bad data"... or should it receive junk but still > show perfect images !? Heh :) Not displaying a single frame because it's corrupt is clearly OK. However Luc's patch killed the video display altogether, regardless of the data quality... On Luc's point, all this data is mjpeg data (the webcam feed is mjpeg AFAIK) -- doesn't that use a fixed quantizer? cheers, Phil
This bug is still hitting me with current ekiga CVS (and the release versions). Typical backtrace & registers:
+ Trace 67670
eax 0x17dc4 97732 ecx 0xa7f16e00 -1477349888 edx 0x17dda 97754 ebx 0xa7fa0fe0 -1476784160 esp 0xa48d804c 0xa48d804c ebp 0xa48d819c 0xa48d819c esi 0x84d7cf8 139295992 edi 0x8 8 eip 0xa7e26834 0xa7e26834 <jpeg_idct_float(component*, unsigned char*, int)+34> eflags 0x210292 2163346 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 Using lucview, I get occasional visual glitches in the display which suggest that the mjpeg stream from the camera may be being corrupted in some way. Want me to try and dump a typical stream again?
(In reply to comment #25) > This bug is still hitting me with current ekiga CVS (and the release versions). [...] > > Using lucview, I get occasional visual glitches in the display which suggest > that the mjpeg stream from the camera may be being corrupted in some way. Want > me to try and dump a typical stream again? Hi phil, is it possible to record with lucview the raw jpeg stream into some files ? and send me the file that cause the problem. I've try to inject bad stream into the decoder, and didn't find a way to crash it.
What's the status of this problem ?
Luc seems away since a few weeks, so no idea :(
*** Bug 374815 has been marked as a duplicate of this bug. ***
*** Bug 390420 has been marked as a duplicate of this bug. ***
A patch is available in the HEAD branch of pwlib. This is problem of allocating a buffer too small. I've reproduced the problem with another webcam. I'll attach the patch sent to the pwlib mailing list.
Created attachment 79028 [details] [review] Patch to fix MJPEG decoding when the resolution is greater
OK, I backported the patch into the Phobos branch of PWLIB so that Ekiga 2.0.4 also gets the fix when it is released. Thanks again Luc!
*** Bug 361218 has been marked as a duplicate of this bug. ***
*** Bug 398515 has been marked as a duplicate of this bug. ***
*** Bug 398518 has been marked as a duplicate of this bug. ***
*** Bug 406149 has been marked as a duplicate of this bug. ***
*** Bug 421118 has been marked as a duplicate of this bug. ***
*** Bug 427226 has been marked as a duplicate of this bug. ***
*** Bug 429703 has been marked as a duplicate of this bug. ***
*** Bug 413247 has been marked as a duplicate of this bug. ***
*** Bug 441870 has been marked as a duplicate of this bug. ***
*** Bug 484474 has been marked as a duplicate of this bug. ***
*** Bug 494654 has been marked as a duplicate of this bug. ***
It isn't normal that we still get a bug report from someone running 2.0.11 : the bug must not be that dead yet :-/
*** Bug 506273 has been marked as a duplicate of this bug. ***
*** Bug 507054 has been marked as a duplicate of this bug. ***
*** Bug 507652 has been marked as a duplicate of this bug. ***
*** Bug 507660 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 516215 ***
*** Bug 538866 has been marked as a duplicate of this bug. ***