Segfault in Helix Master when accessing IFO over NFS #3692
Comments
|
@Karlson2k apologies for pinging you here, but this could be related to the vfs changes, and you are the one who knows that code best. any clue ? |
|
I believe both libc and the optimised libarmmem versions of memcpy use assembly code without cfa directives which means crashes in memcpy never produce a valid backtrace from memcpy. Ben did add these a while ago (bavison/arm-mem@2e6f275) so it might be worth updating to latest version of libarmmem which I think will fix this specific backtrace. |
|
I'm testing later builds, after #1027, and it seems the NFS crash problem went away starting with build #1112 which included xbmc/xbmc#5700 and xbmc/xbmc#5707, amongst other changes. At some point the problem seems to have returned, and I'm now working through the builds after #1112 in an effort to identify which build reintroduced the problem. |
|
#1126 is the build where the problem reappears. This includes various SMB related fixes. Now in the process of reverting these commits and testing. |
|
I think we've reached a conclusion. The problem starts with build #1126, specifically due to the inclusion of xbmc/xbmc#5819. With xbmc/xbmc#5819 reverted from master there is no problem with either NFS or SMB playback. With it, NFS crashes kodi.bin. Adding xbmc/xbmc#5694 on top of master (ie. without reverting xbmc/xbmc#5819) does not help - kodi.bin still crashes when testing NFS (SMB is OK). Will now build with the updated arm-mem to see if its possible to obtain a better backtrace. |
|
Backtrace of master including xbmc/xbmc#5819, with updated arm-mem: |
|
This small patch should fix crashes, but it will not fix real bug: diff --git a/xbmc/filesystem/File.cpp b/xbmc/filesystem/File.cpp
index c25667d..e0a612a 100644
--- a/xbmc/filesystem/File.cpp
+++ b/xbmc/filesystem/File.cpp
@@ -298,7 +298,7 @@ bool CFile::Open(const CURL& file, const unsigned int flags)
return false;
}
- if (m_pFile->GetChunkSize() && !(m_flags & READ_CHUNKED))
+ if (m_pFile->GetChunkSize() > 1 && !(m_flags & READ_CHUNKED))
{
m_pBuffer = new CFileStreamBuffer(0);
m_pBuffer->Attach(m_pFile); |
@Karlson2k - I've given the patch a quick test (I mean, real quick - videos either played or the app crashed) and it does indeed stop the crashing, while also allowing playback over both NFS and SMB. Many thanks. |
|
@Karlson2k please take care that we get a valid "workaround" into helix, so that the next RC does not have that issue. Thanks much in advance. |
|
@Karlson2k - will you be pushing this patch to Helix/master etc.? |
|
Still curious what happens with a chunkSize of 1 though, which code path is taken then? |
|
@fritsch @MilhouseVH Already: xbmc/xbmc#5947 :) |
|
this should now be fixed upstream. thanks to everyone involved. |
TrevorH reported this issue on #irc last night, while using a 32-bit x86 OpenELEC build (Atom d510).
I've been able to reproduce on a R-Pi with test build #1213.
This appears to be OpenELEC specific. @stefansaraev (seo) also took part in the conversation.
To reproduce
Test setup
With current master, I added a folder imaginatively called "Test".
In sources.xml, it's added as an extra path on an existing source:
The contents of the Test folder is as follows (I had intended for the VIDEO_TS and AUDIO_TS folders to be in a folder called "Hitchikers Guide - Extra" as this is what the DVD is, however I messed up my cp command while creating the Test folder which may have helped, who knows):
And this is the contents of the VIDEO_TS folder (AUDIO_TS is empty):
After the video scanner (Universal Movie Scanner) had finished scanning it added the following new movie:
Any attempt to play this movie via the library and using a recent master build results in a seg fault.
Tail end of kodi.log:
Running kodi.bin in gdb produces a fairly useless backtrace[1]:
I also added the same Test folder using SMB, with the following movie added to the Library:
In build #1213, this SMB version of the movie plays without a problem from the Library while the NFS version does not.
Bisecting builds allowed me to narrow it down to build #1027 from the evening of 27 Oct:
26 Oct #1026: SMB crashes, NFS works
27 Oct #1027: SMB works, NFS crashes
The release notes for build #1027 are here.
My October test builds are using libnfs 1.9.5 while my latest #1213 test build is using libnfs 1.9.6, so it doesn't seem to be a libnfs issue, at least not one that is already fixed upstream.
The only relevant change in build #1027 is the revert of xbmc/xbmc#5534 in order to avoid an SMB problem introduced by the final commit, xbmc/xbmc@e502b09. The revert does indeed resolve the SMB issue, but then appears to break NFS.
Subsequent pull requests (one or more of: xbmc/xbmc#5660, xbmc/xbmc#5694, xbmc/xbmc#5700, xbmc/xbmc#5740, possibly others) then addressed the SMB-related problem in xbmc/xbmc#5534 meaning the revert could be dropped, but as a result we now seem to be left with this persistent NFS issue.
The strange thing - and why I'm reporting this issue here and not on Kodi github - is that a current Kodi master build (xbmc/xbmc@238c5ef) on Ubuntu 14.10/x64 (using the same shared MySQL Library and sources.xml as the Raspberry Pi) does not crash with either NFS or SMB and plays the IFO correctly, over both NFS and SMB, so this currently appears to be OpenELEC specific.
Ubuntu kodi.log showing playback over NFS, then SMB, is here.
Based on comparison of the Ubuntu log (where NFS works) and the R-Pi log (where NFS segfaults), the point of failure appears to be libdvdnav related, as the following entry doesn't make it into the R-Pi log:
It's entirely possible that xbmc/xbmc#5534 is a red herring and the NFS problem could have been fixed after 27 Oct by one of the other related pull requests, then broken again by an unrelated (and as yet unidentified) commit, however given the history of the SMB/Posix fixes it's the most likely cause.
I'm happy to test patches etc. if anyone has any ideas or is able to debug further.
Building with debug is an option:
The second solution (
export ...) would IMHO be best but unfortunately it doesn't seem to actually work - ideas weclome!Although building kodi with the first solution doesn't yield a better traceback than kodi built with DEBUG=no, despite kodi.bin increasing from:
to:
so it obviously had an effect on the build, but not in terms of any resulting backtrace.
The text was updated successfully, but these errors were encountered: