Sonarr crashing (coredump / SIGSEGV) in libmediainfo.so

UbiquitousPhoton · April 17, 2023, 11:31am

Sonarr version (exact version): 3.0.9.1549-4.7 (Home:Junknot OBS repository)
Mono version (if Sonarr is not running on Windows): 6.12.0.122
OS: OpenSuse Tumbleweed
Debug logs: (See below)
Description of issue:

Hi all, Sonarr has been crashing on me relatively constantly since upgrading to the latest version - initially this was happening on initial import of the library after upgrade, but I moved some files out of the way and managed to stop that, now its happening on downloading new releases.

I have recovered the stack trace from the journal:


        Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
=================================================================
        Native stacktrace:
=================================================================
        0x55e480b77cd0 - /usr/bin/mono :
        0x55e480b78079 - /usr/bin/mono :
        0x55e480b26e71 - /usr/bin/mono :
        0x55e480b7189d - /usr/bin/mono :
        0x7ff21af68476 - /lib64/libmediainfo.so.0 :
=================================================================

at <unknown> <0xffffffff>
at NzbDrone.Core.MediaFiles.MediaInfo.MediaInfo:MediaInfo_Open_Buffer_Continue <0x000b8>
at NzbDrone.Core.MediaFiles.MediaInfo.MediaInfo:Open <0x000ff>
at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader:GetMediaInfo <0x00293>
at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader:GetRunTime <0x0004f>
at NzbDrone.Core.MediaFiles.EpisodeImport.DetectSample:IsSample <0x0016d>
at <>c__DisplayClass14_0:<GetNonSampleVideoFileCount>b__0 <0x00050>
at System.Linq.Enumerable:Count <0x000c8>
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetNonSampleVideoFileCount <0x001af>
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetImportDecisions <0x001c3>
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetImportDecisions <0x0005f>
at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService:ProcessFolder <0x0044c>
at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService:ProcessPath <0x000ef>
at NzbDrone.Core.Download.CompletedDownloadService:Import <0x0010e>
at NzbDrone.Core.Download.DownloadProcessingService:Execute <0x002b0>
at NzbDrone.Core.Messaging.Commands.CommandExecutor:ExecuteCommand <0x00210>
at System.Object:CallSite.Target <0x00122>
at System.Dynamic.UpdateDelegates:UpdateAndExecuteVoid3 <0x001bc>
at System.Object:CallSite.Target <0x00191>
at NzbDrone.Core.Messaging.Commands.CommandExecutor:ExecuteCommands <0x0032f>
at System.Threading.ThreadHelper:ThreadStart_Context <0x000aa>
at System.Threading.ExecutionContext:RunInternal <0x00191>
at System.Threading.ExecutionContext:Run <0x00042>
at System.Threading.ExecutionContext:Run <0x00063>
at System.Threading.ThreadHelper:ThreadStart <0x00042>
at System.Object:runtime_invoke_void__this__ <0x00091>

The crashed thread is the libmediainfo.so one.

The trace logs contain literally nothing unusual, however the last entry in the log is usually something along the form of :

2023-04-14 02:26:20.3|Debug|ImportDecisionMaker|Analyzing 1/1 files.
2023-04-14 02:26:20.3|Debug|Parser|Parsing string 'Station.19.S06E14.720p.HDTV.x264-SYNCOPY'
2023-04-14 02:26:20.3|Trace|Parser|^(?<title>.+?)(?:(?:[-_\W](?<![()\[!]))+S?(?<season>(?<!\d+)(?:\d{1,2})(?!\d+))(?:[ex]|\W[ex]){1,2}(?<episode>\d{2,3}(?!\d+))(?:(?:\-|[ex]|\W[ex]|_){1,2}(?<episode>\d{2,3}(?!\d+)))*)\W?(?!\\)
2023-04-14 02:26:20.3|Debug|Parser|Episode Parsed. Station 19 - S06E14
2023-04-14 02:26:20.3|Debug|Parser|Language parsed: English
2023-04-14 02:26:20.3|Debug|QualityParser|Trying to parse quality for Station.19.S06E14.720p.HDTV.x264-SYNCOPY
2023-04-14 02:26:20.3|Debug|Parser|Quality parsed: HDTV-720p v1
2023-04-14 02:26:20.3|Debug|Parser|Release Group parsed: SYNCOPY
2023-04-14 02:26:20.3|Debug|VideoFileInfoReader|Getting media info from /home/(removed)/.sabnzbd/downloads/complete/Station.19.S06E14.720p.HDTV.x264-SYNCOPY/b8ef54b3cda8455bbb65814bb94a2e13.mkv

is it possible my libmediainfo.so is somehow incompatible? Its quite difficult to tell, as its not versioned on my system:

file /usr/lib64/libmediainfo.so.0.0.0
/usr/lib64/libmediainfo.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=61a5cf2fde04f271fbe2bd2e0473f98b11b2f2fd, stripped

Any help would be gratefully received. I can post full logs if necessary, but there is literally nothing in even the trace logs that shows anything wrong, they just … stop after “getting media info”

rmadi · April 17, 2023, 12:04pm

Sounds like I have a similar problem with Sonarr crashing.

=================================================================
        Native stacktrace:
=================================================================
        0x4b8ac3 - /bin/mono : (null)
        0x4b8dcc - /bin/mono : (null)
        0x464c71 - /bin/mono : (null)
        0x4b193f - /bin/mono : (null)
        0x7fd19575fb8d - /lib64/libmediainfo.so.0 : _ZN6ZenLib12BitStream_LE3GetEm

Linux 3.10.0-1160.88.1.el7.x86_64

I’ll be following this thread with interest.

UbiquitousPhoton · April 17, 2023, 1:21pm

Hi - what version of libmediainfo do you have? My system upgraded to 23.03-1.1 from 22.12-1.2 on the 1st April, which is about when the crashes started for me, and the major version upgrade makes me extremely suspicious. I was going to attempt an upgrade to 3.10 to see if it fixes anything, but this now looks less likely.

rmadi · April 18, 2023, 10:01am

Sorry to hijack your thread, just wanted to say thanks for the pointer. This was exactly my problem. Once I downgraded libmediainfo and mediainfo it is stable again.

Here’s what I did to tide me over until there’s a more permanent fix:

yum erase mediainfo libmediainfo
wget https://kojipkgs.fedoraproject.org//packages/libmediainfo/22.12/1.el7/x86_64/libmediainfo-22.12-1.el7.x86_64.rpm
wget https://kojipkgs.fedoraproject.org//packages/mediainfo/22.12/3.el7/x86_64/mediainfo-22.12-3.el7.x86_64.rpm
rpm -i libmediainfo-22.12-1.el7.src.rpm mediainfo-22.12-3.el7.src.rpm 
systemctl start sonarr

I’ve blacklisted these packages in my yum.conf until a fix is found.

Cheers.

UbiquitousPhoton · April 18, 2023, 10:44am

Ah, that’s actually really good news - I tried to downgrade my libmediainfo last night but discovered that OpenSuse Tumbleweed doesn’t keep old packages for … reasons, and thus could not.

That was the smoking gun I was looking for however, so will move this to a bug report on github, as I think we will get next to no attention here. I will post the link when created, any backup / extra data would be extremely useful

UbiquitousPhoton · April 18, 2023, 11:37am

github.com/Sonarr/Sonarr

Sonarr segfaults / coredumps on getting media info with libmediainfo v23.03

opened 11:37AM - 18 Apr 23 UTC

UbiquitousPhoton

needs-triage

### Is there an existing issue for this? - [X] I have searched the existing ope…n and closed issues ### Current Behavior Sonarr core dumps on trying to get media info with libmediainfo0 v23.03 (released 2023-03-29 : https://github.com/MediaArea/MediaInfo/releases/tag/v23.03) This will either happen during initial scan (should any information be missing about current files) or during import of a new release. Once it has happened, unless the library is removed, it will then happen 100% on boot of Sonarr from that point on. This is not, unfortunately an unavoidable bug on those systems with upgraded libmediainfo. ### Expected Behavior Sonarr should not segfault on calling libmediainfo v23.03 (behaviour should be the same as with v22.12) ### Steps To Reproduce See above. Cause Sonarr to try and get media info for a file - the easiest way to do this is to download a new release of something, and Sonarr will segfault and coredump. ### Environment ```markdown - OS: OpenSuse Tumbleweed - Sonarr: 3.0.9.1549-4.7 (also reproduced with 3.0.10 on Fedora) - Docker Install: n/a - Using Reverse Proxy: Nginx (but N/A, not browser issue) - Browser: N/A (browser does not need to be attached to cause crash) ``` ### What branch are you running? Main ### Trace Logs? Trace log shows no issues, it will generally just stop dead, after something along the lines of the following: ``` 2023-04-14 02:26:20.3|Debug|ImportDecisionMaker|Analyzing 1/1 files. 2023-04-14 02:26:20.3|Debug|Parser|Parsing string 'Station.19.S06E14.720p.HDTV.x264-SYNCOPY' 2023-04-14 02:26:20.3|Trace|Parser|^(?<title>.+?)(?:(?:[-_\W](?<![()\[!]))+S?(?<season>(?<!\d+)(?:\d{1,2})(?!\d+))(?:[ex]|\W[ex]){1,2}(?<episode>\d{2,3}(?!\d+))(?:(?:\-|[ex]|\W[ex]|_){1,2}(?<episode>\d{2,3}(?!\d+)))*)\W?(?!\\) 2023-04-14 02:26:20.3|Debug|Parser|Episode Parsed. Station 19 - S06E14 2023-04-14 02:26:20.3|Debug|Parser|Language parsed: English 2023-04-14 02:26:20.3|Debug|QualityParser|Trying to parse quality for Station.19.S06E14.720p.HDTV.x264-SYNCOPY 2023-04-14 02:26:20.3|Debug|Parser|Quality parsed: HDTV-720p v1 2023-04-14 02:26:20.3|Debug|Parser|Release Group parsed: SYNCOPY 2023-04-14 02:26:20.3|Debug|VideoFileInfoReader|Getting media info from /home/(removed)/.sabnzbd/downloads/complete/Station.19.S06E14.720p.HDTV.x264-SYNCOPY/b8ef54b3cda8455bbb65814bb94a2e13.mkv ``` I can provide further trace logs on request, but there are no errors whatsoever reported there prior to crash. ### Anything else? Pulling the stack trace from the journal gives always the same trace: ``` Native Crash Reporting ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ================================================================= Native stacktrace: ================================================================= 0x55e480b77cd0 - /usr/bin/mono : 0x55e480b78079 - /usr/bin/mono : 0x55e480b26e71 - /usr/bin/mono : 0x55e480b7189d - /usr/bin/mono : 0x7ff21af68476 - /lib64/libmediainfo.so.0 : ================================================================= at <unknown> <0xffffffff> at NzbDrone.Core.MediaFiles.MediaInfo.MediaInfo:MediaInfo_Open_Buffer_Continue <0x000b8> at NzbDrone.Core.MediaFiles.MediaInfo.MediaInfo:Open <0x000ff> at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader:GetMediaInfo <0x00293> at NzbDrone.Core.MediaFiles.MediaInfo.VideoFileInfoReader:GetRunTime <0x0004f> at NzbDrone.Core.MediaFiles.EpisodeImport.DetectSample:IsSample <0x0016d> at <>c__DisplayClass14_0:<GetNonSampleVideoFileCount>b__0 <0x00050> at System.Linq.Enumerable:Count <0x000c8> at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetNonSampleVideoFileCount <0x001af> at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetImportDecisions <0x001c3> at NzbDrone.Core.MediaFiles.EpisodeImport.ImportDecisionMaker:GetImportDecisions <0x0005f> at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService:ProcessFolder <0x0044c> at NzbDrone.Core.MediaFiles.DownloadedEpisodesImportService:ProcessPath <0x000ef> at NzbDrone.Core.Download.CompletedDownloadService:Import <0x0010e> at NzbDrone.Core.Download.DownloadProcessingService:Execute <0x002b0> at NzbDrone.Core.Messaging.Commands.CommandExecutor:ExecuteCommand <0x00210> at System.Object:CallSite.Target <0x00122> at System.Dynamic.UpdateDelegates:UpdateAndExecuteVoid3 <0x001bc> at System.Object:CallSite.Target <0x00191> at NzbDrone.Core.Messaging.Commands.CommandExecutor:ExecuteCommands <0x0032f> at System.Threading.ThreadHelper:ThreadStart_Context <0x000aa> at System.Threading.ExecutionContext:RunInternal <0x00191> at System.Threading.ExecutionContext:Run <0x00042> at System.Threading.ExecutionContext:Run <0x00063> at System.Threading.ThreadHelper:ThreadStart <0x00042> at System.Object:runtime_invoke_void__this__ <0x00091> ``` It is definitely the libmediainfo thread that is the one crashing. I installed lldb in order to give full native traces, but this gave no further help as to the site of the crash. I would strongly suspect that the reason is that libmediainfo 23.3 is not API/ABI compatible with the version you built the releases against.

UbiquitousPhoton · April 18, 2023, 12:46pm

I managed to source old rpms from https://ftp.lysator.liu.se/pub/opensuse/history/20230328/tumbleweed/repo/oss/x86_64/ and can confirm that downgrading mediainfo and libmediainfo fixes the crashes. I won’t attach the rpms here, but I have them stashed locally, if anyone needs, and they have gone from the above. Hopefully a fix will be relatively quickly incoming.

UbiquitousPhoton · April 18, 2023, 3:01pm

Hm. So, as per the bug tracker above, its a known problem with a bad release of mediainfo, which will crash on all mkvs (mediainfo and libmediainfo throwing segmentation fault on files · Issue #707 · MediaArea/MediaInfo · GitHub). They have a patched development release version available, but not a full release yet, unsure as to when this will happen.

bortius · April 18, 2023, 3:45pm

Same here.

# ls -lh /usr/lib64/libmediainfo.so.0*
lrwxrwxrwx. 1 root root   24 Mar 31 19:00 /usr/lib64/libmediainfo.so.0 -> libmediainfo.so.0.2303.0
-rwxr-xr-x. 1 root root 8.1M Mar 31 19:00 /usr/lib64/libmediainfo.so.0.2303.0

edit: sorry, this was posted very late because I’m a noob.
I had the same issue. Reverting mediainfo and libmediainfo to <23.x let Sonarr v3 run again on my Fedora 38 build.
An alternative to the procedure above is to use dnf versionlock on the packages.
Other versions for Redhat-based RPMs: libmediainfo mediainfo

bortius · April 19, 2023, 8:34pm

Someone said so on github but I’ll post it here because I confirmed it: Sonarr v4 beta isn’t affected. I was able to remove mediainfo and libmediainfo after upgrading. caveat emptor

mobius · April 27, 2023, 12:50pm

I encountered this, and “fixed” it by upgrading to v4.
V4 uses ffprobe (part of ffmpeg tools) bundled with the release package.

W/r/t removing libmediainfo.so, other things may depend on the library and will also break.
Downgrading is a far better course of action.

system · June 26, 2023, 12:50pm

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.