[QLab] Crashing, hanging & freezing

1,703 views
Skip to first unread message

Rich Walsh

unread,
Dec 2, 2010, 7:49:12 PM12/2/10
to Discussion and support for QLab users.
This is a technical question for Chris really, but I thought it might help anyone else who finds themselves trying to support QLab installations and being told QLab "crashed" when it actually "hung"...

Is there a programmer's distinction between "crashing", "hanging" and "freezing"?

To me, a "crash" is something that results in QLab quitting of its own accord with a little message to tell you that it has done so, and a lovely little note ("crash report") for you to send to Figure 53 next time you load QLab so that they can figure (!) out which bit of code confused the Mac so much that it just had to give up on the whole affair. These reports persist in the Console.

"Hanging" is when that funny coloured spinning thing pops up (what is it _actually_ called? I hate all those melodramatic names!) to tell you that an application is busy right now and doesn't want any more input from you thank you very much. Sometimes this goes away, but occasionally the application moves into "not responding" and you have to force quit it. This generates a "hang report" that Apple want you to send them. These reports don't persist in the Console, and looking in the Console for what was going on at the time of the lack of response seldom seems to shed any light onto what the computer thought was more important than dealing with you at the time.

What causes these kind of "hangs"? I did it to QLab myself this morning by switching to the backup machine too quickly and asking QLab to do a Reset All on a large workspace while the OS was still busy re-evaluating all the USB devices it had just gained - at least this is what I assume caused it. I can write infinite loops in AppleScript that cause things to hang, but on the whole hangs don't feel like QLab's fault to me: I can almost always identify that I have just asked it to do too many things at once in quick succession (like firing multiple cues during a QAutoSaver save or triggering a perverse script). We've had one "hang" mid-show in a year (across 3 theatres), which coincided with a flurry of firewall activity - so I put this down to the computer being on the network when it should not have been.

Finally, "freezing" to me means that the mouse stopped moving (an utter rarity in Mac OS X).

Have any bug fixes in the history of QLab ever addressed "hanging" rather than "crashing"? Is this a useful distinction to make when trying to troubleshoot an issue? Is there anything useful to be gleaned from one of Apple's hang reports? If you have 15 identical machines and one of them is suddenly reported as "crashing all the time" because QLab became unresponsive whilst programming does that tell you that you need a new version of QLab (even though many, many other shows have been programmed on these machines with this version), or perhaps that something else has been changed on that machine - in which case, what?

Thanks.

Rich


________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

Paul Gotch

unread,
Dec 3, 2010, 5:50:05 AM12/3/10
to ql...@lists.figure53.com
On Fri, Dec 03, 2010 at 12:49:12AM +0000, Rich Walsh wrote:

> "Hanging" is when that funny coloured spinning thing pops up (what is
> it _actually_ called?

It's actually called the 'Spinning wait cursor'

http://en.wikipedia.org/wiki/Spinning_wait_cursor

However that is a mouthful so many people call it the 'beachball'.

In OS X the beachball means that the application has stopped responding
to events. Usually this is because it's deadlocked or livelocked.
However it is possible that it's actually a system, usually hardware,
problem.

For example if you have a dieing harddisk then you get beachballs due
to applications blocking on disk IO, while waiting the disk to try and
recover the error, and not responding to the OS.

-p
--
Paul Gotch
--------------------------------------------------------------------

Christopher Ashworth

unread,
Dec 3, 2010, 9:59:34 AM12/3/10
to Discussion and support for QLab users.
On Dec 2, 2010, at 7:49 PM, Rich Walsh wrote:

> This is a technical question for Chris really, but I thought it might help anyone else who finds themselves trying to support QLab installations and being told QLab "crashed" when it actually "hung"...
>
> Is there a programmer's distinction between "crashing", "hanging" and "freezing"?

[...snip definitions...]

Your definitions sound right to me.

> Have any bug fixes in the history of QLab ever addressed "hanging" rather than "crashing"?

I'd categorize the issue with inefficient script access to large workspaces as a hang, thus making the release that made script access more efficient as addressing a hang.

> Is this a useful distinction to make when trying to troubleshoot an issue?

Yes, although, as with many diagnostics, it's often a small datapoint from which to try to reconstruct the larger picture of the problem.

> Is there anything useful to be gleaned from one of Apple's hang reports?

As with crash reports, sometimes yes, sometimes no.

> If you have 15 identical machines and one of them is suddenly reported as "crashing all the time" because QLab became unresponsive whilst programming does that tell you that you need a new version of QLab (even though many, many other shows have been programmed on these machines with this version), or perhaps that something else has been changed on that machine - in which case, what?

Yes, it could mean something has changed on the machine. It could also mean that this particular show is being constructed in a way that is encountering a previously unseen QLab bug, or a limitation of the hardware.

The common thread in all of the above cases is that *something* is different, since, as annoying as computers are, they do tend to produce the same outputs given the same inputs. As such, when something changes, something has changed. Either programming, or software (QLab or otherwise), or disk has gone bad, etc. The troubleshooting process pretty much always boils down to cordoning off possible changes, and getting the range of possibilities narrower and narrower.

The great frustration of using closed source is that big chunks of functionality resist this process, since they're a big black box. Also, some kinds of bugs are more subtle than others, and don't come down to "this line of code is wrong", but "these lines of code in these separate files are wrong *sometimes*, depending on the order in which operations happen, etc."

Yay for computers. It's a small miracle they boot at all.

-C

Reply all
Reply to author
Forward
0 new messages