I'm running gstreamer-0.10.4 and gst-plugins-0.10.2

GDB Backtrace:

+ Trace 67391

Ok, the problem seems to be with gst-plugins-lame.  Uninstalling that lets me go into the preferences dialog.

Reassigning to GStreamer then.

I don't understand this at all. It seems like a lame bug, because it happens inside lame_get_ATHlower, but the code in there (here, at least) looks like this:

float
lame_get_ATHlower( const lame_global_flags*  gfp )
{
    return -gfp->ATHlower * 10.0;
}

I fail to see how that can possibly produce a divide-by-zero error unless a) The stacktrace is bad (although it seems consistent) b) You have a different version of lame c) The compiler the built LAME was buggy d) I'm missing something.

Kevin, what distro are you on? 

Jan: the System.DivideByZeroException is at the Mono level, I think it's just an after affect of the crash in LAME, but that still doesn't make much sense (what in TestPipeline would ever throw that?)... here's the relevant C# code:

[DllImport("libbanshee")]
private static extern bool gstreamer_test_encoder(IntPtr encoder_pipeline);
        
public static bool TestEncoder(string pipeline)
{
    IntPtr pipeline_ptr = GLib.Marshaller.StringToPtrGStrdup(pipeline);

    try {
        return gstreamer_test_encoder(pipeline_ptr);
    } finally {
        GLib.Marshaller.Free(pipeline_ptr);
    }
}

...

Though after looking at that, a check should probably be made to see if pipeline_ptr is NULL for some reason.

Created attachment 62662 [details] [review]
NULL check patch to TestEncoder

Kevin, if you can, would you test this patch against Banshee? It adds a null/IntPtr.Zero check to TestEncoder. If doesn't solve anything, then I'll keep my bets on LAME.

Also, can you provide the LAME pipeline that is being tested? You can find it in GConf: /apps/Banshee/EncoderProfiles

OK, I just assumed that the C-level problem is also a divide-by-zero error, since that's what is being reported at the mono level and I can't see differently from the GDB output.

Also worth testing is whether a simple 'gst-inspect lame' succeeds.

(In reply to comment #7)
> Created an attachment (id=62662) [edit]
> NULL check patch to TestEncoder
> 
> Kevin, if you can, would you test this patch against Banshee? It adds a
> null/IntPtr.Zero check to TestEncoder. If doesn't solve anything, then I'll
> keep my bets on LAME.
> 
> Also, can you provide the LAME pipeline that is being tested? You can find it
> in GConf: /apps/Banshee/EncoderProfiles
> 

Yes, it's being tested.  And no, that patch doesn't help.  I checked out CVS where the patch was already applied and it still crashes.

(In reply to comment #6)
> Kevin, what distro are you on? 
Gentoo.

LAME pipeline:
lame|Lame MP3  |mp3 |lame     |bitrate|false|none

Okay, nothing looks out of order then and it's probably safe to say the problem is actually in lame. Something may be configured improperly in your builds? This is far too often the case under Gentoo.

Can't really do much about this without further information. Seems likely that this is indeed a gentoo-related problem of some sort. Closing for now. Please re-open if you have further information that might help track this down.

Well, I did some more digging and found out the error is something with accessing gfp->ATHlower in lame_get_ATHlower.  When I do "display gfp->ATHlower", I get = 0, but even if I try to print it out in the program, it crashes.

Actually it's a SIGFPE for some reason.  I even tried to put a lame_set_ATHlower(gfp,10.0f); in lame_get_ATHlower and it gave a SIGFPE as well.

I'm not sure I get what's going on in Banshee either.  I put some catch statements that return false (before it was just a try and a finally, no catch statements?) in TestEncoder so it wouldn't crash on a bad plugin, but now the GUI just seems to freeze up when going into preferences.

Have you tried running it in valgrind? Does anything useful show up there?

Do you get the same problem with:

 $ gst-launch-0.10 audiotestsrc ! audioconvert ! audio/x-raw-int,channels=2,rate=44100 ! lame ! fakesink

or

 $ gst-launch-0.10 filesrc location=somefile.mp3 ! decodebin ! audioconvert ! audioresample ! audio/x-raw-int,channels=2,rate=44100 ! lame ! fakesink

?

(In reply to comment #17)
> Have you tried running it in valgrind? Does anything useful show up there?
> 
> Do you get the same problem with:
> 
>  $ gst-launch-0.10 audiotestsrc ! audioconvert !
> audio/x-raw-int,channels=2,rate=44100 ! lame ! fakesink
> 
> or
> 
>  $ gst-launch-0.10 filesrc location=somefile.mp3 ! decodebin ! audioconvert !
> audioresample ! audio/x-raw-int,channels=2,rate=44100 ! lame ! fakesink
> 
> ?
> 

Using gst-launch seems to work, I'll try valgrind in a minute.

Ping? :)

Created attachment 65711 [details]
Valgrind output

Pong? :)

Here it is.  It didn't seem to get far, it quits after loading gstreamer.  Not sure if it's because gstreamer acts differently under valgrind or not.

Thanks, looks like the liboil stuff makes it abort.

Could you do another valgrind log with

 $ export OIL_CPU_FLAGS=0
 $ export G_SLICE=always-malloc
 $ valgrind --trace-children=yes  ...  2> dbg.log
 $ gzip dbg.log

(and the --trace-children=yes).

Created attachment 65714 [details]
Valgrind with trace children

Didn't seem to change much.

I'm afraid I have absolutely no idea what the problem might be here. valgrind seems to choke on liboil (despite OIL_CPU_FLAGS=0), so that's not very useful either.

Given the code I just don't see how this could possibly be a problem in GStreamer's lame code.

Not sure what to do about this, sorry.

Tim, let me know more details about valgrind choking on liboil; I'll try and fix it (or get it fixed). Whether this'll help here I don't know, but it's always helpful to have tools working properly.

> Tim, let me know more details about valgrind choking on liboil; I'll try and
> fix it (or get it fixed). Whether this'll help here I don't know, but it's
> always helpful to have tools working properly.

Maybe I'm reading the log (attached above) wrong, but this is what I think is the process terminating properly (and not just what liboil does internall), isn't it?


--31508-- Reading syms from /usr/lib/liboil-0.3.so.0.1.0 (0x7D97000)
unhandled opc_aux = 0x1 
first_opcode == 0xDF
vex x86->IR: unhandled instruction bytes: 0xDF 0xE 0x83 0x45
==31508== Your program just tried to execute an instruction that Valgrind
==31508== did not recognise.  There are two possible reasons for this.
==31508== 1. Your program has a bug and erroneously jumped to a non-code
==31508==    location.  If you are running Memcheck and you just saw a
==31508==    warning about a bad jump, it's probably your program's fault.
==31508== 2. The instruction is legitimate but Valgrind doesn't handle it,
==31508==    i.e. it's Valgrind's fault.  If you think this is the case or
==31508==    you are not sure, please let us know.
==31508== Either way, Valgrind will now raise a SIGILL signal which will
==31508== probably kill your program.
GStreamer has detected that it is running inside valgrind.
It might now take different code paths to ease debugging.
Of course, this may also lead to different bugs.
==31508== 
==31508== Process terminating with default action of signal 6 (SIGABRT)
==31508==    at 0x415E5F9: raise (raise.c:64)
==31508==    by 0x415FA62: abort (abort.c:88)
==31508==    by 0x7DA8041: illegal_instruction_handler (liboilcpu.c:450)
==31508==    by 0x4101CF7: (within /lib/libpthread-2.4.so)
==31508==    by 0x7DA951A: _oil_test_marshal_function (liboilmarshal.c:165)
==31508==    by 0x7DAB1AC: oil_test_check_function (liboiltest.c:270)
==31508==    by 0x7DAB284: oil_test_check_ref (liboiltest.c:303)
==31508==    by 0x7DAB38C: oil_test_check_impl (liboiltest.c:353)
==31508==    by 0x7DA909B: oil_class_optimize (liboilfunction.c:367)
==31508==    by 0x7DA92E9: oil_optimize_all (liboilfunction.c:186)
==31508==    by 0x7DA93BE: oil_init (liboilfunction.c:146)
==31508==    by 0x7B268A6: resample_init (resample.c:46)

I'm afraid there isn't really much we can do about this bug for now, hence closing. Not much indication that it really is GStreamer-related either. Valgrind issue passed on upstream.

the problem was with the lame included in the Gentoo tree. lame was being compiled with mp3rtp option enabled at compile time and the upstream said it was broken for everyone. Now mp3rtp is option on our package and it shouldn't cause more problems like this.

Sorry and thanks for your help.

*** Bug 380588 has been marked as a duplicate of this bug. ***