Pseudorandom crashes in Flash Debugger - My bad, or Abode's?

Question

I'm working on a large-size dual AS3/Flex project (some parts are pure AS3, other parts are Flex), and I'm experiencing a lot of Flash Debugger crashes.

These crashes aren't completely random - it seems like I can get them to occur with greater consistency when I perform certain actions in my app. However, at the same time, they aren't consistently repeatable - sometimes a set of actions causes my app to crash, and other times, the same steps execute fine without a crash.

I have two questions (carefully worded to remove my personal bias :) )

1. Are these crashes due to my coding practices, or Adobe's Flash Debugger?

   1a. If these crashes are due to my coding, how do I go about fixing problems that aren't consistently repeatable? :P

2. When I deploy my app on a web site and access it via Flash Player, should I expect the same crashes to occur, or is Flash Player considerably more resilient than Flash Debugger?

Thanks so much, all! :)

-Rich

---

UPDATE:

Thanks for the responses, all! Some more background information:

1. I'm using the pretty-good DeMonster Debugger (http://demonsterdebugger.com/) as well as a homegrown Profiler class to monitor memory/processor strain of my app. I'm reasonably confident that the crashes are unrelated to memory/processor burden because I can (somewhat consistently) get the app to crash with very little strain within 30 seconds of execution.

2. Due to the architecture of my application, memory leaks become apparent quite readily. Therefore, I've been able to/forced to eliminate at least the majority of the memory leaks. While I admit there are likely still memory leaks present, memory usage is trivially low at the point I can get the app to crash, so it seems unlikely to be related.

3. Now for some details on the actual offending code:

The app's undo mechanism (XMLManager.as) works by storing changes to the model (represented in XML). To undo a change, the app reloads (re-instantiates) key components based on the XML stored in XMLManager.as. To get the app to (somewhat consistently) crash, I can perform a set of actions that are all related to a certain class in the app, the Line.as class. Performing the actions causes no problems, but Undo()ing them causes the app to crash.

The most confusing part of this is that the XML stored by the XMLManager class is effectively identical in the crash scenario and in the no-crash scenario. Another confusing aspect is that the crash scenario is introduced by one line only:

xml += ' text="' + text + '"'; //does not lead to a crash

xml += ' text="' + tf.text + '"'; //leads to a crash

'text' is a string that is supposed to mirror the content of tf.text (tf is a TextField). This line is found in the Line.toXml(), the method used to convert a Line into its respective XML for storage in the XMLManager. So, the confusing thing about all of this is that using tf.text ultimately leads to a crash in the undo mechanism, even though the XML stored in the XML mechanism has not substantially changed...

To make things even more confusing, I can output the complete XML before starting the undo process. This way, when Flash crashes, I have a record of the XML that caused it to crash. If I take that exact same XML (which, upon manual inspection, appears normal) and feed it back into the app as its initial state, no errors occur and Flash does not crash.

So much confusion! :)

Sorry for the long explanation; perhaps you can see why I'm at a loss here!

(Note that I have found a workaround - instead of using 'tf.text' directly in the code toXml() code, I can keep 'text' up-to-date with the contents of 'tf.text' at all times. This approach, which theoretically leads to the same XML being used, performs fine without crashes...)

Any thoughts?

Answer 1

1. Adobe's Flash Debugger, a debugger is not supposed to crash, but it's also a sign that your code might not be very stable.
2. I personally find that FlashPlayer has a higher tolerance, I find it great that there are so many not carefully programmed Flash Applications, which contain memory leaks and FP is still running, despite all the cruelty.

Answer 2

I think the flash debugger might actually be less prone to crashing than the regular player, as it runs slightly slower than the normal version. I've built some extremely large flash applications, and I haven't experienced the kind of instability you describe without there being something wrong with my code.

To clean up your problems I'd recommend:

1) Profile your application. See you have any memory leaks or anything like that. (http://livedocs.adobe.com/flex/3/html/help.html?content=profiler_3.html)

2) Clean up all event listeners when you're done with them using removeEventListeners

3) Reuse objects where possible

4) Monitor your framerate to see where things are slowing down: http://www.gskinner.com/blog/archives/2008/04/simple_componen.html

Without actually seeing the code that's running though it's hard to give anything other than vague suggestions. Is the code that's running when the crashes occur particularly graphics heavy? Is it doing some serious number crunching?

Answer 3

With large project, its performance is undesirable, depending on machine configuration. The Flex debugger can crash but more often the flash player freezes when debugger and debug flash player does not communicate well.

It crashes more easily when system resources become tight. It might be that your codes does not manage resources well. It might be that your machine is not powerful enough for your task. You probably need to check memory footprint from time to time. You probably need to rework your algorithm or data structure to meet tight configuration.