Bug 5001

Summary: Bug in package kodi-18.0-0.12.b4.fc29.x86_64 causes kodi to crash when accessing SMB shares
Product: Fedora Reporter: Mike Goodwin <mike>
Component: kodiAssignee: Michael Cronenworth <mike>
Status: RESOLVED FIXED    
Severity: enhancement CC: alexl, ktdreyer, leigh123linux, m.mcnutt, maci, roignac
Priority: P1    
Version: f30   
Hardware: x86_64   
OS: GNU/Linux   
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1645576
namespace:
Attachments: GDB Backtrace while running kodi 18 on Fedora 28

Description Mike Goodwin 2018-08-26 05:48:40 CEST
Created attachment 1958 [details]
GDB Backtrace while running kodi 18 on Fedora 28

Description: 

Kodi immediately crashes if any attempt is made to use SMB.

Filing this in case it becomes a future bug and can be renamed, since I put a few hours into figuring out what's going on here.

Since VAAPI is broken for Haswell in 17.6-9 (bug #5000), (and you had mentioned 18.0 being the solution) I took it upon myself to grab the latest SRPM from: http://koji.rpmfusion.org/koji/packageinfo?packageID=103

which is currently kodi-18.0-0.4.a2.fc29: http://koji.rpmfusion.org/koji/buildinfo?buildID=8447

And I ran the following mock command to build:

mock ~/kodi-18.0-0.4.a2.fc28.src.rpm -r fedora-28-x86_64-rpmfusion_nonfree

And then installed it locally onto the system.

----

I use all SMB shares from a CentOS 7.5 server to share all media to Kodi clients on my network. Kodi crashes immediately after starting the GUI while it tries to resolve SMB paths.

I noticed when I moved (or removed) advancedsettings.xml (for the MySQL information - this is needed because if kodi can read the database, then it knows the paths to look for regardless of sources.xml) AND sources.xml, it would not crash upon startup. Of course a new profile works, but the reverse is also true, i.e. Copying advancedsettings.xml and sources.xml causes Kodi to crash - so I am certain it's buggy behavior


Included is the stacktrace from

`gdb /usr/lib64/kodi/kodi-xll | tee log` then waiting for the crash and typing `thread apply all bt`


----

Although I could not find the old bug, I recall that a similar SMB problem would crash kodi in the same visual way and it turned out to be something fedora specific iirc, if that jogs anyone's memory.
Comment 1 leigh scott 2018-08-26 11:29:10 CEST
You backtrace has missing debug symbols, looking at the incomplete backtrace I would assign blame to mesa intel driver


Thread 1 (Thread 0x7ffff7f4fc80 (LWP 7382)):
#0  0x00007fffec521659 in poll () from /lib64/libc.so.6
#1  0x00007fffea81404f in poll (__timeout=-1, __nfds=1, __fds=0x7fffffffcdf8) at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait () at xcb_conn.c:479
#3  0x00007fffea815da2 in xcb_wait_for_special_event (c=0x5555573cb460, se=0x555557590f70) at xcb_in.c:795
#4  0x00007fffd146fc1b in dri3_wait_for_event_locked () from /lib64/libEGL_mesa.so.0
#5  0x00007fffd146fd70 in dri3_find_back () from /lib64/libEGL_mesa.so.0
#6  0x00007fffd147067e in dri3_get_buffer.isra () from /lib64/libEGL_mesa.so.0
#7  0x00007fffd1471411 in loader_dri3_get_buffers () from /lib64/libEGL_mesa.so.0
#8  0x00007fffa2e78805 in intel_update_renderbuffers () from /usr/lib64/dri/i965_dri.so
#9  0x00007fffa2e78e95 in intel_prepare_render () from /usr/lib64/dri/i965_dri.so
#10 0x00007fffa2e74315 in brw_clear () from /usr/lib64/dri/i965_dri.so
#11 0x0000555555e162bb in CRenderSystemGL::ClearBuffers(unsigned int) ()
#12 0x000055555634af37 in CGUIWindowManager::RenderPass() const ()
#13 0x000055555634b198 in CGUIWindowManager::Render() ()
#14 0x0000555556550965 in CApplication::Render() ()
#15 0x0000555556604425 in CXBApplicationEx::Run(CAppParamParser const&) ()
#16 0x000055555621512f in XBMC_Run ()
#17 0x0000555555c28b1e in main ()
Comment 2 Mike Goodwin 2018-08-26 14:06:39 CEST
Isn't thread #8 the one with the issue, based on the last line of:

Using netbios name LAPTOP.
Using workgroup WORKGROUP.
Performing aggressive shutdown.
Context 0x7fff98173f10 successfully freed
smbc_stat(smb://SERVER1/movies/folder.jpg)
SMBC_server: server_n=[SERVER1] server=[SERVER1]
 -> server_n=[SERVER1] server=[SERVER1]
Opening cache file at /var/lib/samba/gencache.tdb
tdb(/var/lib/samba/gencache.tdb): tdb_open_ex: could not open file /var/lib/samba/gencache.tdb: Permission denied
gencache_init: Opening cache file /var/lib/samba/gencache.tdb read-only.
Opening cache file at /home/mgoodwin/.kodi/.smb/gencache_notrans.tdb
tdb(/home/mgoodwin/.kodi/.smb/gencache_notrans.tdb): tdb_open_ex: could not open file /home/mgoodwin/.kodi/.smb/gencache_notrans.tdb: No such file or directory
Opening /home/mgoodwin/.kodi/.smb/gencache_notrans.tdb failed: No such file or directory
sitename_fetch: No stored sitename for realm ''
internal_resolve_name: looking up SERVER1#20 (sitename (null))
Opening cache file at /var/lib/samba/gencache.tdb
tdb(/var/lib/samba/gencache.tdb): tdb_open_ex: could not open file /var/lib/samba/gencache.tdb: Permission denied
gencache_init: Opening cache file /var/lib/samba/gencache.tdb read-only.
Opening cache file at /home/mgoodwin/.kodi/.smb/gencache_notrans.tdb
tdb(/home/mgoodwin/.kodi/.smb/gencache_notrans.tdb): tdb_open_ex: could not open file /home/mgoodwin/.kodi/.smb/gencache_notrans.tdb: No such file or directory
Opening /home/mgoodwin/.kodi/.smb/gencache_notrans.tdb failed: No such file or directory
no entry for SERVER1#20 found.
name_resolve_bcast: Attempting broadcast lookup for name SERVER1<0x20>

Thread 8 "JobWorker" received signal SIGABRT, Aborted.




Which in turn looks like: 




Thread 8 (Thread 0x7fffa0770700 (LWP 7403)):
#0  0x00007fffec468feb in raise () from /lib64/libc.so.6
#1  0x00007fffec4535c1 in abort () from /lib64/libc.so.6
#2  0x00007fffde587805 in open_urandom () at ../lib/util/genrand.c:37
#3  generate_random_buffer (out=0x7fffa076cb56 "\321\321`l\023\230\377\177", len=2) at ../lib/util/genrand.c:46
#4  0x00007fffe7f1925e in generate_trn_id () at ../source3/libsmb/namequery.c:1313
#5  name_query_send (mem_ctx=<optimized out>, ev=0x7fff981611e0, name=name@entry=0x7fff98127f40 "SERVER1", name_type=name_type@entry=32, bcast=bcast@entry=true, recurse=recurse@entry=true, addr=0x7fff981b0f20) at ../source3/libsmb/namequery.c:1313
#6  0x00007fffe7f19df9 in name_queries_send (bcast=true, recurse=true, wait_msec=0, timeout_msec=1000, num_addrs=4, addrs=0x7fff981b0f20, name_type=32, name=0x7fff98127f40 "SERVER1", ev=0x7fff981611e0, mem_ctx=<optimized out>) at ../source3/libsmb/namequery.c:1704
#7  name_resolve_bcast_send (mem_ctx=mem_ctx@entry=0x7fff981482c0, ev=ev@entry=0x7fff981611e0, name=name@entry=0x7fff98127f40 "SERVER1", name_type=name_type@entry=32) at ../source3/libsmb/namequery.c:1904
#8  0x00007fffe7f1a0eb in name_resolve_bcast (name=name@entry=0x7fff98127f40 "SERVER1", name_type=name_type@entry=32, mem_ctx=0x7fff981483c0, return_iplist=return_iplist@entry=0x7fffa076d030, return_count=return_count@entry=0x7fffa076d134)
    at ../source3/libsmb/namequery.c:1962
#9  0x00007fffe7f1b527 in internal_resolve_name (name=name@entry=0x7fff98127f40 "SERVER1", name_type=name_type@entry=32, sitename=sitename@entry=0x0, return_iplist=return_iplist@entry=0x7fffa076d138, return_count=return_count@entry=0x7fffa076d134, 
    resolve_order=<optimized out>) at ../source3/libsmb/namequery.c:2776
#10 0x00007fffe7f1c483 in resolve_name_list (ctx=0x7fff98032b00, name=name@entry=0x7fff98127f40 "SERVER1", name_type=name_type@entry=32, return_ss_arr=return_ss_arr@entry=0x7fffa076d1a8, p_num_entries=p_num_entries@entry=0x7fffa076d194)
    at ../source3/libsmb/namequery.c:2949
#11 0x00007fffe8f56af3 in cli_connect_sock_send (port=<optimized out>, myname=0x7fff98128be0 "LAPTOP", pss=0x0, name_type=32, host=<optimized out>, ev=0x7fff9824e320, mem_ctx=<optimized out>) at ../source3/libsmb/cliconnect.c:2531
#12 cli_connect_nb_send (mem_ctx=mem_ctx@entry=0x7fff9824e320, ev=ev@entry=0x7fff9824e320, host=<optimized out>, host@entry=0x7fff98127f40 "SERVER1", dest_ss=dest_ss@entry=0x0, port=port@entry=0, name_type=name_type@entry=32, myname=0x7fff98128be0 "LAPTOP", 
    signing_state=-1, flags=64) at ../source3/libsmb/cliconnect.c:2655
#13 0x00007fffe8f5a458 in cli_connect_nb (host=host@entry=0x7fff98127f40 "SERVER1", dest_ss=dest_ss@entry=0x0, port=port@entry=0, name_type=name_type@entry=32, myname=0x7fff98128be0 "LAPTOP", signing_state=signing_state@entry=-1, flags=64, pcli=0x7fffa076d2b8)
    at ../source3/libsmb/cliconnect.c:2715
#14 0x00007ffff3fce842 in SMBC_server_internal (ctx=ctx@entry=0x7fff9814ae90, context=context@entry=0x7fff98127cf0, connect_if_not_found=connect_if_not_found@entry=true, server=server@entry=0x7fff98127f40 "SERVER1", port=<optimized out>, share=<optimized out>, 
    share@entry=0x7fff98174070 "movies", pp_workgroup=0x7fffa076d3e0, pp_username=0x7fffa076d3d0, pp_password=0x7fffa076d3d8, in_cache=0x7fffa076d33f) at ../source3/libsmb/libsmb_server.c:486
#15 0x00007ffff3fcf001 in SMBC_server (ctx=ctx@entry=0x7fff9814ae90, context=context@entry=0x7fff98127cf0, connect_if_not_found=connect_if_not_found@entry=true, server=0x7fff98127f40 "SERVER1", port=<optimized out>, share=0x7fff98174070 "movies", 
    pp_workgroup=0x7fffa076d3e0, pp_username=0x7fffa076d3d0, pp_password=0x7fffa076d3d8) at ../source3/libsmb/libsmb_server.c:698
#16 0x00007ffff3fcf9bd in SMBC_stat_ctx (context=0x7fff98127cf0, fname=0x7fff9820da70 "smb://SERVER1/movies/folder.jpg", st=0x7fffa076d490) at ../source3/libsmb/libsmb_stat.c:166
#17 0x0000555555e91ae6 in XFILE::CSMBFile::Exists(CURL const&) ()
#18 0x0000555556a4aa63 in XFILE::CFile::Exists(CURL const&, bool) ()
#19 0x0000555556a4aca8 in XFILE::CFile::Exists(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) ()
#20 0x00005555565ee342 in CProgramThumbLoader::GetLocalThumb[abi:cxx11](CFileItem const&) ()
#21 0x00005555565ee683 in CProgramThumbLoader::FillThumb(CFileItem&) ()
#22 0x00005555565ee114 in CProgramThumbLoader::LoadItem(CFileItem*) ()
#23 0x0000555556242011 in CDirectoryJob::DoWork() ()
#24 0x000055555613fbf1 in CJobWorker::Process() ()
#25 0x00005555561cd731 in CThread::Action() ()
#26 0x00005555561d0330 in CThread::staticThread(void*) ()
#27 0x00007ffff79b6594 in start_thread () from /lib64/libpthread.so.0
#28 0x00007fffec52c0df in clone () from /lib64/libc.so.6





Seems like SMB to me? Plus, why would the UI work fine except for when sources.xml and advancedsettings.xml have references to SMB?

---



I tried compiling with -DCMAKE_BUILD_TYPE=Debug, but for some reason it wouldn't run at all when I edited the SPEC to include that. (It built ok, just wouldn't run). I just chalked it up to being the wrong way to enable debug symbols but it was the only method I could find published that didn't involve ./configure. (which is why I didn't save the log for that but probably should have.) 

Is that the right way to do debug symbols for kodi? Is it worth repeating that and submitting that error too?
Comment 3 Michael Cronenworth 2018-08-28 18:04:56 CEST
I can reproduce the issue with 18.0 beta 1. I'd recommend trying to report this upstream. It has nothing to do with FFMPEG.

PS. 18.0 beta 1 is built for F29/F30.
Comment 4 Vadim Rutkovsky 2018-10-14 14:56:08 CEST
Just hit this on kodi-18.0-0.9.b2.fc29.x86_64 - whenever SMB share is added / enabled on startup Kodi crashes with a similar traceback.

Previous Beta 1 worked fine though
Comment 5 Matt 2018-10-31 13:18:16 CET
I am still seeing this issue with Kodi18b4 that is in the test updates right now

Curiously, I have an arch test vm which I installed Kodi prerelease from the AUR (https://aur.archlinux.org/packages/kodi-addon-pvr-hts/) and it does not suffer from this issue, so it is probably not upstreams problem
Comment 6 Matt 2018-10-31 13:19:38 CET
(In reply to Matt from comment #5)
> I am still seeing this issue with Kodi18b4 that is in the test updates right
> now
> 
> Curiously, I have an arch test vm which I installed Kodi prerelease from the
> AUR (https://aur.archlinux.org/packages/kodi-addon-pvr-hts/) and it does not
> suffer from this issue, so it is probably not upstreams problem

sorry correction on the AUR listing https://aur.archlinux.org/packages/kodi-pre-release
Comment 7 Mike Goodwin 2018-10-31 22:20:19 CET
I've updated the name of the bug because I can now no longer use Kodi on Fedora 29 as I have done the upgrade this morning. 

I can confirm that this buggy behavior is still present, now on the official version it was supposed to be on.
Comment 8 Matt 2018-11-01 12:05:56 CET
it does not appear to be related to the mock build environment either, I have built from the current git master this evening using the standard cmake instructions from the kodi git page and I get the same behaviour
Comment 9 Michael Cronenworth 2018-11-01 16:23:19 CET
We don't carry any patches for Samba or do anything special. I've opened a discussion on the Samba mailing list.

https://lists.samba.org/archive/samba/2018-November/219141.html
Comment 10 leigh scott 2018-11-01 16:58:26 CET
(In reply to Michael Cronenworth from comment #9)

Hi Michael,

On a different note, I hope you don't mind me switching kodi to ninja-build, I changed it because kodi wasn't using all cpu cores for make.
Not being optimized is a total waste of builder time, using ninja reduces build time considerably.

Regards

Leigh
Comment 11 Michael Cronenworth 2018-11-01 17:12:25 CET
(In reply to leigh scott from comment #10)

Yes, I saw the change. That's fine. I noticed the build was slower but haven't had time to investigate. Thanks.
Comment 12 Michael Cronenworth 2018-11-02 20:33:34 CET
Created a bug with Fedora's samba package. See URL line.
Comment 13 Michael Cronenworth 2018-11-03 20:13:59 CET
Fix incoming. Please test once the builds finish.

F29: http://koji.rpmfusion.org/koji/buildinfo?buildID=9363
F30: http://koji.rpmfusion.org/koji/buildinfo?buildID=9362
Comment 14 Vadim Rutkovsky 2018-11-04 10:04:35 CET
(In reply to Michael Cronenworth from comment #13)
> F29: http://koji.rpmfusion.org/koji/buildinfo?buildID=9363

This package fixed the issue here, thanks!
Comment 15 Mike Goodwin 2018-11-06 11:40:51 CET
Confirmed fixed in: kodi-18.0-0.15.b4.fc29.x86_64