GNOME Bugzilla – Bug 129164
Problems with gnome-sound-recorder and gstreamer-properties
Last modified: 2004-12-22 21:47:04 UTC
Hiya, I've Gnome 2.5, builded from the ebuilds given on www.breakmygentoo.net. I've Alsa(-lib,-utils) 0.9.8 and the modules integrated in my 2.6 Kernel. There's some problems with the gnome-sound-recorder : It crashes when I launch it. The steps are : - Get Gnome 2.5 - You must only have Alsa on your system with OSS Emulation. - Launch gnome-sound-recorder Then it will crash. Same thing with gstreamer-properties when testing the output alsasrc. The backtraces are in attachment because they are huge. If I launch gnome-sound-recorder from a console, I've this error : (gnome-sound-recorder:16948): GStreamer-CRITICAL **: file gstbin.c: line 484 (gst_bin_add): assertion `GST_IS_ELEMENT (element)' failed (gnome-sound-recorder:16948): GStreamer-CRITICAL **: file gstelement.c: line 1521 (gst_element_link_pads_filtered): assertion `GST_IS_ELEMENT (dest)' failed ** (gnome-sound-recorder:16948): WARNING **: You do not have a new enough gst-plugins. You really need CVS after 20-Oct-2002 I've gst-plugins-0.7.2 which are the last released at the moment ( 12 December 2003 ) ( emerge -vp gst-plugins These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] media-libs/gst-plugins-0.7.2 ) By the way I haven't gst-plugins-oss because I can't compile it... I wonder if it's not the reason of the error. I've emerged Gnome like this : USE="doc tiff ipv6" ACCEPT_KEYWORDS="~x86" emerge -v gnome Here are my system informations : Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.6.0-thebest-test11) ================================================================= System uname: 2.6.0-thebest-test11 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.4.3.10p1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O2 -m3dnow -pipe -mmmx -s" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O2 -m3dnow -pipe -mmmx -s" DISTDIR="/opt/packages" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo ftp://gentoo.linux.no/pub/gentoo/ http://gentoo.linux.no/ http://212.219.56.162/sites/www.ibiblio.org/gentoo/ http://212.219.56.152/sites/www.ibiblio.org/gentoo/ http://212.219.56.146/sites/www.ibiblio.org/gentoo/ http://212.219.56.131/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib directfb gtkhtml alsa gdbm berkdb slang readline arts tetex aalib bonobo svga tcltk java guile ruby mysql postgres X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla ldap cdr scanner" I've Xfree 4.3.99.901.
Created attachment 22360 [details] Gnome-sound-recorder backtrace
Created attachment 22361 [details] Gstreamer-properties Backtrace from bug-buddy
Both stack trace are unique according to the simple-dup-finder. I'm not sure whether this should be split into two bugs or kept together--and if they're kept together, whether this should be filed here or against gstreamer. So, I'll leave it as is for now. The first stack trace has debugging symbols, the second stack trace does too but not in the functions in the lowermost frames before the signal handler gets called. I'll add the STACKTRACE keyword anyway for now.
Maybe a CC to the gstreamer team would be a good idea ?
It sounds like a duplicate of this : http://bugzilla.gnome.org/show_bug.cgi?id=126539
Eddahbi Karim: The steps to reproduce may sound the same as bug 126539, but the stack traces are different meaning that you are triggering a different bug. CC'ing the gstreamer people sounds like a good idea--that way they can help decide where this bug belongs.
I think they should be alerted for gstreamer-properties at least which crashes when using ALSA 0.9.8.
Which GStreamer version? ALSA in 0.6.x is known to be broken. It should work in HEAD CVS (0.7.x).
I have Gstreamer 0.7.2, I'll try CVS HEAD. By the way I haven't gst-plugins-oss ...
OK, I finally got around to a good review of GSR tonight. Dzjeeeeeeeh! It doesn't look that bad, don't get me wrong, but it misses too much error correction. For each element that's created, it should check whether it's !NULL after creation. If not, it should give an error dialog and bail out (i.e. return control to user) without crashing. It doesn't do any of this. What's worse, is that saving a file to **whatever** media type appears to crash. The backtraces are inconsistent and the thing refuses to give any useful info in either gdb or valgrind (!), which leads me to believe we've got a nice example of well-defined memory corruption here. I'm intending to make this the general "GSR crashes on save-as or GSR crashes and one element is NULL" bug. Expect some dups here. I hope to have this fixed fairly soon. It'll take me quite some patching to get this correct, though.
*** Bug 122634 has been marked as a duplicate of this bug. ***
Thank you for the informations, I hope that it will be fixed soon. If you need some testers for your patches, mail me :).
Thanks for taking a look, Ronald. :)
Hi, Just to give a notice of my progress: I think I've got our main bug. I'm still not sure what it is, but I've removed most of the threading, which also solved this issue. I'm guessing for some complicated mess between Gst threading, bonobo or X or so. Not really sure, but don't care much either. I'm not actually committing it yet, because there's one Gst bug holding this off (in wavparse). I'm hoping to have that fixed in a few hours. I'll commit this stuff too, then, and close this bug (hopefully).
OK, committed to HEAD. - Remove threading in saving (this fixed all those segfaults). - Add some checks to ensure elements are created properly. - Basic error handling in the saving pipeline. Please let me know how it works. Note that: - I use current CVS/HEAD for this thing. - wav/ogg/flac/mp3 playback might or might not work, this is a GStreamer issue, not a GSR issue. - saving as FLAC fails here. It doesn't crash, though. It's probably a GStreamer bug, too (an encoder should be able to encode using default settings). I'm not closing this yet, because I only fixed saving. The other stuff (playback, recording) didn't crash, but still need the same checks. I still need to do that, but it's (imo) less priority because it didn't crash the thing.
Ok, so I'll compile the CVS version of Gstreamer and GSR ... I'll report any problems if I found another one...
Sorry for the delay, I battle to compile Gnome CVS (to have the latest versions of GSR) so I can't say if the problem is solved or not on my side...
So I tried the new Gnome-Sound-Recorder with the latest Gstreamer (I use jhbuild to build Gnome CVS) and I can launch it but not record a sound. I'll try to see if that's not the CFLAGS which creates this problem. If not, I'll post a bug report.
If you cannot record a sound, it should at least give you a notice (an error dialog), and ideally, the error dialog would actually say something interesting. Can you please be a bit more specific as what doesn't work and what errors it gives?
*** Bug 122266 has been marked as a duplicate of this bug. ***
*** Bug 135445 has been marked as a duplicate of this bug. ***
*** Bug 135526 has been marked as a duplicate of this bug. ***
*** Bug 124992 has been marked as a duplicate of this bug. ***
Hmm I've build the latest Gnome CVS with cvsgnome this time and gnome-sound-recorder didn't start anymore. I haven't enough time to check yet. Here is the backtrace : Backtrace was generated from '/opt/Gnome26/bin/gnome-sound-recorder' 0x40ca77a8 in waitpid () from /lib/libpthread.so.0
+ Trace 44717
This time my CFLAGS was : -O2 -march=athlon-xp -ggdb3
Hm, what GStreamer version and did you run gst-register on your GStreamer tree? The backtrace isn't particularly useful because something's killing the addresses (0xfffffe00)... :-(. Anyway, I'll look at it.
Ok I've run gst-register in user and now it works like a charm :)... Hmm... nearly like a charm :/ If I record a sound, it works now (YAY!) But if I record a sound again without creating a "New file", the software hangs... By the way, If I launch /opt/Gnome26/bin/gnome-sound-record with gdb, when I click on "Record", I got this backtrace :
+ Trace 44865
I hope that it will help you =)
The hang sounds like a bug, that's probabyl something we can debug. Thanks for reporting.
johan claims he fixed this. Care to give current CVS a try? :).
Yeah, this should be fixed. Closing. If you can still reproduce, reopn.