Segmentation fault at EOS

[gpalsingh]

lt-gst-launch-1.0: ../../include/c11/threads_posix.h:226: mtx_lock: Assertion `mtx != NULL' failed.

Thread 26 "video" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe2e1e700 (LWP 3122)]
0x00007ffff6f86428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6f86428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff6f8802a in __GI_abort () at abort.c:89
#2  0x00007ffff6f7ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7fffe09cf202 "mtx != NULL", file=file@entry=0x7fffe09cf1e0 "../../include/c11/threads_posix.h", line=line@entry=226, function=function@entry=0x7fffe09cf2a8 <__PRETTY_FUNCTION__.3798> "mtx_lock") at assert.c:92
#3  0x00007ffff6f7ec82 in __GI___assert_fail (assertion=0x7fffe09cf202 "mtx != NULL", file=0x7fffe09cf1e0 "../../include/c11/threads_posix.h", line=226, function=0x7fffe09cf2a8 <__PRETTY_FUNCTION__.3798> "mtx_lock") at assert.c:101
#4  0x00007fffe08cfdce in mtx_lock (mtx=0x0) at ../../include/c11/threads_posix.h:226
#5  0x00007fffe08d0337 in slab_free (pool=0x7fffd80ffe70, ptr=0x7fffd8138c60) at slab.c:262
#6  0x00007fffe097e383 in r600_buffer_transfer_unmap (ctx=0x7fffd80ffa80, transfer=0x7fffd8138c60) at r600_buffer_common.c:548
#7  0x00007fffe08521f3 in u_transfer_unmap_vtbl (pipe=0x7fffd80ffa80, transfer=0x7fffd8138c60) at util/u_transfer.c:154
#8  0x00007fffe07e126f in pipe_transfer_unmap (context=0x7fffd80ffa80, transfer=0x7fffd8138c60) at ../../../../src/gallium/auxiliary/util/u_inlines.h:482
#9  0x00007fffe07e1438 in h264e_outport_FreeBuffer (ap_obj=0x7fffd800a610, ap_hdl=0x7fffdc036f50, idx=1, buf=0x7fffd8150ee0) at h264eoutport.c:60
#10 0x00007fffe32acf05 in krn_FreeBuffer (ap_obj=0x7fffd8005ba0, ap_hdl=0x7fffdc036f50, a_pid=1, ap_hdr=0x7fffd8150ee0) at tizkernel.c:880
#11 0x00007fffe328c728 in dispatch_msg (ap_sched=ap_sched@entry=0x7fffdc004200, ap_state=ap_state@entry=0x7fffdc005300, ap_msg=0x62c030) at tizscheduler.c:2322
#12 0x00007fffe328c892 in il_sched_thread_func (p_arg=0x7fffdc004200) at tizscheduler.c:2410
#13 0x00007ffff73226ba in start_thread (arg=0x7fffe2e1e700) at pthread_create.c:333
#14 0x00007ffff70583dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[gpalsingh]

Reverting to https://github.com/gpalsingh/mesa/commit/67c6e145fc987096ea3e6527ba5c52618789c7ed still gives that error which used to work earlier. Could related to gstreamer instead.

[CapOM]

I found this is because deallocate is called before FreeBuffer during the transition state from Idle to Loaded. So it looks to me to be an issue in Tizonia, I reported to Juan here https://github.com/tizonia/tizonia-openmax-il/issues/364

Waiting for his feedback.

[tizonia]

Hi guys,

I think understand why changing the ordering (FreeBuffer vs prc_deallocate_resources) would help in this specific case. But I wonder if we can have another scenario in the future that breaks because the ordering is the opposite to what that scenario needs.

So in other words, can't this scenario be made to work with the current ordering?.

e.g.: here, the pipe should be assigned to NULL after destruction:

   if (p_prc->t_pipe) {
      p_prc->t_pipe->destroy(p_prc->t_pipe);
      p_prc->t_pipe = NULL;  // <--- to make it clear that this resource no longer exists
  }

And the FreeBuffer implementation maybe could take this into account:

   if (outp) {
      if (outp->transfer && p_prc->t_pipe)
         pipe_transfer_unmap(p_prc->t_pipe, outp->transfer);
      pipe_resource_reference(&outp->bitstream, NULL);
      FREE(outp);
      buf->pOutputPortPrivate = NULL;
   }
   buf->pBuffer = NULL;

I think I would need to understand better how the encoder port and the processor are sharing their resources. But maybe something along these lines would solve the problem?

[CapOM]

Thx for the suggestion. I thought about it but then it will leak the buffer as it cannot properly release if it is still mapped.

Another solution would be to add prc_deallocate_resources_after ? (and rename prc_deallocate_resources to prc_deallocate_resources_before), something like that so for more flexibility

[tizonia]

I think changing the ordering is probably the ideal solution. The problem is that adding another framework API to libtizonia or changing the ordering of events in such deep internals is (potentially) a major risk/effort.

I still believe this is solvable at component level (of course, at the expense of increasing a little bit the final LoC in the component):

So here is another idea:

• The FreeBuffer implementation currently accesses directly the processor internal member 't_pipe'. This breaks encapsulation. No issues, but I think it would be possible to expose a processor API that deals with this need on behalf of the port.

#ifndef H264EPRC_H
#define H264EPRC_H

void * h264e_prc_class_init(void * ap_tos, void * ap_hdl);
void * h264e_prc_init(void * ap_tos, void * ap_hdl);

OMX_ERRORTYPE h264e_prc_free_buffer_resources(void *ap_obj, 
struct pipe_transfer *transfer, 
struct pipe_resource *bitstream);

#endif                          /* H264EPRC_H */

So the encoder processor could expose a new 'free_buffer_resources' to deallocate those resources that have buffer dependencies. FreeBuffer would call 'free_buffer_resources' on the processor class, to unmap and release the buffer. The processor then maintains a reference count, and when this reaches 0, the pipe resource is destroyed. 'prc_deallocate_resources' could be kept to deallocate those resources that have no dependencies with existing buffers.

if (outp) {
      if (outp->transfer) {
         h264e_prc_t *p_prc = tiz_get_prc(ap_hdl);
         h264e_prc_free_buffer_resources(p_prc, outp->transfer, &outp->bitstream);
      }
      FREE(outp);
      buf->pOutputPortPrivate = NULL;
   }
   buf->pBuffer = NULL;

[CapOM]

It is not ideal but it is doable. Also in this case I think we should just move the pipe_t creation/destruction to h264eprc constructor/destructor. That should be easier. Thx

[CapOM]

Hi Gurkirpal, please cherry-pick my patch https://github.com/CapOM/mesa/commit/fe40ffa0112783340708e3f2d3bc9461761a5e96 . It fixes the issue.

[gpalsingh]

Works. Thx!