Gee ... I really hoped this would work, cause it looked like the type of AS voodoo I was hoping to find. So I created a file "trace.as" and pasted in your code. IntelliJ jumped to the right place, but the breakpoint was not hit. In order to try if defining functions this way worked, I added the same function (called "lalala" in a file called "lalala.as") and called both functions from initializing code ... lalala was hit, trace wasn't ... so I guess this hack was a good idea, but it didn't work :-(
Decompiling is problematic, as the Flexicious components have a copy protection and decompiling that code would result in me losing my license ... I don't want to risk this after paying that much money for it ;-) Well I think I'll simply live with the trace statements :-| But thanks anyway, Chris -----Ursprüngliche Nachricht----- Von: Gordon Smith [mailto:[email protected]] Gesendet: Mittwoch, 23. Januar 2013 19:02 An: [email protected] Betreff: RE: AW: tracking down where "[trace] null" statements are comming from? Isn't trace() is just a public function in the unnamed package? I'd try putting a file with package { public function trace(...args):void { var i:int = 0; // set breakpoint here } } on the source path. Then mxmlc should find this trace() instead of the trace() in playerglobal.swc. But I've never tried monkey-patching a non-method, or anything that is native. - Gordon -----Original Message----- From: Alex Harui [mailto:[email protected]] Sent: Wednesday, January 23, 2013 9:56 AM To: [email protected] Subject: Re: AW: tracking down where "[trace] null" statements are comming from? I'm not sure how to do that. But consider this: When the flex tool chain creates a SWF in release mode, it cleans out trace statements, so whatever is spitting a trace has debug code in it. The swfdump decompiler will certainly show you what SWFs have debug code in it. Then, I generally use divide and conquer by placing breakpoints and seeing if the flashlog.txt has the trace in it. But once you get to a "reasonable" boundary around the area, you can also use the poorly documented flash.trace.Trace to dump all function calls leading up to the trace statement. On 1/23/13 9:48 AM, "Gordon Smith" <[email protected]> wrote: > Is it possible to monkey-patch trace() to substitute your own version, > and set a breakpoint in it? > > - Gordon > > -----Original Message----- > From: Michael Montoya [mailto:[email protected]] > Sent: Wednesday, January 23, 2013 4:02 AM > To: [email protected] > Subject: Re: AW: tracking down where "[trace] null" statements are > comming from? > > Hey Chris, > > This may be a long shot, but how about using a an swf decompiler? I > remember ising Trillix awhile back and was very impressed by the > amount of detail provided in the diagnostics - It may pinpoint the > source of your trace statement... > > Cheers! > > On Jan 23, 2013, at 11:46 AM, "[email protected]" > <[email protected]> wrote: > >> Hi Omar, >> >> thanks for that input ... I knew that "trace" is a Flash function. I >> was simply hoping for some guru here to give me a hint to the >> "ultimate way to debug this" ;-) As it would help quite a lot ... >> especially when having AMF serialization/deserialization problems >> (The other type of problems that seem to be really hard to debug) >> >> Chris >> >> -----Ursprüngliche Nachricht----- >> Von: Omar Gonzalez [mailto:[email protected]] >> Gesendet: Mittwoch, 23. Januar 2013 11:00 >> An: [email protected] >> Betreff: Re: tracking down where "[trace] null" statements are comming from? >> >> On Wednesday, January 23, 2013, [email protected] wrote: >> >>> Unfortunately I can't set a breakpoint to the "trace" function ... >>> perhaps it would be good if in future versions of flex there would >>> be the means to somehow do this. >>> >>> Chris >> >> The trace() function is not a method from Flex it comes from Flash player. >> There really isn't anything that can be done at the Flex level. >> >> I would try to get source code for your 3rd party libraries and >> search for trace statements. If the source isn't available then >> you're probably out of luck. Or you can try a decompiler. >> >> Also, I don't know enough about Adobe Scout but maybe that could help >> you narrow it down. >> >> -omar -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
