After the latest update, Sonarr crashes continuously.
EPIC FAIL: Object reference not set to an instance of an object: Object reference not set to an instance of an object
Exception
System.NullReferenceException: Object reference not set to an instance of an object
at System.Threading.EventWaitHandle.Reset () [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.Threading.EventWaitHandle:Reset ()
at System.Threading.Timer+Scheduler.SchedulerThread () [0x00000] in :0
at System.Threading.Thread.StartInternal () [0x00000] in :0
I’m not exactly sure which part of the log file you need, so I copied the part from when it crashed last. It appears that maybe it doesn’t know how to handle the show “Horizon”:
15-3-30 08:08:23.5|Info|RefreshSeriesService|Updating Info for Horizon
15-3-30 08:08:24.4|Info|RefreshEpisodeService|Starting episode info refresh for: [74379][Horizon]
15-3-30 08:08:24.9|Info|RefreshEpisodeService|Finished episode refresh for series: [74379][Horizon].
15-3-30 08:08:25.7|Fatal|GlobalExceptionHandlers|EPIC FAIL: Object reference not set to an instance of an object
System.NullReferenceException: Object reference not set to an instance of an object
at System.Threading.EventWaitHandle.Reset () [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.Threading.EventWaitHandle:Reset ()
at System.Threading.Timer+Scheduler.SchedulerThread () [0x00000] in :0
at System.Threading.Thread.StartInternal () [0x00000] in :0
15-3-30 16:04:41.0|Warn|DownloadedEpisodesImportService|Non-sample file detected: [/media/video/!sort/The.Soup.2015.03.27.720p.HDTV.x264-W4F/the.soup.2015.03.27.720p.hdtv.x264-w4f-sample.mkv]
15-3-30 16:05:41.3|Info|RssSyncService|Starting RSS Sync
15-3-30 16:05:44.8|Info|DownloadDecisionMaker|Processing 372 reports
15-3-30 16:05:45.0|Fatal|GlobalExceptionHandlers|EPIC FAIL: Object reference not set to an instance of an object
System.NullReferenceException: Object reference not set to an instance of an object
at System.Threading.Timer+Scheduler.SchedulerThread () [0x00000] in :0
at System.Threading.Thread.StartInternal () [0x00000] in :0
It’s very unlikely the issue is related to one particular show. The exception comes from mono itself.
Could you run mono with the --debug option? just add the option to the autorun mechanism (systemd, upstart, etc).
That will avoid some of the usual optimizations and add a bit more to the stacktrace.
I doubt clearing the db helps, but normally it’s stored in ~/.config/NzbDrone
If you delete it, keep a backup.
@Taloth, I wasn’t sure how to add the debug option to the systemd, upstart, etc., so I just updated mono to 3.12.1 and mediainfo to 0.7.72 as described by @macros. At least I thought I had updated mediainfo to the latest version, but I kept getting crashes. Once I double-checked, I was still at a lower version so I just updated (for real this time) and confirmed I’m at 0.7.72. I’ll keep an eye on it and report back. Mediainfo may be your culprit?
Okay. Meanwhile I have to warn you, this is not going to be something easily fixed. (or it is easily fixed once we find out what the heck is going wrong in mono )
I’m also not able to do this alone so I’ll drag @markus101 in here as well.
I’ve been seeing the same error since moving back to Ubuntu Server 14.04 LTS from 14.10 a few weekends ago.
I found this thread yesterday and have upgraded mono and mediainfo to the latest from their PPAs instead of the ubuntu PPAs and since haven’t seen this error since. I previously couldn’t keep sonarr running for more than 15 min.
Previous (failing) Mono version:
mono --version
Mono JIT compiler version 3.10.0 (tarball Wed Nov 5 12:50:04 UTC 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen
Still haven’t seen this particular crash since updating mono and MediaInfo.
I was still seeing crashes, but I think I tied that to some issue with using SSL to connect to my deluge server. Since reverting the webui for deluge to non-SSL it’s been rock solid.
Still not able to complete an “update library” scan or rss scan. But I was kind of starting to wonder if it was some back end service we where using that might be dishing out bad data. Was thinking that Sonarr might be popular enough that its services might be getting hacked or datacenter attack. Guess github had a bought of it over the last week.
Its been hit and miss but still running enough to grab what I need.
No it’s not a hack, those wouldn’t cause SIGSEGVs
We’re working with some users to identify what combination of mono and native libraries cause this. But it’s a tedious process since it’s something internal in mono or native dependencies, very hard to debug.
Keep the reports coming.