We have an app that keeps crashing (taking the browser with
it) but we can't find out WHERE it is crashing. We've loaded it
full of traces but it is far to large to add enough traces to find
the problem, and because the app is so heavily asynchronous there
is no way to set a breakpoint and step through the code till it
crashes (the path invariably ends before it has crashed).

Is there a way to have builder trace/log every line of code
during debug execution? This way we could simply look at the log
and see what line is causing the error. I've not found a way to get
Eclipse/Flex Builder to do this tho...

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")

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?

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.

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.

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.

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.