flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Wells <leif.we...@gmail.com>
Subject Re: tracking down where "[trace] null" statements are comming from?
Date Wed, 23 Jan 2013 21:27:44 GMT
I assume the trace() is coming from your code and not from the Flex SDK.
Correct?

I have a tendency to use className in my traces to make sure I know where
output is coming from:

trace(className + ": someVar value: " + someVar);

This approach may be too OG for you, but I thought it might help.


Leif



Leif Wells
Atlanta
http://www.linkedin.com/in/leifwells


On Wed, Jan 23, 2013 at 4:17 PM, Wayne Studley <waynestudley@me.com> wrote:

> Quick question - are your components linked swc's / ane's etc or imported
> classes (as in a bunch of .as files)?
>
> If it's the latter you can use a tool like EasyFind (for Mac - no idea
> what a PC equivalent is) to search inside the files for any 'trace' strings.
>
> If the components are compiled swc's then you're going to have a tough
> time omitting the trace but I'm guessing it'll be somewhere in an imported
> .as file.
>
> Hope this helps?
>
> Wayne
>
> On 23 Jan 2013, at 21:00, "christofer.dutz@c-ware.de" <
> christofer.dutz@c-ware.de> wrote:
>
> > 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:gosmith@adobe.com]
> > Gesendet: Mittwoch, 23. Januar 2013 19:02
> > An: users@flex.apache.org
> > 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:aharui@adobe.com]
> > Sent: Wednesday, January 23, 2013 9:56 AM
> > To: users@flex.apache.org
> > 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" <gosmith@adobe.com> 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:montoyland@gmail.com]
> >> Sent: Wednesday, January 23, 2013 4:02 AM
> >> To: users@flex.apache.org
> >> 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, "christofer.dutz@c-ware.de"
> >> <christofer.dutz@c-ware.de> 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:omarg.developer@gmail.com]
> >>> Gesendet: Mittwoch, 23. Januar 2013 11:00
> >>> An: users@flex.apache.org
> >>> Betreff: Re: tracking down where "[trace] null" statements are comming
> from?
> >>>
> >>> On Wednesday, January 23, 2013, christofer.dutz@c-ware.de 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
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message