Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth  wrote:

> I got a tweet from you asking for a donation (or rather a 'partner', which
> apparently means 'money'), but couldn't frame a useful response in 140
> chars, so since this thread is coming back, I thought to do so here
> instead.
>

Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
> something open and available, what is the benefit to an advance copy of the
> jar if I, an author of a library and several open source tools and
> applications, cannot provide it to my customers or other downstream users?
>

That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


> We've found that https://gist.github.com/niloc132/3906501 goes a heck of
> a long ways toward offering optional debug info - if not enabled, the user
> gets the normal-size application with zero size or performance hit, and by
> redirecting to a slightly different url, the full trace info can be pulled
> out (with the quirks you mention of course*), which typically goes a long
> ways toward identifying the real issue.
>

Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


> * How often have you needed to know which line of Impl.java or
> DOMImpl.java a stack trace intersects? To make your case more effectively,
> you might consider using code where it is meaningful to see those lines,
> something other than the equivelent of
> java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
> JSNI, or an annoying IE6-9 focus() or setAttribute issue?
>
>
Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


> You touch briefly on the risk of '[exposing] your application’s
> implementation details', but unless I am mistaken, the extra metadata
> included in the file:line ints should still be enough to take apart an app
> and map it to discrete files and reconstruct methods, even un-inlining (as
> you mention) to pull out clearer details. My understanding was that the
> premise of the sourceMap was to work entirely from the stack to allow the
> actual source to be obfuscated, and avoid any other metadata from being
> left in the compiled output. Combine this with the fact that many of those
> classes are publicly available (GWT itself, etc), and it seems that you
> could reverse out a significant portion of the app - the "secret sauce".
> Can you comment on using this for public applications and any reverse
> engineering attempts you've made?
>

Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this "cipher" is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
"salt" to the output.

Thanks for your questions!
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Brian Slesinsky]

Thanks for looking into how to improve Java stack traces. I agree that we
could do a better job. However, there are some problems with your approach:

First of all, we can't guarantee that we will accept this change. That
doesn't seem very fair to whoever might be donating money.

I would like to make sure we come up with a solution taking the best
features of everyone's ideas, while remaining as simple as possible. See
the discussion about GWT.create() improvements for an example. So the final
result will likely be modified and include ideas from multiple
contributors, though course the person who volunteers to do most of the
work often has the largest influence. And simple patches aren't a solo
effort because someone has to review them and try them out.

With a project as complex and widely used as GWT, the drawbacks to a change
may be unexpected. It's unfortunate, but we often find that after
committing a change to Google's codebase, we discover problems that nobody
thought of in review and we not caught by GWT's own tests. It's much easier
to test a change if it's broken up into smaller patches.

So if possible it's best to split up a larger feature into smaller patches
and consider each of them on their merits. For example, if some things are
just bug fixes, we should review and commit them separately. This is often
a good way to get started in the community - before trying something large,
fix simpler bugs. This gives us a chance to get to know your work through
smaller and less risky changes, and you'll likely learn things along the
way. Resist the urge to add more features since that makes a change riskier
and harder to get agreement on.

- Brian

On Mon, Aug 19, 2013 at 1:06 PM, Alex Epshteyn  wrote:

> Hello folks,
>
> I just wanted to remind everyone that the last day to fund this project is
> this Friday, August 23.
>
> I've been using this framework in production in my app now for 2 months,
> and it works great.  Have logged 70,000 perfect stack traces so far!
>  Already fixed 3 major bugs in my GWT-based UI code that I would NEVER
> found otherwise.
>
> Let's get this capability into GWT by the end of the year.  Please donate!
>
> Thanks,
> Alex
>
>
>
> On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:
>>
>> Dear fellow GWT users,
>>
>> I would like to announce that I have finally solved what I always thought
>> to be GWT's greatest weakness: its lack of debugging information for
>> client-side exceptions in production.
>>
>> With my patch, your deployed app will be able to report stack traces like
>> this:
>>
>> com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null
>> com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(**
>> DOMImplMozilla.java:145)
>> com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(**
>> Document.java:1287)
>> com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(**
>> PopupPanel.java:884)
>> com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(**
>> PopupPanel.java:453)
>> com.typeracer.commons.client.**widgets.EnhancedPopup.**
>> EnhancedPopup(EnhancedPopup.**java:32)
>> com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(**
>> PopupWithFocusableTextBox.**java:28)
>> com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand**
>> ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55)
>> com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(**
>> SchedulerImpl.java:50)
>> etc... :-)
>>
>>
>> instead of the current state of affairs that looks like this:
>>
>> lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:
>> http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.html
>>
>> stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2422
>>
>> Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2423
>>
>> dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:3190
>>
>> tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2810
>>
>> Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
>> B8.cache.html:2289
>>
>> etc... :-(
>>
>>
>> I am asking the community to support me in finishing this effort and
>> integrating my patch into GWT.  Please take a look and what I've done, and
>> consider making a donation:
>>
>> http://igg.me/at/gwt-stack-**traces/x/3494291
>>
>> I am an indie developer and I just need some funding to continue this
>> work.  I'm looking for bot