Crash while seeking video with TrueHD audio

[MilhouseVH]

Bug report

Describe the bug

Kodi will crash while seeking a video (any codec) with TrueHD audio - easily reproducible on Raspberry Pi (LibreELEC).

popcornmix has confirmed the issue:

I can confirm it happens on master (as well as newclock5), so I suspect it's not Pi specific (but given the crash is random and seems to be memory corruption it may need different conditions to occur on different platforms). Identifying when it first occurred would be useful.

Unfortunately this is not a new issue (which also suggests it's not a high priority!) - I can reproduce with a test build from 20180423.

I did test LibreELEC x86_64 and also Kodi on Ubuntu (x86_64) but could not reproduce. This issue may just be harder to reproduce on x86_64, and/or may affect other ARM systems.

Expected Behavior

Kodi does not crash and seeks correctly.

Actual Behavior

Kodi crashes.

Possible Fix

Avoid memory corruption that seems to be the cause of this issue.

To Reproduce

1. Play sample TrueHD video
2. Seek to 5 (seconds) using the numpad/keyboard
3. Kodi crashes

Debuglog

Debug-enabled crash logs from RPi3+ seeking to 5 seconds in sample video: http://ix.io/1IlX http://ix.io/1IlY

Non-debug crash log, showing crash in malloc(): http://ix.io/1IlW

Sample video

70MB sample video used for testing:

https://www.dropbox.com/s/mzre2sqgwswyhvz/hd_dolby_truehd_5.1_countdown_lossless.m2ts?dl=0

Your Environment

Used Operating system:

• [ ] Android

• [ ] iOS

• [X] Linux (LibreELEC)

• [ ] OSX

• [X] Raspberry-Pi

• [ ] Windows

• [ ] Windows UWP

• Operating system version/name: LibreELEC 9 and LibreELEC 10

• Kodi version: Kodi 18, Kodi 19

note: Once the issue is made we require you to update it with new information or Kodi versions should that be required. Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.

[popcornmix]

I could reproduce:

#0  tcache_get (tc_idx=0) at malloc.c:2934
#1  __GI___libc_malloc (bytes=12) at malloc.c:3042
#2  0x01906a68 in av_packet_add_side_data (pkt=pkt@entry=0x65bbf8a0, type=type@entry=AV_PKT_DATA_MPEGTS_STREAM_ID, data=0x6e74ae20 "\275\322\360y", size=size@entry=1) at libavcodec/avpacket.c:315
#3  0x01906b10 in av_packet_new_side_data (pkt=pkt@entry=0x65bbf8a0, type=AV_PKT_DATA_MPEGTS_STREAM_ID, size=size@entry=1) at libavcodec/avpacket.c:341
#4  0x01907260 in av_packet_copy_props (dst=<optimized out>, src=<optimized out>) at libavcodec/avpacket.c:580
#5  0x00900690 in CDVDDemuxUtils::StoreSideData (pkt=pkt@entry=0x6e7648e0, src=src@entry=0x6e741dd8) at /home/dom/xbmc_holder/xbmc/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxUtils.cpp:80
#6  0x008fcc10 in CDVDDemuxFFmpeg::Read (this=0x6e741d40) at /home/dom/xbmc_holder/xbmc/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxFFmpeg.cpp:1037
#7  0x00949554 in CVideoPlayer::ReadPacket (this=this@entry=0x53c7260, packet=@0x65bbf990: 0x0, stream=Reading in symbols for /home/dom/xbmc_holder/xbmc/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemux.cpp...
    done.
@0x65bbf994: 0x0) at /home/dom/xbmc_holder/xbmc/xbmc/cores/VideoPlayer/VideoPlayer.cpp:1127
#8  0x00950e8c in CVideoPlayer::Process (this=0x53c7260) at /home/dom/xbmc_holder/xbmc/xbmc/cores/VideoPlayer/VideoPlayer.cpp:1556
#9  0x00b61118 in CThread::Action (this=this@entry=0x53c7270) at /home/dom/xbmc_holder/xbmc/xbmc/threads/Thread.cpp:208
#10 0x00b628c4 in CThread::staticThread (data=0x53c7270) at /home/dom/xbmc_holder/xbmc/xbmc/threads/Thread.cpp:116
#11 0x76ec1494 in start_thread (arg=0x65bc03b0) at pthread_create.c:486
#12 0x761c74e8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /opt/bcm-rootfs/lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Also got corrupted size vs. prev_size printed to console. Happens on kodi master (as well as newclock5). Possibly giving ffmpeg too small or insufficiently aligned buffers and it is overwriting the end of them causing fairly random crashes later?

[KarellenX]

I was just about to submit an issue for Audio crashes on Windows10 using WASAPI when using Skip Steps, but I think this may be the same problem. I have also noticed a steady trickle of similar reports on the forum.

Log here... https://paste.ubuntu.com/p/JQ8X86nHtV/ Playback commences line 2996 Errors commence approx line 3300

Using m2ts file, it is reproducible on two separate Win10 PC's and results in unresponsive Windows, requiring a reboot. I did leave my PC for 20min, then had limited use of Windows, but noticed my audio drivers were no longer available, so needed to reboot anyway.

The media files are using DTS MA-HD though, not TrueHD

Could not reproduce in v17.6. Could not reproduce in v18.3- KodiSetup-20190602-cf9c1b2d-master-x64

If not the same problem, let me know and I will create a new issue.

[cg110]

While I dislike me too posts, I've been seeing what is probably this issue of seeking crashing since moving to libreelec 9.0.x on pi3

I don't generally seek much though, but sometimes the kids want to jump to something, eg lego movie 2, this song's going to get stuck inside your head, and one of the chapter points seems to hit this issue pretty much every time time.

The minimal digging I have time to make, I note that libreelec is using the 4.0.3 version of ffmpeg, and that there's a very new ffmpeg 4.0.4-xbmc just been released (7 days ago so I'm not surprised it hasn't rippled through yet): https://github.com/xbmc/FFmpeg/releases/tag/4.0.4-Leia-18.4

Switching to the dts-ma sound track and I can skip around as desired. Also resuming the file from it's last point seems to also work (perhaps the seek is different for a restart to a chapter skip)

I wish I had the time to dig in further, but I sadly don't any more. Those doing regular builds might want to try with an updated ffmpeg, although I can't see any fixes to the upstream ffmpeg truehd decoder, so it may need debugging to work out what is doing the memory scribble/corruption.

[MilhouseVH]

@cg110 try the latest LE10/Kodi 19 nightly (#0809 and later) as this includes the updated FFmpeg. I'll try repeating my own testing with ffmpeg-4.0.4 later.

[MilhouseVH]

I just tested my latest #0815 RPi2 LibreELEC nightly with ffmpeg-4.0.4 and Kodi continues to crash when seeking while playing the sample TrueHD video (see link in first post), whether passthrough is enabled or not.

I'm still not able to reproduce on x86_64.

[MilhouseVH]

With MMAL hardware acceleration disabled I can seek without crashing.

[sopparus]

Still happens today on libreelec, OS reboots

[github-actions[bot]]

This issue is now marked stale because it has been open over a year without activity. Remove the stale label or add a comment to reset the stale state.