no, sure haven't. though i've never checked the "omit trace" option. what's the point?
If you use trace output to aid in the debugging of your SWFs, It's usually a good idea to omit trace when you publish a forward facing production version of your SWF. It will improve performance and hide any debug information that you do not want end users have access to.
I have used this feature in past version of Flash without any issues.
i use trace() frequently. but as i eliminate errors i eliminate or comment-out trace statements. by the time i finished i have no more errors and no more trace statements.
why would you leave trace statements active in a finished project?
I don't leave trace statements in an active finished project. I use omit trace actions to remove them. I have found this approach more efficient than selectively commenting in and out hundreds of lines of code in multiple files that may or may not have been created by myself alone.
kglad, I'm be happy to discuss flash debugging practices with you, but I wonder if in the future this thread could be reserved for discussion regarding any experience developers or Adobe staff have with this potential issue with the flash CS3 compiler?
sorry, my bad.
I've experienced the same problem yesterday. Flash CS5 or FlexSDK 4.1 latest prod. & AS3.
I can only show what was my problematic code part:
private function methodCalledFromEventDispatcherClonedEventDelegatedToRPennerSignal (medium:Signal)
// just some comment
// just some comment
After i've tried to delete trace statement line-by-line, when i've deleted the trace("whatever") code, i was getting the same compiler error (stack underflow nasty exception)
But when i've moved my double comments from case Const.C: the problem was solved... so it was not a trace statement that was causing the exception, it was caused by a nested multiline comment inline in a switch statement.
Also i must notice that using nested conditions inside switch statements also can make some headaches, nowadays i'm more preferring using State design pattern or just very simply calls in switch statements (FlexPMD also gives a notice about that if you inspect your code).
About using trace command:
In my development practices i prefer using native API usage as far as possible, so i don't use any external logger class dependency unless it's a huge enterprise level application where i need different report targets (like firebug console, hudson, etc.) - trace is just simply enough to follow code execution or find where the code is broken when the throwen expection is not really exact.
When the project is in implementation phase i'm building test versions with mxmlc debug option enabled (same as in Flash CS omit trace actions unchecked) so all the trace actions are compiled in the code.
After the implementation phase is complete you can switch to Release or Pre-release version where you can turn off the debug option and test/release with optimized code (mxml debug option false or Flash CS omit trace actions enabled) without any trace calls.
If you are using an external logger like Thunderbolt AS3 Logger and you want to exclude these references from the code, you have to use some pre-build filter with the code (with apache ant for example) or a conditional compilation (IFDEF), as far as i've experienced if you are working with a design team which is using Flash IDE these are not really options.
ps.: Joa Elbert's great Apparat is also capable in swf byte level optimalization, so you can write your own pre/post compiler in fact ( http://blog.joa-ebert.com/tag/apparat/ )