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:35:46 GMT
Sorry, Chris.

I finally got to the rest of this thread. My solution is pointless. Sorry.

Kind of sucks that there are traces coming from a 3rd-party component set,
though. Especially a trace that says something unhelpful like "null".
Thanks for nothing, eh?

Leif




On Wed, Jan 23, 2013 at 4:27 PM, Leif Wells <leif.wells@gmail.com> wrote:

> 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