This content has been marked as final. Show 18 replies
In the builder's debugger, step through the code to see what is going on.
Afraid that doesn't work. Because the code is very much signal-based, threads of execution begin and end in the middle of nowhere. I can step thru all the code I want but invariably I end up at a dead end (ie. the stepped doesnt go anywhere anymore, and I can only continue by clicking "play")
The ObjectUtil is useful for expanded trace.
If you have Flex Builder Professional you can use the profiler.
Have you tried that? If so, what results did you get? I haven't used it yet, so I am not sure if it will be beneficial in this case.
KreeK, not quite the problem I'm dealing with here, but an issue I have struggled with before. Thx for that tip!
myIP, just the standard version, the Linux version in fact. Otherwise though it doesn't appear to e an exact solution to the issue of figuring out where a crash is occurring, it does look like it could get you close by allowing you to watch what objects are created and working from there.
I'm still hoping for that elusive response of "just select this checkbox and Builder will put out a breakpoint signal at every line". If this feature isn't available, it sure as hell should be. Cases where an unexplained and hard to find crash occurs must be commonplace. This feature would save many hours of debugging in such cases.
Perhaps the application is not the problem.
I'm assuming you do not get any error message before the browser crashes. Could be the browser is the problem. Can you export a release build and try in on another machine with a different browser and perhaps different OS?
Correct, no error messages of any kind. Browser just segfaults.
And without getting into the usual debate of where does the line of code fault lie (clearly a browser shouldnt crash just cause the plugin did, something which Chrome finally realized), the problem occurred both with debug runs and release builds, running FF3 on Linux, IE7 on WinXP, and FF on OSX.
Sounds like you've done your homework. I'm sorry I don't have the answer. I haven't encountered this type of problem before. I'm not even sure an error handler (try...catch) would help you here since the problem could lie anywhere and you don't know where to put it..
Exactly the problem that an automatic trace would solve. Be nice to have a function that would automatically output a trace on every (user-defined, not builtin of course) method call. Or simply print a log indicating the file & line # of every line of code that was executed so you could see where it ends. Obviously a pretty verbose log to generate, but invaluable in such situations.
Without knowing the details or size of the project you are troubleshooting, I would suggest performing a unit test such as: FUnit or FlexUnit. Again, I haven’t used any of these yet, so I am not sure if they would be beneficial for this problem of yours.
An interesting tool, altho it requires a much more enterprise approach to writing code (a good thing, of course).
Clearly there is no answer I was hoping for forthcoming. Here's hoping Adobe (or Eclipse, not sure whose product this falls under) sees fit to implement this feature in the near future. Would be a HUGE time saver.
To those who submitted suggestions, thx for the help!
I haven't heard about any tool for tracing every line of code but I had a similar problem.
It was caused by embedding huge XML into my application (using <XML src="... /> tag).
When I divided XML into smaller parts and embed them separately the problem disappeared.
Search this phrase in the help docs:
Using the logging API
the mx.logging.targets class
Turns out there IS a way to log messages to a file.
Hope this helps you.
not sure if we're on the same page here rtalton. My goal isn't to log messages (a trace works just fine for this in most cases). The goal is to have automatic global tracing without having to run thru 100,000 lines of code and add 1000 or more traces to find out where it is crashing. If we can just check off one feature in FB and have it automatically log/trace debug output verbosely so we can see where something crashes (in cases where no error message is provided), this would save hours and hours of tracking such errors down.
Check it out. This looks like what you want: global tracing.
Took a close look at what you pointed out, but still can't see how it does what I am looking for. Seems that it requires specifying listeners on particular events, similar to having to manually add traces one by one.
What I mean by "global tracing" is a single checkbox somewhere that reads "log every line of source executed". Maybe that's a clearer explanation.
Oh well, it was worth a shot...
Appreciate the attempt. As with most suggestions so far, it has some interesting applications, just not quite what I'm hoping for. Thx.