[Karlson2k]

New test build with fix from cg110 soon should be available at http://mirrors.kodi.tv/test-builds/win32...ash_h0.exe (based on Helix 14.0), PDB file: http://mirrors.kodi.tv/test-builds/win32...ash_h0.pdb

Test build based on current Helix branch (14.1 Beta/RC): http://mirrors.kodi.tv/test-builds/win32...rash_h.exe, http://mirrors.kodi.tv/test-builds/win32...rash_h.pdb

[Hetfiled]

@Karlson2k

I installed last 14.1 dated 12/01 for windows and kodi hasn't crashed anymore, webserver works fine for me,
but many scripts as grab.fanat or artwork.organizer fails

do you have any idea where could be the issue?

Last couple of test builds i installed, I noticed addons weren't being granted Internet access. Maybe its still an issue?

I don't know, maybe this part of log could be helpful?

Code:

19:24:01 T:4404   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                            Error Type: <type 'exceptions.IndexError'>
                                            Error Contents: list index out of range
                                            Traceback (most recent call last):
                                              File "C:\Users\namei\AppData\Roaming\Kodi\addons\script.artworkorganizer\default.py", line 514, in <module>
                                                Main()
                                              File "C:\Users\name\AppData\Roaming\Kodi\addons\script.artworkorganizer\default.py", line 33, in __init__
                                                self._copy_artwork()
                                              File "C:\Users\name\AppData\Roaming\Kodi\addons\script.artworkorganizer\default.py", line 148, in _copy_artwork
                                                self._copy_musicvideofanart()
                                              File "C:\Users\name\AppData\Roaming\Kodi\addons\script.artworkorganizer\default.py", line 246, in _copy_musicvideofanart
                                                artist = item['artist'][0]
                                            IndexError: list index out of range
                                            -->End of Python script error report<--

thanks

[Kiggerbare]

Here is another crash using the new build, it seems to be even worse then the old one.
All i had to do was to start my computer, before i got back from making breakfast it was crashed, i didn't use yatse or anything.
This rar contains:
xbmc_stacktrace-14.0 Git_20150121-0a4a80d-20150122-084749.txt 1,23 KB
xbmc_crashlog-14.0 Git_20150121-0a4a80d-20150122-084749.dmp 274 KB
Kodi.log 343 KB
https://www.dropbox.com/s/5vqb37v4dn36lr...h.rar?dl=0

[Karlson2k]

Previous one shouldn't be any worse as it was with only one small fix.

New test build (based on Helix 14.0), fixes on other code region: http://mirrors.kodi.tv/test-builds/win32...ash_h0.exe
PDB file: http://mirrors.kodi.tv/test-builds/win32...ash_h0.pdb

[Martijn]

you know the split between 14.0 and 14.1 is quite confusing i think? Why not both base them on same 14.1 code?

@nedscott could you perhaps make a Windows specific test thread with these build where we can redirect windows users to?

[Pretoriano80]

Previous one shouldn't be any worse as it was with only one small fix.

New test build (based on Helix 14.0), fixes on other code region: http://mirrors.kodi.tv/test-builds/win32...ash_h0.exe
PDB file: http://mirrors.kodi.tv/test-builds/win32...ash_h0.pdb

I will give this test build a spin, but so far the 19/01 was the most stable build and had no crash other than the one i reported (the crash when using Yatse).

[cg110]

Further digging, the render thing might have been a red herring. The culprit might actually be this crt issue/change in vs2012:
https://connect.microsoft.com/VisualStud...plications
and:
https://connect.microsoft.com/VisualStud...ils/794122

It appears the microhttpd calls through (with multiple threads):
https://github.com/xbmc/xbmc/blob/master...er.cpp#L46

The result of setlocale(XX, NULL) should be the current locale, not NULL. I've patched the code to:
std:tring backupLocale;
if (currentLocale != NULL && (strcmp(currentLocale, "C")!=0))
{
backupLocale = currentLocale;
setlocale(LC_NUMERIC, "C");
}

Note the strcmp addition so that if the system is already in C the locale isn't changed. Testing and I've not provoked a crash when the locale isn't being fiddled all the time.

I suspect the right thread-safe fix is to set the thread (on windows) to only change the thread locale, rather than the global locale (which according to the connect bugs should be sync'd across threads), using:
https://msdn.microsoft.com/en-us/library/26c0tb7x.aspx

[Karlson2k]

cg110, thanks for nice links. This can be real root issue.

[cg110]

A little more digging, and there's a hint in the comments on one of the above connect bugs:
https://msdn.microsoft.com/en-us/library/ms235330.aspx

Note that if kodi links to threadlocale.obj then threads will default to using a per thread locale, which seems far saner than letting any old thread change locales for everyone else. However, I don't know the impact on localization/other languages of doing so.

Although I would still think that checking if the current locale is C before changing it would be more efficient, I'm just not sure it avoids the issue, as setlocale is documented as risky if any other thread is calling many of the common string functions, see:
http://en.cppreference.com/w/c/locale/setlocale

So this might need a per platform solution, rather than just a windows fix (although it appears windows is the most impacted) I suspect that a linux version would probably be using:
http://man7.org/linux/man-pages/man3/newlocale.3.html

(but then glibc looks like it checks if the requested locale is the same as the current one and do nothing)

[Karlson2k]

@Martijn, it was requested.
Someone wants just to try test build and then return to latest release.

[Martijn]

@Martijn, it was requested.
Someone wants just to try test build and then return to latest release.

I see no reason to do that. In mean time we also fixed crashing for some repo trouble and who knows what else

[nickr]

@Martijn, it was requested.
Someone wants just to try test build and then return to latest release.

I see no reason to do that. In mean time we also fixed crashing for some repo trouble and who knows what else

Is there a database update in 14.1?

[Karlson2k]

New test build, hopefully finally fixed: http://mirrors.kodi.tv/test-builds/win32...ash_h0.exe
PDB file: http://mirrors.kodi.tv/test-builds/win32...ash_h0.pdb

Please, report!

[Martijn]

@Martijn, it was requested.
Someone wants just to try test build and then return to latest release.

I see no reason to do that. In mean time we also fixed crashing for some repo trouble and who knows what else

Is there a database update in 14.1?

We never update database versions in point releases

[Pretoriano80]

@Karlson2k : thx for the new build mate i will install it tomorrow.
And btw, the previous build it's also pretty stable here, no crashes yet (and i tried hard to break it ).