Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

mpp_slots_set_prop error with vpu hardware decoder #1

Closed
geekerlw opened this issue Jan 12, 2017 · 1 comment
Closed

mpp_slots_set_prop error with vpu hardware decoder #1

geekerlw opened this issue Jan 12, 2017 · 1 comment

Comments

@geekerlw
Copy link

I just found your gstreamer-rockchip plugin may not work without h264parse, when I debug the gstreamer programs, each time I played the video , the error blow printed:

mpp_buf_slot: mpp_slots_set_prop found invalid input slots 0xa78822a0 type 3 val (nil)

I don't know how to debug gstreamer with mpp, and I'll give the current log I got here:
With the --gst-debug=vpudec:5,vpubufferpool:5,h264parse:5 , I got the debug log as blow:
one is normal when the video switched: http://paste.fedoraproject.org/525878/41931441/
another is stoped playing at the last frame 239: http://paste.fedoraproject.org/525879/14841932/
The video is looped again and again, and It's 239 frames, I don't know why it didn't got an eos message at the last frame?
@hizukiayaka
Copy link
Contributor

It is just a warning message, harmless.

hizukiayaka pushed a commit that referenced this issue Mar 9, 2017
@HermanChen
[h264d]: remove useless code to disabe warning
00ee65d 
Fix issue:
#1

It makes no sense and generates an uncomfortable warning message:
mpp_buf_slot: mpp_slots_set_prop found invalid input slots

Change-Id: I8a26cd58aa10d03add371c88bb81e19f2a83cd70
Signed-off-by: Randy Li <randy.li@rock-chips.com>
@dalmatele dalmatele mentioned this issue Sep 22, 2017
Closed
@wshyu wshyu mentioned this issue Aug 16, 2018
Closed
ydirson referenced this issue in BladeGroup/mpp Sep 4, 2018
Fix buffer overflow scanning soc_name.
73b5f21 
The soc_name we read from device-tree is NUL-separated so we need to
replace intervening NUL chars, but we don't want to replace the last
one, or the next call to strstr() will overflow the buffer.

Detected with address-sanitizer:

    ==3271==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f940026a0 at pc 0x7f97df7160 bp 0x7fee1fa8e0 sp 0x7fee1fa958
    READ of size 97 at 0x7f940026a0 thread T0
        #0 0x7f97df715f  (/usr/lib/libasan.so.3+0x4215f)
        #1 0x7f97df745b in __interceptor_strstr (/usr/lib/libasan.so.3+0x4245b)
        #2 0x7f97d6b27b in MppPlatformService::MppPlatformService() (/usr/lib/librockchip_mpp.so.1+0x8727b)
        #3 0x7f97d6b64f in mpp_get_vcodec_type (/usr/lib/librockchip_mpp.so.1+0x8764f)
        #4 0x7f97d38da3 in hal_h264d_init (/usr/lib/librockchip_mpp.so.1+0x54da3)

    0x7f940026a0 is located 0 bytes to the right of 96-byte region [0x7f94002640,0x7f940026a0)
    allocated by thread T0 here:
        #0 0x7f97e6445b in __interceptor_posix_memalign (/usr/lib/libasan.so.3+0xaf45b)
        #1 0x7f97d6ed13 in os_malloc (/usr/lib/librockchip_mpp.so.1+0x8ad13)
        #2 0x7f97d6e54b in mpp_osal_malloc (/usr/lib/librockchip_mpp.so.1+0x8a54b)
        #3 0x7f97d6b1d7 in MppPlatformService::MppPlatformService() (/usr/lib/librockchip_mpp.so.1+0x871d7)
        #4 0x7f97d6b64f in mpp_get_vcodec_type (/usr/lib/librockchip_mpp.so.1+0x8764f)
        #5 0x7f97d38da3 in hal_h264d_init (/usr/lib/librockchip_mpp.so.1+0x54da3)
        #6 0x7f97d387c7 in mpp_hal_init (/usr/lib/librockchip_mpp.so.1+0x547c7)
        #7 0x7f97d02ad3 in mpp_dec_init (/usr/lib/librockchip_mpp.so.1+0x1ead3)
        #8 0x7f97cfda3f in Mpp::init(MppCtxType, MppCodingType) (/usr/lib/librockchip_mpp.so.1+0x19a3f)
        #9 0x7f97d0056f in mpp_init (/usr/lib/librockchip_mpp.so.1+0x1c56f)
        #10 0x404347 in mpi_dec_test_decode (/home/root/rockchip-mpp-test/mpi_dec_test+0x404347)
        #11 0x4057b3 in main (/home/root/rockchip-mpp-test/mpi_dec_test+0x4057b3)
        #12 0x7f97bba563 in __libc_start_main (/lib/libc.so.6+0x1f563)
        #13 0x402217  (/home/root/rockchip-mpp-test/mpi_dec_test+0x402217)

    SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/libasan.so.3+0x4215f)
    Shadow bytes around the buggy address:
      0x1ff2800480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    =>0x1ff28004d0: 00 00 00 00[fa]fa fa fa fa fa fa fa 00 00 00 00
      0x1ff28004e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
      0x1ff28004f0: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
      0x1ff2800500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa

Signed-off-by: Yann Dirson <yann@blade-group.com>
HermanChen pushed a commit that referenced this issue Sep 5, 2018
@HermanChen
Fix buffer overflow scanning soc_name.
621dd85 
The soc_name we read from device-tree is NUL-separated so we need to
replace intervening NUL chars, but we don't want to replace the last
one, or the next call to strstr() will overflow the buffer.

Detected with address-sanitizer:

    ==3271==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f940026a0 at pc 0x7f97df7160 bp 0x7fee1fa8e0 sp 0x7fee1fa958
    READ of size 97 at 0x7f940026a0 thread T0
        #0 0x7f97df715f  (/usr/lib/libasan.so.3+0x4215f)
        #1 0x7f97df745b in __interceptor_strstr (/usr/lib/libasan.so.3+0x4245b)
        #2 0x7f97d6b27b in MppPlatformService::MppPlatformService() (/usr/lib/librockchip_mpp.so.1+0x8727b)
        #3 0x7f97d6b64f in mpp_get_vcodec_type (/usr/lib/librockchip_mpp.so.1+0x8764f)
        #4 0x7f97d38da3 in hal_h264d_init (/usr/lib/librockchip_mpp.so.1+0x54da3)

    0x7f940026a0 is located 0 bytes to the right of 96-byte region [0x7f94002640,0x7f940026a0)
    allocated by thread T0 here:
        #0 0x7f97e6445b in __interceptor_posix_memalign (/usr/lib/libasan.so.3+0xaf45b)
        #1 0x7f97d6ed13 in os_malloc (/usr/lib/librockchip_mpp.so.1+0x8ad13)
        #2 0x7f97d6e54b in mpp_osal_malloc (/usr/lib/librockchip_mpp.so.1+0x8a54b)
        #3 0x7f97d6b1d7 in MppPlatformService::MppPlatformService() (/usr/lib/librockchip_mpp.so.1+0x871d7)
        #4 0x7f97d6b64f in mpp_get_vcodec_type (/usr/lib/librockchip_mpp.so.1+0x8764f)
        #5 0x7f97d38da3 in hal_h264d_init (/usr/lib/librockchip_mpp.so.1+0x54da3)
        #6 0x7f97d387c7 in mpp_hal_init (/usr/lib/librockchip_mpp.so.1+0x547c7)
        #7 0x7f97d02ad3 in mpp_dec_init (/usr/lib/librockchip_mpp.so.1+0x1ead3)
        #8 0x7f97cfda3f in Mpp::init(MppCtxType, MppCodingType) (/usr/lib/librockchip_mpp.so.1+0x19a3f)
        #9 0x7f97d0056f in mpp_init (/usr/lib/librockchip_mpp.so.1+0x1c56f)
        #10 0x404347 in mpi_dec_test_decode (/home/root/rockchip-mpp-test/mpi_dec_test+0x404347)
        #11 0x4057b3 in main (/home/root/rockchip-mpp-test/mpi_dec_test+0x4057b3)
        #12 0x7f97bba563 in __libc_start_main (/lib/libc.so.6+0x1f563)
        #13 0x402217  (/home/root/rockchip-mpp-test/mpi_dec_test+0x402217)

    SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/libasan.so.3+0x4215f)
    Shadow bytes around the buggy address:
      0x1ff2800480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    =>0x1ff28004d0: 00 00 00 00[fa]fa fa fa fa fa fa fa 00 00 00 00
      0x1ff28004e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
      0x1ff28004f0: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
      0x1ff2800500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa

Change-Id: Ia529035847cc23c612e4039e3d445db9d014d31f
Signed-off-by: Yann Dirson <yann@blade-group.com>
@johlim johlim mentioned this issue Sep 11, 2018
Closed
@zhuboMr zhuboMr mentioned this issue May 28, 2019
Closed
This was referenced Aug 5, 2019
Closed
Closed
@jbloomfield2008 jbloomfield2008 mentioned this issue Feb 21, 2020
Open
@jasonwxj2009 jasonwxj2009 mentioned this issue Aug 3, 2020
Closed
@jiale-gdyd jiale-gdyd mentioned this issue Aug 18, 2021
Open
HermanChen pushed a commit that referenced this issue Feb 25, 2022
@Caesar-github @HermanChen
[mpp_service]: Fix error on reg offset setup
5c0859c 
Fix error in commit fb3390c
Error log:

[   60.923201] rk_vcodec: reg[-2080222496] + offset 127
[   60.923216] Unable to handle kernel paging request at virtual address ffffff83263859f4
[   61.004607] Mem abort info:
[   61.004877]   ESR = 0x96000005
[   61.005154]   EC = 0x25: DABT (current EL), IL = 32 bits
[   61.005623]   SET = 0, FnV = 0
[   61.005898]   EA = 0, S1PTW = 0
[   61.006172] Data abort info:
[   61.006425]   ISV = 0, ISS = 0x00000005
[   61.006764]   CM = 0, WnR = 0
[   61.007031] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000017e5000
[   61.007621] [ffffff83263859f4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[   61.008407] Internal error: Oops: 96000005 [#1] SMP
[   61.008835] Modules linked in: rk_vcodec
[   61.009194] CPU: 1 PID: 1537 Comm: mpp_dec_parser Not tainted 5.10.66 #10
[   61.009793] Hardware name: Rockchip RK3588 EVB3 LP5 V10 Board (DT)
[   61.010340] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[   61.010900] pc : mpp_translate_reg_offset_info+0xec/0xfc [rk_vcodec]
[   61.011469] lr : mpp_translate_reg_offset_info+0xdc/0xfc [rk_vcodec]
[   61.012025] sp : ffffffc013f33a90

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I023db0c7c930ec54bfbc1141bef3543a295b165a
@Allenhe123 Allenhe123 mentioned this issue May 25, 2022
Closed
@sukesh-g sukesh-g mentioned this issue May 30, 2022
Open
HermanChen pushed a commit that referenced this issue Aug 1, 2022
@HermanChen
[allocator]: fix dma_heap allocator
652e18f 
segment fault happened in mpp_allocator_put.
 #00 pc 00102e14  /vendor/lib/libmpp.so (mpp_allocator_put+272)
 #1 pc 0004705c  /vendor/lib/libmpp.so (MppBufferService::~MppBufferService()+536)

Signed-off-by: xueman.ruan <xueman.ruan@rock-chips.com>
Change-Id: Ia4f9a3b4823bf6a5d8f3fdfd85055630222c0b43
HermanChen pushed a commit that referenced this issue Dec 9, 2022
@qvoid
[iep2]:fix crash on mv update
2c93f73 
backtrace:
      #00 pc 00071fa4  /vendor/lib/libmpp.so (iep2_is_subt_mv+40)
      #1 pc 00072290  /vendor/lib/libmpp.so (iep2_update_gmv+548)
      #2 pc 0007056c  /vendor/lib/libmpp.so (iep2_done+176)

Change-Id: I0d8cd49a3df87150273216ac0110baae4918c14a
Signed-off-by: Johnson Ding <johnson.ding@rock-chips.com>
HermanChen pushed a commit that referenced this issue Dec 27, 2022
@HermanChen
[mpp_buffer]: fix group callback crash
5d3623a 
thread1:
  1)control(MPP_DEC_SET_EXT_BUF_GROUP)
  2)mpp_buffer_group_set_callback
    p->callback = callback;
thread2:
  1)mpp_buffer_commit
  2)mpp_buffer_create
    group->callback(group->arg, group);
    But arg is NULL now.

backtrace:
  #00 (Mpp::notify(void*))
  #1 (mpp_buffer_create+712)
  #2 (mpp_buffer_import_with_tag+212)
  #3 (commit_memory_handle+116)

Signed-off-by: Grey Li <grey.li@rock-chips.com>
Change-Id: Id50e2f1b46d127c8bf0fe8080751949fcccc6e25
@cpmbailey cpmbailey mentioned this issue Jan 29, 2023
Closed
@Yg-Luo Yg-Luo mentioned this issue May 10, 2023
Closed
HermanChen pushed a commit that referenced this issue Nov 1, 2023
@HermanChen
fix[mpp_dec]:fix mpp_destroy crash
09e859a 
Fixed a crash issue in mpp_destroy stage caused by calling members of a recycled parser thread.

crash backtrace:
#00 pc 00084882  /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+6)
#1 pc 00081434  /vendor/lib/libmpp.so (mpp_dec_notify_normal(MppDecImpl_t*, unsigned int)+32)
#2 pc 0007d6cc  /vendor/lib/libmpp.so (mpp_dec_callback_slot(char const*, void*, int, void*)+112)
#3 pc 000937f0  /vendor/lib/libmpp.so (mpp_buf_slot_clr_flag+944)
#4 pc 000da960  /vendor/lib/libmpp.so (mpp_hevc_unref_frame+168)
#5 pc 000d1c50  /vendor/lib/libmpp.so (h265d_deinit+32)
#6 pc 00081908  /vendor/lib/libmpp.so (mpp_parser_deinit+40)
#7 pc 0007e24c  /vendor/lib/libmpp.so (mpp_dec_deinit+548)
#8 pc 0006b4f0  /vendor/lib/libmpp.so (Mpp::clear()+104)
#9 pc 0006b61c  /vendor/lib/libmpp.so (Mpp::~Mpp()+12)
#10 pc 0006f7e0  /vendor/lib/libmpp.so (mpp_destroy+152)
#11 pc 00003d1c  /vendor/bin/mpi_dec_test (dec_decode+984)


Change-Id: I985168aa6ef30a265fce17c2d9765c17a24075c8
Signed-off-by: Yanjun Liao <yanjun.liao@rock-chips.com>
@xlwlp xlwlp mentioned this issue Jan 17, 2024
Open
@andymatos andymatos mentioned this issue Feb 6, 2024
Closed
HermanChen pushed a commit that referenced this issue Feb 6, 2024
@qvoid
fix[h265e_vepu580]: fix SIGSEGV when reencoding
aa92148 
Hal buffer one_used marking will be wrong when reencoding.

Error log:
    "hal_bufs: hal_bufs_get_buf invalid input impl 0xf3500a60 buf_idx 4"
backtrace:
  #00 pc 0023e39c  /vendor/lib/libmpp.so (vepu580_h265_set_hw_address+328)
  #1 pc 0023f344  /vendor/lib/libmpp.so (hal_h265e_v580_gen_regs+2432)
  #2 pc 00233980  /vendor/lib/libmpp.so (hal_h265ev2_gen_regs+132)
  #3 pc 0008de04  /vendor/lib/libmpp.so (mpp_enc_hal_gen_regs+200)
  #4 pc 000805f0  /vendor/lib/libmpp.so (mpp_enc_normal(Mpp*, EncAsyncTaskInfo_t*)+1988)
  #5 pc 0007b380  /vendor/lib/libmpp.so (try_proc_normal_task(MppEncImpl_t*, EncAsyncTaskInfo_t*)+128)
  #6 pc 00078e50  /vendor/lib/libmpp.so (mpp_enc_thread+1340)

Change-Id: I5137a3db0ff63ee55a83c2d63da4430d2fc362b1
Signed-off-by: Johnson Ding <johnson.ding@rock-chips.com>
HermanChen added a commit that referenced this issue Feb 6, 2024
@HermanChen
fix[vproc]: Fix deadlock in vproc thread
9431bbc 
BUG is reported from https://redmine.rock-chips.com/issues/464206

Thread 18 (LWP 2440):
#0  __lll_lock_wait (futex=0x7f34000d48, private=0) at lowlevellock.c:52
#1  0x0000007fab5b1540 in __GI___pthread_mutex_lock (mutex=0x7f34000d48) at pthread_mutex_lock.c:115
#2  0x0000007fa9e0299c in dec_vproc_signal (ctx=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:929
#3  0x0000007fa9df5bdc in mpp_dec_notify (ctx=0x7f602be600, flag=1088) at ../git/mpp/codec/mpp_dec.cpp:956
#4  0x0000007fa9e0ef30 in mpp_buffer_ref_dec (buffer=0x7f6403f6c8, caller=caller@entry=0x7fa9ee300c "mpp_frame_deinit") at ../git/mpp/base/mpp_buffer_impl.cpp:509
#5  0x0000007fa9e0fb84 in mpp_buffer_put_with_caller (buffer=<optimized out>, caller=caller@entry=0x7fa9ee300c "mpp_frame_deinit") at ../git/mpp/base/mpp_buffer.cpp:105
#6  0x0000007fa9e11820 in mpp_frame_deinit (frame=frame@entry=0x7f602ec340) at ../git/mpp/base/mpp_frame.cpp:85
#7  0x0000007fabd6bf4c in rkmpp_release_frame (opaque=<optimized out>, data=0x7f602ba600 <error: Cannot access memory at address 0x7f602ba600>) at src/libavcodec/rkmppdec.c:339
#8  0x0000007fab9547dc in buffer_replace (src=0x0, dst=<optimized out>) at src/libavutil/buffer.c:133
#9  av_buffer_unref (buf=<optimized out>) at src/libavutil/buffer.c:144
#10 0x0000007fac714bb8 in mp_image_destructor (ptr=0x7f60252c80) at ../../../../../../sources/mpv/video/mp_image.c:209
#11 0x0000007fac748d40 in ta_free (ptr=0x7f60252c80) at ../../../../../../sources/mpv/ta/ta.c:244
#12 0x0000007fac715178 in mp_image_unrefp (p_img=p_img@entry=0x7f4c00bfc0) at ../../../../../../sources/mpv/video/mp_image.c:472
#13 0x0000007fac73396c in wlbuf_pool_entry_release (data=0x7f4c00bfa0, wl_buffer=<optimized out>) at ../../../../../../sources/mpv/video/out/wlbuf_pool.c:132
#14 0x0000007fb4cfe328 in ffi_call_SYSV () at ../libffi-3.3/src/aarch64/sysv.S:114
#15 0x0000007fb4cfdb44 in ffi_call_int (cif=cif@entry=0x7f70fdec80, fn=0x7f70fdeca0, orig_rvalue=orig_rvalue@entry=0x0, avalue=0x10, avalue@entry=0x7f70fded50, closure=0x200000001, closure@entry=0x0) at ../libffi-3.3/src/aarch64/ffi.c:747
#16 0x0000007fb4cfdf24 in ffi_call (cif=cif@entry=0x7f70fdec80, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7f70fded50) at ../libffi-3.3/src/aarch64/ffi.c:756
#17 0x0000007faa49c7c0 in wl_closure_invoke (closure=0x7f4c00bff0, flags=<optimized out>, target=<optimized out>, opcode=0, data=<optimized out>) at ../wayland-1.22.0/src/connection.c:1025
#18 0x0000007faa499df0 in dispatch_event (display=display@entry=0x7f4c001d40, queue=<optimized out>) at ../wayland-1.22.0/src/wayland-client.c:1644
#19 0x0000007faa49b2c8 in dispatch_queue (queue=0x7f4c001e30, display=0x7f4c001d40) at ../wayland-1.22.0/src/wayland-client.c:1790
#20 wl_display_dispatch_queue_pending (display=0x7f4c001d40, queue=0x7f4c001e30) at ../wayland-1.22.0/src/wayland-client.c:2032
#21 0x0000007faa49b2f4 in wl_display_dispatch_pending (display=<optimized out>) at ../wayland-1.22.0/src/wayland-client.c:2095
#22 0x0000007fac73e2cc in vo_wayland_dispatch_events (wl=0x7f4c000e40, nfds=nfds@entry=2, timeout=timeout@entry=100) at ../../../../../../sources/mpv/video/out/wayland_common.c:1933
#23 0x0000007fac741d7c in vo_wayland_wait_events_timeout (vo=vo@entry=0x7f600abed0, timeout_ms=timeout_ms@entry=100) at ../../../../../../sources/mpv/video/out/wayland_common.c:2594
#24 0x0000007fac73baf4 in draw_frame (vo=0x7f600abed0, frame=0x7f302063b0) at ../../../../../../sources/mpv/video/out/vo_dmabuf_wayland.c:1113
#25 0x0000007fac7360c4 in render_frame (vo=0x7f600abed0) at ../../../../../../sources/mpv/video/out/vo.c:984
#26 vo_thread (ptr=0x7f600abed0) at ../../../../../../sources/mpv/video/out/vo.c:1123
#27 0x0000007fab5af370 in start_thread (arg=0x7f72ffbe06) at pthread_create.c:477
#28 0x0000007fab51bedc in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 14 (LWP 3455):
#0  __lll_lock_wait (futex=0x7f60208040, private=0) at lowlevellock.c:52
#1  0x0000007fab5b1540 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7f60208040) at pthread_mutex_lock.c:115
#2  0x0000007fa9e0ef48 in mpp_buffer_ref_dec (buffer=0x7f6406fee8, caller=caller@entry=0x7fa9ee1ae7 "check_entry_unused") at ../git/mpp/base/mpp_buffer_impl.cpp:503
#3  0x0000007fa9e0fb84 in mpp_buffer_put_with_caller (buffer=<optimized out>, caller=caller@entry=0x7fa9ee1ae7 "check_entry_unused") at ../git/mpp/base/mpp_buffer.cpp:105
#4  0x0000007fa9e0bf1c in check_entry_unused (entry=0x7f601ef530, impl=0x7f60263ec0) at ../git/mpp/base/mpp_buf_slot.cpp:627
#5  mpp_buf_slot_clr_flag (slots=0x7f60263ec0, index=<optimized out>, type=type@entry=SLOT_QUEUE_USE) at ../git/mpp/base/mpp_buf_slot.cpp:919
#6  0x0000007fa9e00eb0 in dec_vproc_clr_prev0 (ctx=ctx@entry=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:149
#7  0x0000007fa9e00fd0 in dec_vproc_clr_prev (ctx=ctx@entry=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:180
#8  0x0000007fa9e012b8 in dec_vproc_thread (data=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:631
#9  0x0000007fab5af370 in start_thread (arg=0x7f47ffdf16) at pthread_create.c:477
#10 0x0000007fab51bedc in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I742e55e745c46a4adb229e2f6f0e2a2c3498e369
@HouLingLXH HouLingLXH mentioned this issue Mar 19, 2024
Closed
scottlamb added a commit to scottlamb/mpp that referenced this issue Apr 13, 2024
@scottlamb
fix crash after init vepu buffer failure
c8181fe 
If initialization fails as follows:

```
Apr 13 12:38:23 rock-5b mpp[9997]: hal_h264e_vepu580: hal_h264e_vepu580_init init vepu buffer failed ret: -1
```

...then `hal_h264e_vepu580_init` calls `h264e_vepu_stream_amend_deinit`
before initializing `amend_sets`, which goes badly:

```
(lldb) frame select 1
frame rockchip-linux#1: 0x0000007ff4b3d77c
librockchip_mpp.so`hal_h264e_vepu580_deinit(hal=0x0000007ff000b5a0) at
hal_h264e_vepu580.c:218:9
   215      clear_ext_line_bufs(p);
   216
   217      for (i = 0; i < p->task_cnt; i++)
-> 218          h264e_vepu_stream_amend_deinit(&p->amend_sets[i]);
   219
   220      MPP_FREE(p->regs_sets);
   221      MPP_FREE(p->amend_sets);
(lldb) print p->amend_sets
(HalH264eVepuStreamAmend *) $0 = 0x0000000000000000
```
@handring97 handring97 mentioned this issue May 16, 2024
Open
@ramiropolla ramiropolla mentioned this issue Jul 1, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hizukiayaka @geekerlw