Login at Kodi Home

**jfcarroll** · 2012-12-01, 16:46

Sranshaft,

Can you give me the exact steps to reproduce this, including which Program addon you're running, where you're playing the video from, etc?

Thanks.

**jfcarroll** · 2012-12-01, 18:34

I can't seem to reproduce this on the latest codebase in Windows. There's been many changes since beta1. Can I get you to retry it with the current master?

**jfcarroll** · 2012-12-01, 18:51

And please distinguish between a hang and a crash, in case I'm not looking for the right thing.

Sranshaft · (This post was last modified: 2012-12-02, 07:00 by Sranshaft.)

(2012-12-01, 16:46)jfcarroll Wrote: Sranshaft,

Can you give me the exact steps to reproduce this, including which Program addon you're running, where you're playing the video from, etc?

Thanks.

It's pretty hit and miss and there aren't any steps to really reproduce it - ie. click this, navigate here, and crash. Some times it'll crash after an hour, some times it'll take several hours. The only common thing is that it will always crash when I try to start a program addon. The program addons I'm using are ForumBrowser, TV Next Aired, GlobalSearch and Metadata Actors.

The videos I'm playing are all contained on external hard drives connected directly to the HTPC.

(2012-12-01, 16:46)jfcarroll Wrote: And please distinguish between a hang and a crash, in case I'm not looking for the right thing.

It is definitely a crash as all of the crashlogs on the Trac ticket were generated from this issue.

I have noticed that at least one of those addons - ForumBrowser - is calling non-API actions with an error about memory leaks. I'm wondering if this is what causing the crashes? The odd thing is I never had this issue before the Beta 1 release of Frodo; I had been using the Frodo nightlies before that though.

Code:
13:59:53 T:4612   ERROR: EXCEPTION: Non api type passed in place of the expected type "p.XBMCAddon::xbmcgui::Action."

13:59:53 T:4612   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--

                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!

                                            Error Type: <type 'exceptions.TypeError'>

                                            Error Contents: Non api type passed in place of the expected type "p.XBMCAddon::xbmcgui::Action."

                                            Traceback (most recent call last):

                                              File "C:\Users\Calvin\AppData\Roaming\XBMC\addons\script.forum.browser\default.py", line 2231, in onAction

                                                BaseWindow.onAction(self,action)

                                              File "C:\Users\Calvin\AppData\Roaming\XBMC\addons\script.forum.browser\default.py", line 409, in onAction

                                                BaseWindowFunctions.onAction(self,action)

                                              File "C:\Users\Calvin\AppData\Roaming\XBMC\addons\script.forum.browser\default.py", line 383, in onAction

                                                xbmcgui.WindowXML.onAction(self,action)

                                            TypeError: Non api type passed in place of the expected type "p.XBMCAddon::xbmcgui::Action."

                                            -->End of Python script error report<--

Here's a debug log I was able to get last night. https://dl.dropbox.com/u/3687220/xbmc.old.log

Another debug log: https://dl.dropbox.com/u/3687220/xbmc.old.2.log. Crashed while the screensaver was activated. My wife noticed something that I thought I should pass on. XBMC seems to crash more often when there has been a long period of inactivity. Whether this has anything to do with the removal of the built-in slideshow screensaver is yet to be determined.

Latest build used where I'm experiencing these crashes is the November 28th build. I will try to get the newest build and report any possible changes.

**jfcarroll** · 2012-12-02, 22:56

I think I know what the problem is. There's no type checking on the 'self' pointer passed to python methods and the Forum Browser script is simply wrong. If you look at the above stack trace you'll notice that line 383 of default.py calls xbmcgui.WindowXML.onAction and passes 'self'. But 'self' isn't a WindowXML instance. It's a BaseWindowFunction instance, which inherits from a ThreadWindow, which inherits from nothing.

Ultimately this results in memory being written that shouldn't be and eventually leads to a crash.

I'll fix the type checking but the forum browser along with any other script that makes the same mistake will need to be fixed.

**jfcarroll** · 2012-12-02, 22:57

Sorry ... I was wrong. There is type checking. But that script is still wrong.

**jfcarroll** · 2012-12-02, 23:23

ha. nm on the first issue also. It looks like the actual object is actually a WindowXML inherited in lower down the hierarchy.

Sranshaft · 2012-12-03, 00:25

@JFCarroll: I really appreciate the time you're spending on this issue. I know how hard it is to debug a problem that you don't get yourself.

I wanted to share with you the experience I had last night / this morning and hope that it helps you narrow down the cause. I used the HTPC last night for about 6 hours watching videos both through addons and local files, used the program addons - ForumBrowser, Metadata Actors, TV Next Aired - without a single problem. No crashes, no hangs, nothing. Throughout this period the slideshow screensaver never activated. Fell asleep and woke up to the screensaver going. Figured I'd check to see if it would crash when starting a program addon and sure enough it did.

It appears that as long as the screensaver doesn't activate, XBMC doesn't crash - or doesn't crash as often. Trying to repeat the scenario without using the slideshow screensaver at the moment to see if it changes the outcome. The steps I'm using in this test scenario is as follows:

1. Start XBMC .
2. Start ForumBrowser and navigate through that addon for 5 minutes.
3. Close ForumBrowser.
4. Wait for the screensaver to activate.
5. Wait 3 hours (could be shorter / longer but I figured 3 hours is good time in between testing and simulates falling asleep with XBMC running).
6. Start ForumBrowser again and see if XBMC crashes.

I'll be doing this with the built-in Dim and Black screensavers and the new Slideshow screensaver addon to see if there any differences. Will report my findings.

Just a quick question: Is the crash coinciding with the screensaver just a coincidence or could that be a possible cause / side-effect of the underlying issue? If I remember correctly, the slideshow screensaver was removed in Frodo Beta 1 which is when this crash issue first started to appear.

I agree that the error message in ForumBrowser should be fixed but before Frodo Beta 1, I never had XBMC crash as often as it does now which would lead one to believe there is something else causing the increase in crashes beyond the memory leak in ForumBrowser.

**jfcarroll** · 2012-12-03, 01:29

It's not just a memory leak. It's actually passing a bad data type to the C++ call resulting in a C++ exception. The C++ exception is then mapped into a python exception. This seems to leave the python virtual machine in a really bad state. The WindoXML object is still alive and still receiving messages even though the script is stopped. I know how to fix the script. I want to make sure the C++ side can handle script mistakes correctly.

**jfcarroll** · 2012-12-03, 16:13

Ok. It took me a while to see what's going on.

I was totally convinced that Python was leaking objects since I could close an interpreter and never get a "dealloc" call I was expecting on a number of objects. So I wrote code to manage potential python leaks. Any instances that were created by the API that weren't cleaned up when the interpreter was closed, I cleaned up.

Well. Python does actually clean them up. It just doesn't do it when the interpreter is closed. Sometimes it does it when the NEXT interpreter is opened.

So, I think what is happening is that when you run a script that uses a WindowXMLDialog, it still exists after the script is finished. Then, later, when you start another script it does the final dealloc on that WindowXMLDialog. However, since the window is still running after the script is finished when the NEXT script starts, some pending callbacks are executed against the first window (perhaps in all of that time some message ends up sent to that window). Of course, when the call goes down into Python, the window isn't there since the interpreter that had that window python object doesn't even exist anymore.

I can fix this. It's just ridiculously complicated and I should probably refactor the code somewhat.

Sranshaft · 2012-12-03, 16:48

Great to hear you've been able to suss out the problem. Due to the complicated nature of this problem should we expect this fix to make it upstream after Frodo is finalized or are you hoping to get this into Frodo?

I'd like to again thank you for all the time you've spent on this issue. I know this is time that could be spent getting something else done and I really appreciate it mate.

**jfcarroll** · 2012-12-03, 17:52

I'll get a fix in the next few days.

**jfcarroll** · 2012-12-04, 16:17

If you want to try a fix and can build from a PR, you can try this: https://github.com/xbmc/xbmc/pull/1889

Sranshaft · 2012-12-05, 00:37

(2012-12-04, 16:17)jfcarroll Wrote: If you want to try a fix and can build from a PR, you can try this: https://github.com/xbmc/xbmc/pull/1889

Cheers for that! Unfortunately, I don't have a build environment set up so I'll have to wait until this gets rolled into a nightly to test. Will let you know how things go when that happens.

hunkyn · 2012-12-05, 02:16

Thanks guys seems like there has been a lot of progress. I will also test it out extensively after we get a nightly. Thx