libnfs crashes XBMC resuming - segfault rpc_allocate_pdu #28
Comments
|
Can you build with debugging so you get the arguments to rpc_allocate_pdu () You can try adding printouts to These should where only places where rpc is malloced and freed so if rpc Can you also try running under valgrind ? If it is accessing freed memory Do you by any chance compile libnfs with --enable-tirpc ? On Fri, Nov 16, 2012 at 12:32 AM, Cyberwizzard notifications@github.comwrote:
|
|
I added print statements to the function and simply dumped values to the console; so I did not use gdb to step through the program. I will add some logging to init and destroy context to see if the clear the memory of 'rpc'. |
|
I numbered the calls to quickly see what was printed where and finally only left the print statements that showed the addresses from the rpc pointer. Interestingly, you can see in the end that it suddenly uses a different pointer from the one that was in use before. snip What can I do next? Would building it with debug support help? |
|
Hmmmm. 1.1: rpc_allocate_pdu rpc @ 0x50eeb30 This context where it crashes, was that context ever created ? Try to build XBMC with debugging so it is easier for you to look at the And when it crashes, look in the stack backtrace to try to see where XBMC If this pointer 0x50eeb30 was never created through a call to But first, try to find out where XBMC got that pointer from. On Sun, Nov 18, 2012 at 10:35 AM, Cyberwizzard notifications@github.comwrote:
|
|
I built XBMC and libnfs with -O0 and -g - I got a log at http://xbmclogs.com/show.php?id=15024 showing the crash. The problem is that according to Memphiz from XBMC they keep one context per file and as such never touch the rpc directly. I tried adding debug statements to the libnfs wrapper to see if it discards the nfs_context prematurely. But so far, it seems to behave as it should... I saw the xdr commits in master, is that something I could try? As in: do I need to do something to use the new xdr routines except for 'git pull && git update && make clean all' ? |
|
You could try the xdr commit. The change is for an issue where the 64 bit accessor on 64 bit platforms It could have an impact. Try latest git and see if it helps. On Mon, Nov 19, 2012 at 12:18 PM, Cyberwizzard notifications@github.comwrote:
|
|
Since I am not using tirpc (as far as I know) - it did not seem to make a difference. But the debug build of both libnfs and xbmc (with loads of debug output) did help me figure out the problem: xbmc had a bug where it considered an active context to be expired and destroyed the context. The consecutive call to nfs_read would then provide this invalid context resulting in the crash; this was an issue with xbmc. Thank you for helping! |
|
Good stuff! I need to do a new release soon to handle the XDR 64 bit issue anyway. I am thinking about adding a Unfortunately, it the rpc_context is garbage, then I cant set the rpc_error If I add this tracking/check to libnfs over the next few days, would you be regards On Tue, Nov 20, 2012 at 12:45 PM, Cyberwizzard notifications@github.comwrote:
|
|
Sure, I have the test builds still on my system so testing the asserts should be no problem. |
|
Thanks. I have pushed a change that adds a new rpc->magic field. Please test that this assert triggers so we know that this kind of defects regards On Wed, Nov 21, 2012 at 9:56 AM, Cyberwizzard notifications@github.comwrote:
|
|
The skin in XBMC causing the issue was updated and I could not get it to crash like it used to because of this. I did alter XBMC to explicitly destroy a context just before it was used, which of course crashed the program. Using gdb on XBMC yielded the following: |
|
Good stuff. Ok so at least we can trap this kind of issue easier. Thanks for testing. regards On Thu, Nov 22, 2012 at 2:09 PM, Cyberwizzard notifications@github.comwrote:
|
The problem: I am running the XBMC nightly builds and often when I pause and then resume playback, XBMC crashes. With help from one of the XBMC devs I narrowed the problem down to a crash within libnfs, see also: http://trac.xbmc.org/ticket/13505
I started with libnfs 1.2.x from Ubuntu 11.10 (I think), upgraded to 1.3.0 from the nightly XBMC PPA and now pulled the master from here.
I have experienced this issue for a while now and it seems to get worse. My guess is that I keep running into a race condition.
Relevant parts of the backtrace as posted at http://xbmclogs.com/show.php?id=14577 :
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff8d1f44700 (LWP 30968)]
0x00007ff8c931064e in rpc_allocate_pdu () from /usr/lib/x86_64-linux-gnu/libnfs.so.1
(gdb) thread apply all bt
snip
Thread 7 (Thread 0x7ff8d1f44700 (LWP 30968)):
#0 0x00007ff8c931064e in rpc_allocate_pdu () from /usr/lib/x86_64-linux-gnu/libnfs.so.1
#1 0x00007ff8c9317936 in rpc_nfs_read_async () from /usr/lib/x86_64-linux-gnu/libnfs.so.1
---Type to continue, or q to quit---
#2 0x00007ff8c93069b3 in nfs_pread_async () from /usr/lib/x86_64-linux-gnu/libnfs.so.1
#3 0x00007ff8c930e58d in nfs_pread () from /usr/lib/x86_64-linux-gnu/libnfs.so.1
#4 0x00007ff8c930e60a in nfs_read () from /usr/lib/x86_64-linux-gnu/libnfs.so.1
#5 0x0000000000c945b6 in XFILE::CNFSFile::Read(void*, long) ()
#6 0x0000000000bda796 in XFILE::CFile::Read(void*, long) ()
#7 0x0000000000a276d8 in CDVDInputStreamFile::Read(unsigned char*, int) ()
snip
I compiled libnfs from source and tried debugging the issue myself. I tried multiple things, checked all pointers in 'rpc_allocate_pdu' for sane values and concluded that the mallocs are checked properly and the memset was not causing the crash either. I then spotted that at the locations where it crashes, values from the 'rpc' struct pointer are read.
Perhaps the rpc struct is freed somewhere while 'rpc_allocate_pdu' is using it or something similar?
The text was updated successfully, but these errors were encountered: