[Maxim]

I was thinking some users have experienced locks or crashes with XBMC, and how helpful it might be if XBMC could detect when it crashes or freezes and automatically produces a backtrace.

I only have experience with the Linux XBMC so i'm not sure what would be involved for the Windows version. It doesn't seem like it would be out of the question, and it might help the devs out if the users could easily/automatically produce the vital information that could be provided in a backtrace.

I'm not sure if the backtrace is really all that important, but the few times i've seen one referenced here on the forums the devs almost always reply back shortly after and go, oh yeah, I see the issue, keep an eye on the SVN for a fix in the next few days.

I'm no programmer but it seems that the backtrace could be handled/created with a wrapper script of sorts. What do you guys think?

[althekiller]

http://trac.xbmc.org/changeset/22194

A few steps ahead of you... Obviously there's no way to detect a deadlock within the app itself. That would require the kernel to support such things, which no real OSes bother doing as it's quite resource intensive. You can kill xbmc.bin with sigsegv and generate a core anyway.

[Maxim]

Man, you guys are awesome, and obviously i'm not as insightful as I thought since I neglected to search trac before posting. Sorry for that, I just don't know my way around as well as I do the forums. You've even done it in the fashion which I thought would work, so cool. At least I was going in the right direction.

I'm going to look around to see if that sigsegv thing is documented. I haven't heard of that yet. So it's able to close the application in a special fashion which would allow the devs to see what went wrong right before the freeze? If that's the case, if XBMC does freeze, and someone kills it with this sigsevg message, the script would still operate properly and get the same result as if it crashed "proper," right?

[Maxim]

Many applications use a heartbeat to accomplish detecting when something has gone wrong. Maybe XBMC could send out a message to an application running as a service, or the service could query XBMC. This could be done once every 30 seconds or so. Resources would probably be minimal and it probably wouldn't effect performance at all. When something goes wrong and XBMC is no longer responsive the service could kill XBMC with the appropriate command.

The command which some users have had success with creating crash reports and core dumps is:

Code:

pkill -SIGSEGV xbmc.bin