#15946 closed Bugs (Fixed)

kodi 15b1 sometimes hang when pressing stop.

Reported by: marantz Owned by: WiSo
Priority: 4 - Normal
Component: Windows (Win32) Distribution / Installer Version: 15.0 "Isengard" Beta2
Severity: Normal Keywords:
Cc: arnova, FernetMenta, fritsch Blocked By:
Blocking: Platform: All

Description

Attachments (2)

Change History (36)

comment:1 Changed at 2015-04-28T18:44:07+01:00 by marantz

this has happend for me quite a few times now, I think it happens when buffer is 0, for some reason kodi doesnt want to download anything sometimes, and while cache is on 0 I cant stop or exit kodi.

comment:2 Changed at 2015-04-29T08:15:39+01:00 by marantz

this is not an installer issue, made a mistake there.

comment:3 Changed at 2015-05-01T20:11:48+01:00 by Martijn

  • Cc arnova FernetMenta fritsch added

maybe something in caching code changes?

comment:4 Changed at 2015-05-03T14:37:14+01:00 by arnova

I can't reproduce this, however I'm seeing weird stuff in the log for our simple-cache. @marantz: Why did you disable memory caching and resorted to disk caching (cache=0) ?

comment:5 Changed at 2015-05-03T15:08:08+01:00 by marantz

becouse I play over internet and prefer to buffer as much as possible. I use ssd to cache and I havent had any issues with that in the past.

comment:6 Changed at 2015-05-03T15:18:25+01:00 by arnova

Did you also have this problem with 14.2 then?

comment:7 Changed at 2015-05-03T15:19:19+01:00 by marantz

nope, never.

comment:8 Changed at 2015-05-03T15:21:50+01:00 by arnova

Did you try reproducing this with memory caching as well? And does the screen just turn black or does the last video frame stay on screen?

comment:9 Changed at 2015-05-03T15:23:21+01:00 by marantz

ill try with memoery cache, the screen first become VERY slow and unresponsive and when actually pressing stop to get out of there it just stalls, no black screen etc.

comment:10 Changed at 2015-05-03T15:55:43+01:00 by marantz

cant reproduce this with webdav which I recently went back to.. give me some time to check with https again

comment:11 Changed at 2015-05-23T16:21:59+01:00 by Paxxi

As far as I've been able to find out it's actually two bugs behaving in the same way, one when just caching and one when seeking.

It can be fairly reproducable using youtube addon. Open a video and stop it after a second or two when you know it will be reading data into the cache. Alternatively start a video and jump forward a small step and then stop the video.

It's a bit hit or miss but I can usually hit it 3/5 tries.

comment:12 Changed at 2015-05-24T09:14:39+01:00 by arnova

I just had a look at this. The problem is: I still can't reproduce it on Linux here, so it seems a Windows-only problem which I can't debug. I'm wondering why it's behaving this way on Windows only.

Last edited at 2015-05-24T09:16:38+01:00 by arnova (previous) (diff)

comment:13 Changed at 2015-05-24T11:38:54+01:00 by Paxxi

arnova at least curl differs a bit internally so there might be something going on there, I'll get you some call stacks and can certainly spin up a vm for you if it would help

comment:14 Changed at 2015-05-25T09:23:07+01:00 by arnova

Paxxi, when you reproduced this you also used our alternative ondisk-cache (cachemembufsize=0) ?

comment:15 Changed at 2015-05-25T10:53:26+01:00 by Martijn

  • Version changed from 15.0 "Isengard" Alpha1 to 15.0 "Isengard" Beta2

comment:16 Changed at 2015-05-25T19:36:12+01:00 by Paxxi

testing was done with default value so 20mb. I tried changing readfactor to 1 and issue remained. Will try with cachemembufsize=0 tomorrow and see if it makes a difference.

comment:17 Changed at 2015-05-25T20:04:04+01:00 by arnova

Ok, just wanted to make sure the cache-type doesn't matter, since the initial report suggested it was a disk-cache only issue.

comment:18 Changed at 2015-05-25T20:23:38+01:00 by arnova

What I don't get is why it doesn't timeout internally in Curl. A full callstack could help a lot here.

comment:20 Changed at 2015-05-26T20:56:48+01:00 by arnova

Weird, I see no reason why the Curl thread is hanging. It seems to be running and not blocking anywhere. Could you please give detailed instructions on how you exactly make it lockup? Perhaps even with a clean install (and no advancedsettings.xml) ?

Changed at 2015-05-27T09:25:54+01:00 by arnova

Changed at 2015-05-27T09:26:12+01:00 by arnova

comment:21 Changed at 2015-05-27T09:27:08+01:00 by arnova

Since it seems a Windows-only problem, I may have found something. I've attached a patch and a hacked version of curlfile.cpp (/xbmc/filesystem/), which ever you prefer. Note that I've not (compiled) tested it.

@Paxxi: Can you give it a try and see how it goes?

Last edited at 2015-05-27T10:08:00+01:00 by arnova (previous) (diff)

comment:22 Changed at 2015-05-27T18:56:04+01:00 by Paxxi

  • Milestone Future / Pending deleted
  • Version changed from 15.0 "Isengard" Beta2 to 13.2 "Gotham" Alpha1

The curl thread doesn't block as such on a conditionvariable or anything but it just keeps reading which keeps the mainthread and dvdplayer thread blocked.

So what I did is. built a fresh debug build from todays git, deleted %appdata%\kodi (.kodi) folder and started with a completely clean userdata. This is first try, when the video stops it's me pressing X to stop the video https://www.youtube.com/watch?v=VHePg6BVjsM

This is a second try with your patch https://www.youtube.com/watch?v=ouQ3J7JscBc

You'll notice the callstacks are the same and CurlFile is always writing data into the buffer when I break into the debugger.

I tried to show some of the relevant state but video isn't the best way for it.

comment:23 Changed at 2015-05-28T08:48:44+01:00 by arnova

  • Milestone set to Future / Pending

Are you able to figure out when this issue was introduced? It's a regression, right? Can you also post a debug log with curl component logging enabled?

So it keeps looping in CurlFile::FillBuffer(), it's not hanging in multiperform correct? Are you able to singlestep through FillBuffer to figure out why it's not exiting this function? It should either timeout or fill the buffer till it's full. I assume somehow Curl is not flagging an error condition on line 1479. And I'm interested in what happens at line 1577, where the result is evaluated. Can you figure this out?

Last edited at 2015-05-28T08:51:13+01:00 by arnova (previous) (diff)

comment:24 Changed at 2015-05-28T09:45:43+01:00 by arnova

  • Milestone changed from Future / Pending to 15.0 "I*****"
  • Version changed from 13.2 "Gotham" Alpha1 to 15.0 "Isengard" Beta2

comment:25 Changed at 2015-05-28T12:44:52+01:00 by arnova

@Paxxi, you forced me into booting into Windows here and installing VC2013 ;-) I think the problem is in libcurl itself. It seems to hang in multiperform. Did you notice the debug output spew while it hangs send from libcurl?

Using an old libcurl dll seems to get rid of the issue. I therefor think it got introduced with https://github.com/xbmc/xbmc/commit/449a0bbd58b522fb5ecb58461fab012136623e67 . Could you try upgrading to the latest libcurl 7.42.1 and else revert to the old one as well and see whether this fixes the issue? This also explains why it seems like a Windows-only issue.

Last edited at 2015-05-28T12:45:13+01:00 by arnova (previous) (diff)

comment:26 Changed at 2015-05-28T14:20:21+01:00 by Paxxi

Nice finding. I haven't looked at the log output actually. Will try and upgrade/downgrade curl, got some extra stuff at work so it's possible that I won't get to it until the weekend.

comment:27 Changed at 2015-05-28T14:26:56+01:00 by arnova

I also seems that as soon as I disable component logging for curl, the problem is also gone. Can you confirm this?

comment:28 Changed at 2015-05-28T19:54:02+01:00 by Paxxi

In my testing component logging was off for curl. I uncommented the logging in curlfile::writecallback and overflowbuffer was just growing and growing, was up to 62mb at one try.

It never returns from multi_perform in any of my testing. Will report back with curl upgrade/downgrade when ive had the chance

comment:29 Changed at 2015-05-29T21:35:51+01:00 by Martijn

  • Milestone changed from 15.0 "I*****" to 15.0 "Isengard"

comment:30 Changed at 2015-05-31T11:17:27+01:00 by Paxxi

@arnova I've spent the weekend with this and it seems it's a curl bug. Upgrading to 7.42.1 made no difference. However rebuilding curl with openssl instead of schannel makes it behave as on other platforms. The issue seems to be in curls implementation of schannel.

Will try and report the issue there, to not hold up our release I'm thinking we should update curl on win32 with an openssl build.

comment:31 Changed at 2015-06-01T06:19:18+01:00 by arnova

@paxxi: I seemed to have missed your last comment. But apparently our conclusion is the same. Reverting to Curl + OpenSSL seems the most logical way, especially since we know it works so a much lower risk of regressions before release.

comment:32 Changed at 2015-06-02T06:51:50+01:00 by Paxxi

@marantz can you test the build linked here https://github.com/xbmc/xbmc/pull/7167 ? You can reply here or in that thread, whichever you prefer

comment:33 Changed at 2015-06-02T12:31:31+01:00 by marantz

seems to work fine! thanks guys!

comment:34 Changed at 2015-06-03T06:30:09+01:00 by Paxxi

  • Resolution set to Fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.