Created attachment 140529 [details]
gstreamer debug log

I can't see these failures in the debug log (or any output of check really). 

Could you get a stack trace from where it crashes with

  make generic/states.gdb
  (gdb) run

in tests/check?

and/or make a log with:

  GST_DEBUG=check:5 make generic/states.check 2>&1 | tee states.log


I'm aware of an issue with the renamed amrwbenc plugin if the old amrwb plugin is still installed in the system directory, but I'm guessing this isn't the problem here, right? (All tests would fail then and there would be lots of 'can't register existing type AmrwbEnc warnings').

Here's the gdb output:
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/goetz/svn/gstreamer0.10-plugins-bad/BUILD/gst-plugins-bad-0.10.13.2/tests/check/generic/states 
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 31657.
Running suite(s): states
[New Thread 0x4059b470 (LWP 31656)]
[New Thread 0x40ee8b70 (LWP 31658)]

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt

+ Trace 216894

Created attachment 140531 [details]
requested log

Thanks, I can reproduce this now that I have the vdpau headers/lib installed.

Created attachment 140537 [details] [review]
blacklist vdpau in states test and demote elements to rank NONE

Does this help?

There must be another bug:

Running suite(s): states


Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed


Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed


Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed
0%: Checks: 3, Failures: 3, Errors: 0
gstcheck.c:72:F:general:test_state_changes_up_and_down_seq:0: Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed
gstcheck.c:72:F:general:test_state_changes_up_seq:0: Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed
gstcheck.c:72:F:general:test_state_changes_down_seq:0: Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed
FAIL: generic/states

> There must be another bug:
 
> Running suite(s): states 
> Unexpected critical/warning: gst_clock_get_time: assertion `GST_IS_CLOCK
> (clock)' failed

Where does that come from?

 $ cd tests/check/
 $ G_DEBUG=fatal_warnings make generic/states.gdb
 (gdb) run

[goetz@n5 check]$ G_DEBUG=fatal_warnings make generic/states.gdb
GNU gdb 6.8-6mdv2009.1 (Mandriva Linux release 2009.1)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
(gdb) run
Starting program: /home/goetz/svn/gstreamer0.10-plugins-bad/BUILD/gst-plugins-bad-0.10.13.2/tests/check/generic/states 
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 22709.
Running suite(s): states
[New Thread 0x4059b470 (LWP 22696)]
[New Thread 0x40ee8b70 (LWP 22722)]
[Thread 0x40ee8b70 (LWP 22722) exited]
[New Thread 0x40ee8b70 (LWP 22739)]
[New Thread 0x43054b70 (LWP 22740)]
[New Thread 0x43255b70 (LWP 22741)]
[New Thread 0x43456b70 (LWP 22742)]
[Thread 0x43456b70 (LWP 22742) exited]
[Thread 0x43054b70 (LWP 22740) exited]
[Thread 0x43255b70 (LWP 22741) exited]
[Thread 0x40ee8b70 (LWP 22739) exited]
[New Thread 0x43456b70 (LWP 22747)]
Detaching after fork from child process 22748.
Detaching after fork from child process 22749.

GStreamer-CRITICAL **: gst_clock_get_time: assertion `GST_IS_CLOCK (clock)' failed
aborting...

Program received signal SIGTRAP, Trace/breakpoint trap.
IA__g_logv (log_domain=<value optimized out>, log_level=G_LOG_LEVEL_CRITICAL, format=0x401fccc5 "%s: assertion `%s' failed", 
    args1=0xbf88830c "��\020@\035�\020@�3\001@\210x\005\b\220D\034@x\234\020@�\237\023@������\t@x\234\020@��\020@\035�\020@\005p\n@X�\027\b�\232\005\bPH\025\b��\214C\200\003<@PH\025\bx\203\210�I") at gmessages.c:512
512               g_private_set (g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt

+ Trace 216896

Indeed, thanks.

Created attachment 140579 [details] [review]
mimenc: Refuse to go playing in paused-mode without clock

Only try to use the clock in if paused-mode is set and refuse to go playing
in paused-mode without it.

Fixes bug #591538

Created attachment 140580 [details] [review]
mimenc: USE GST_WRITE_*_LE macros

> Created an attachment (id=140579) [edit]
> mimenc: Refuse to go playing in paused-mode without clock

Thanks for the patch. Sorry for the nitpicking, but could you update this to use

  GST_ELEMENT_ERROR(enc, LIBRARY, SETTINGS, ("bla bla"), (NULL));

or so instead? Feel free to use STREAM, ENCODE or whatever other error code you find most suitable instead. (I believe the object lock has to be dropped before the GST_ELEMENT_ERROR then, fwiw).


> Created an attachment (id=140580) [edit]
> mimenc: USE GST_WRITE_*_LE macros

Looks good, please commit (I guess the timestamp writing was broken on big endian machines before then?).

Created attachment 140586 [details] [review]
mimenc: Refuse to go playing in paused-mode without clock

Now with added message posting

Thanks, please commit. (Btw, the GST_ELEMENT_ERROR macro already contains a GST_WARNING_OBJECT in addition to the message posting).

mimenc part done:

commit 4f61f46f073a940b7fab47ae165b8816ff74770c
Author: Olivier Crête <tester@tester.ca>
Date:   Wed Aug 12 12:23:30 2009 -0400

    mimenc: USE GST_WRITE_*_LE macros

commit 6001c6b5c0e438b4bab21a2babc0bad6cf6630a9
Author: Olivier Crête <tester@tester.ca>
Date:   Wed Aug 12 12:21:33 2009 -0400

    mimenc: Refuse to go playing in paused-mode without clock
    
    Only try to use the clock in if paused-mode is set and refuse to go playing
    in paused-mode without it.
    
    Fixes bug #591538

Götz: better now?

It is fixed now, thanks a lot.