Created attachment 317088 [details] [review]
disable orc in gst base video

Can you get a backtrace of all threads when it crashes? Also make sure to install debug symbols for libc, glib, gstreamer, gst-plugins-base and orc.

new found: if enable the ORC debugging by export ORC_DEBUG=5, crash gone

Please try with latest ORC.

You can also disable orc at run-time by using ORC_CODE=backup as environment variable.

The stack trace is not very useful, it's the wrong thread, not the thread that crashes. With

(gdb) threads apply all bt

you can get the state of all threads.

backtrace of all threads:

(gdb) info th
  Id   Target Id         Frame
  3    Thread 0x768b6460 (LWP 1183) "videotestsrc0:s" 0x76cd2cb4 in nanosleep () at ../sysdeps/unix/syscall-template.S:84
  2    Thread 0x75eff460 (LWP 1184) "gmain" 0x76c473c4 in poll () at ../sysdeps/unix/syscall-template.S:84
* 1    Thread 0x76fb9210 (LWP 1170) "gst-launch-1.0" 0x76c473c4 in poll () at ../sysdeps/unix/syscall-template.S:84
(gdb) t 2
[Switching to thread 2 (Thread 0x75eff460 (LWP 1184))]

+ Trace 235808

This trace does not show any crash either. Are you sure of what you are reporting ?

Nicolas, if you expand the stack trace and look further down you'll see the crash. It's in video_orc_pack_Y

Sorry, got confused by the nanosleep we use in our signal handler. On my side, I still can't reproduce on a similar CPU. Maybe we'll need a valgrind trace ? I wonder if a copy of the tmp-orc.c would help (it's at line 1390).

It looks like it's in the JIT generated code

void
video_orc_pack_Y (guint8 * ORC_RESTRICT d1, const guint8 * ORC_RESTRICT s1, int n)
{
  OrcExecutor _ex, *ex = &_ex;
  static volatile int p_inited = 0;
  static OrcCode *c = 0;
  void (*func) (OrcExecutor *);

  if (!p_inited) {
    orc_once_mutex_lock ();
    if (!p_inited) {
      OrcProgram *p;

#if 1
      static const orc_uint8 bc[] = {
        1, 9, 16, 118, 105, 100, 101, 111, 95, 111, 114, 99, 95, 112, 97, 99, 
        107, 95, 89, 11, 1, 1, 12, 4, 4, 20, 2, 190, 32, 4, 189, 0, 
        32, 2, 0, 
      };
      p = orc_program_new_from_static_bytecode (bc);
      orc_program_set_backup_function (p, _backup_video_orc_pack_Y);
#else
      p = orc_program_new ();
      orc_program_set_name (p, "video_orc_pack_Y");
      orc_program_set_backup_function (p, _backup_video_orc_pack_Y);
      orc_program_add_destination (p, 1, "d1");
      orc_program_add_source (p, 4, "s1");
      orc_program_add_temporary (p, 2, "t1");

      orc_program_append_2 (p, "select0lw", 0, ORC_VAR_T1, ORC_VAR_S1, ORC_VAR_D1, ORC_VAR_D1);
      orc_program_append_2 (p, "select1wb", 0, ORC_VAR_D1, ORC_VAR_T1, ORC_VAR_D1, ORC_VAR_D1);
#endif

      orc_program_compile (p);
      c = orc_program_take_code (p);
      orc_program_free (p);
    }
    p_inited = TRUE;
    orc_once_mutex_unlock ();
  }
  ex->arrays[ORC_VAR_A2] = c;
  ex->program = 0;

  ex->n = n;
  ex->arrays[ORC_VAR_D1] = d1;
  ex->arrays[ORC_VAR_S1] = (void *)s1;

  func = c->exec;
  func (ex);
}
#endif

that's the video_orc_pack_Y in tmp-orc.c and the line 1390 is "func (ex)",
the interest thing is that when I enable the ORC debugging by ORC_DEBUG=5, then no crash (at least for 3 hours running, I didn't test longer)

Hi All,

I've hit the same issue with various Cortex A9 boards (all i.MX based)
* Freescale iMX6QP sdb
* Wandboard solo

While troubleshooting I have come up with a similar test-case which fails every minute or so :

while [ 1 ]; do
  gst-launch-1.0 videotestsrc num-buffers=1 ! filesink location=/dev/null
done

This is on a yocto krogoth system running the following versions of gst/orc : 
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.6.3
GStreamer 1.6.3

$ orcc --version
Orc Compiler 0.4.24

Is there anything else I can do to help troubleshoot the issue ?

@Mingke I'm not sure that the fact that you did not see the issue with ORC_DEBUG=5 is relevant. This slows down processing by a lot due to prints. On my system setting ORC_DEBUG=5 and redirecting stdout / stderr to /dev/null trigerred the crash as well :

while [ 1 ]; do
  gst-launch-1.0 videotestsrc num-buffers=1 ! filesink location=/dev/null &>/dev/null
  echo "still alive $?"
done

I can reproduce on a Snapdragon 600 (currently running 1.10.0).

Running ORC 0.4.26, so it's not an old bug.

Nicolas, can you still reproduce with current gstreamer and orc ?

Still can reproduce this issue with gstreamer-1.14 on imx 6Q board

Still can reproduce this issue with gstreamer-1.14 on imx 6Q board

This needs debugging by someone with access to the actual hardware.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/orc/issues/11.