Hosted mode broken on MacOS X Leopard

[dankurka]

Originally reported on Google Code with ID 1792

Found in GWT Release: 1.4

Detailed description:

http://groups.google.com/group/Google-Web-
Toolkit/browse_thread/thread/44df53c5c7ef6df2

The hosted mode does not work in Leopard.  In my case, the browser pops up for
a second, but quickly disappears.  There does not appear to be any useful details
given stdout or stderr when it exits/crashes, nor is there anything useful that shows
up in Console.app.      In my case, I'm using Netbeans and gwt4nb, but  it also  fails
when I attempt to run it standalone.

I'm running the latest developer seed:  Mac OS X 10.5 (9A559)  The official release
is supposed to come out on October 26th, and I suspect it won't behave any better.

Other details available in the aforementioned group thread.

Workaround:  None.

Reported by pohl.longsine on 2007-10-21 22:36:19

[dankurka]

I wanted to seek a workaround for this problem, so I considered the hypothesis that
Leopard's JVM no longer requires the annoying "-XstartOnFirstThread" argument that
is commonly required to launch SWT-based applications.

I removed -XstartOnFirstThread from the startup script to see if it alleviated the
symptoms.

Sadly, GWT checks internally if it is running on OSX, and exits if the -XstartOnFirstThread
argument is absent.  This vexes me.    I understand that it is there for the sake of

useability, but couldn't it be a warning instead?

So, in the end, I was unable to carry out my experiment.

Reported by pohl.longsine on 2007-10-22 15:12:03

[dankurka]

I've removed check for -XstartOnFirstThread from GWT code, it does not help. Shell still
crashes on start.

Reported by krondix on 2007-10-22 19:01:08

[dankurka]

Just to confirm that it isn't any better with the official release. I'm running it from
Netbeans 6.0 beta 2 and get 
the following:-
2007-10-26 16:29:28.240 java[1867:80f] [Java CocoaComponent compatibility mode]: Enabled
2007-10-26 16:29:28.241 java[1867:80f] [Java CocoaComponent compatibility mode]: Setting
timeout for 
SWT to 0.100000
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at apple.awt.CGraphicsEnvironment.displayChanged(CGraphicsEnvironment.java:65)
Invalid memory access of location 00000000 eip=00000000
        at apple.awt.CToolkit$4.run(CToolkit.java:1259)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Reported by RJReader on 2007-10-26 15:34:56

[dankurka]

I suggest escalating the priority of this issue now that leopard is out.

Reported by pohl.longsine on 2007-10-26 15:53:19

[dankurka]

I've been investigating this tonight with the official Leopard release.  As best I can
tell, it looks like there are 2 
different problems:

Problem 1: Shell opens and immediately exits without any stdout/stderr
This happens when you run the shell with the embedded server enabled, either via Eclipse
or the command 
line.  I stuck it in the debugger & tracked down an exception thrown from 
javax.xml.parsers.DocumentBuilderFactory.newInstance() while starting the embedded
Tomcat (full stacktrace 
below).  This looks related to a bug in Apple's JAXP impl; see http://lists.apple.com/archives/Java-
dev/2007/Apr/msg00247.html.

I got past this issue by using an alternative JAXP implementation (xerces-j-2.9.1)
& prepending it to the 
bootclasspath.  Here is the first part of my launch script:
java -Xbootclasspath/p:xercesImpl.jar -XstartOnFirstThread -cp ...

Or you can run the script with -noserver, bypassing the embedded Tomcat altogether.
 Either way, this lets 
you progress to...

Problem 2: CGraphicsEnvironment NullPointerException/Invalid memory access
I'm getting the same stacktrace as RJReader.  As soon as the shell starts up, it crashes
with the "Invalid 
memory access" message, and with the NPE usually close by.  This happens on my box
regardless of whether I 
run with -noserver or with the Xerces bootclasspath.  

I haven't made any progress on this one.

------------------------------------------------------------
Problem 1: DocumentBuilderFactory.newInstance() Stacktrace
Daemon Thread [Thread-0] (Suspended (exception FactoryConfigurationError))  
    DocumentBuilderFactory.newInstance() line: 104  
    DomUtil.readXml(InputStream) line: 284  
    MbeansDescriptorsDOMSource.execute() line: 130  
    MbeansDescriptorsDOMSource.loadDescriptors(Registry, String, String, Object) line:
120 
    Registry.load(String, Object, String) line: 819 
    Registry.loadDescriptors(String, Object, String) line: 931  
    Registry.loadDescriptors(String, ClassLoader) line: 909 
    Registry.findDescriptor(Class, String) line: 992    
    Registry.findManagedBean(Object, Class, String) line: 696   
    Registry.findManagedBean(Class, String) line: 1047  
    Registry.registerComponent(Object, ObjectName, String) line: 859    
    CoyoteConnector.initialize() line: 1351 
    Embedded.start() line: 851  
    EmbeddedTomcatServer.<init>(TreeLogger, int, File) line: 237    
    EmbeddedTomcatServer.start(TreeLogger, int, File) line: 62  
    GWTShell.startUp() line: 742    
    GWTShell.run() line: 539    
    GWTShell.main(String[]) line: 321   

Reported by adam.houghton@sas.com on 2007-10-27 06:18:07

[dankurka]

Has anyone filed a ticket with Apple regarding the CGraphicsEnvironment stack trace?
 This looks like its deep inside Apple's windowing toolkit implementation and
probably not specific to GWT applications.  

Reported by ericzundel on 2007-10-27 11:51:39

[dankurka]

Same problem on the released version: Mac OS X 10.5 (9A581). Suggest escalating the
priority for this issue.

Reported by ion.b.moraru on 2007-10-27 13:13:20

[dankurka]

I submitted a bug report to Apple: "CGraphicsEnvironment NullPointerException breaks
Google Web Toolkit in 
Leopard".  Problem ID 5563333  in the Bug Reporter.

I'll keep this thread updated if I hear anything.

Reported by ahoughton on 2007-10-27 18:59:37

[dankurka]

Reported by gwt.team.knorton on 2007-10-29 14:29:17

• Status changed: Accepted
• Labels added: Priority-Critical
• Labels removed: Priority-Medium

[dankurka]

I don't have the GWT sources, but looking through our AWT I see a possible workaround.
Try calling 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices() early on in the
code. That will initialize 
the object that's null in this stack trace.

Reported by skovatch on 2007-10-29 16:54:21

[dankurka]

I tried this, and the hosted shell progresses a little further, but no  dice. I added
the line skovatch suggested as 
the first line of main() in GWTShell and rebuilt 1.4.60. Running Hello or KitchenSink
now no longer causes the 
Hosted shell to crash and disppear, rather the shell window appears, but is locked
up. You can't click on anything 
in the toolbar and the embedded WebKit remains empty. 

-Ray

Reported by cromwellian on 2007-10-29 20:16:14

[dankurka]

I hope this is a problem google can fix...I've got a lotta work to do...

Reported by sam@alloymms.com on 2007-10-29 21:01:42

[dankurka]

Yes, this is critical for me. I wasted several hours today reconfiguring my dev environment
to run inside a VM on 
my Mac Pro because of this (Ubuntu).  I hope skovatch and the GWT team are working
closely together to resolve 
this. I saw that some other SWT apps got semi-broke too.

(of course, this brings up the question that maybe the Hosted mode shell should be
a Swing app instead of SWT, 
you can still embed webkit/gecko inside Swing)

Reported by cromwellian on 2007-10-29 21:04:39

[dankurka]

Using a custom xercesImpl.jar from apache, and added the
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(); at the 76th
line of BootStrapPlatform.java, It works for a while loads the client application and
sometimes throw the not found sources exception 

[ERROR] Failure to load module 'org.drools.brms.JBRMS'
java.lang.NullPointerException: null
    at com.google.gwt.dev.util.Util.findSourceInClassPath(Util.java:292)
    at com.google.gwt.dev.util.Util.logMissingTypeErrorWithHints(Util.java:413)
    at com.google.gwt.dev.cfg.ModuleDef.getTypeOracle(ModuleDef.java:314)
    at com.google.gwt.dev.cfg.ModuleDef.refresh(ModuleDef.java:357)
    at com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:86)
    at com.google.gwt.dev.GWTShell.doLoadModule(GWTShell.java:687)
    at com.google.gwt.dev.GWTShell$BrowserWidgetHostImpl.loadModule(GWTShell.java:295)
    at
com.google.gwt.dev.GWTShell$BrowserWidgetHostImpl.createModuleSpaceHost(GWTShell.java:257)
    at
com.google.gwt.dev.shell.mac.BrowserWidgetSaf$ExternalObject.gwtOnLoad(BrowserWidgetSaf.java:58)
    at
com.google.gwt.dev.shell.mac.BrowserWidgetSaf$GwtOnLoad.invoke(BrowserWidgetSaf.java:119)

After a few minutes of use the client application crashes with the following error

    Macintosh-2:tmp fmeyer$ sh Myapp-shell 
    2007-10-30 03:24:41.597 java[2491:80f] [Java CocoaComponent compatibility mode]: Enabled
    2007-10-30 03:24:41.602 java[2491:80f] [Java CocoaComponent compatibility mode]:
Setting timeout for SWT to 0.100000
    Invalid memory access of location 00000000 eip=00000000
    Myapp-shell: line 3:  2491 Bus error               java
-Xbootclasspath/a:/stash/xercesImpl.jar -XstartOnFirstThread -cp
"$APPDIR/src:$APPDIR/bin:/Users/fmeyer/projects/google-web-toolkit/build/dist/gwt-mac-0.0.0/gwt-user.jar:/Users/fmeyer/projects/google-web-toolkit/build/dist/gwt-mac-0.0.0/gwt-dev-mac.jar"
com.google.gwt.dev.GWTShell -out "$APPDIR/www" "$@" tmp.Myapp/Myapp.html

ps: as you can see I got this working for a while on my Leopard.
ps: IMHO it looks like some bug in leopards latest WebKit

Reported by fmcamargo on 2007-10-30 05:30:43

---

• Attachment: Picture 3.png
  

[dankurka]

Are you getting a native stack trace with that crash? Launch Console.app and look in

~/Library/Logs/CrashReporter. File a bug at bugreport.apple.com, but it could also
be 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=207827>.

Reported by skovatch on 2007-10-30 05:55:47

[dankurka]

http://rafb.net/p/Hh9THh17.html not sure if it's the same 

Reported by fmcamargo on 2007-10-30 06:09:21

[dankurka]

some progress with this issue? Development process in my project is totally stopped
since saturday.

Reported by unreallity on 2007-10-30 15:25:41

[dankurka]

This is really critical (for me).
I think I have to install Windows in BootCamp to develop gwt now. (grrr:)
Would be nice I this could get fixed..

Reported by retoonline on 2007-10-30 16:32:19

[dankurka]

Folks: There is no reason to post a comment about how critical this issue is for you.
It is marked as critical, is 
being actively researched and is being treated with much urgency. If you must express
your frustration in some 
way here, please star the issue rather than posting a comment about  how much you wish
it was fixed. Those 
type of comments just make it harder to follow the trail of facts and observations
that are actually helping us 
figure this out.

Reported by gwt.team.knorton on 2007-10-30 17:28:58

[dankurka]

Understood, but any idea when this might be fixed.. The thought of having to go back

to windows for my development makes me want to gag... 

Reported by michellec41117 on 2007-11-01 12:13:32

[dankurka]

sorry, no eta on a fix yet. i hope to know a little more by the end of the day today.
also, if i find even a kludgy 
workaround, i'll note it here.

Reported by gwt.team.knorton on 2007-11-01 13:18:03

[dankurka]

can't wait, windows in my VM smells....

Reported by ralfschimmel on 2007-11-01 14:20:01

[dankurka]

Yes, windows smells :)

Reported by tony.wroblewski on 2007-11-01 14:46:21

[dankurka]

Please everyone, try just use this comment feature properly, There are few guys from
GWT working on this, I believe some community guys are trying to figure out what is
happening with GWT on Leopard ( including me ) and I use this channel to post
technical comments and receive updates from the official gwt team.

so please don't pollute this issue tracker, use mailing lists instead. 

Reported by fmcamargo on 2007-11-01 15:37:25

[dankurka]

Just a brief update for those following along:

There are at least 3 issues in the way here.

1 - The jaxp / xerces issue, which seems straightforward to fix.

2 - The AWT subsystem initialization, which I believe is fixed by skovatch's suggestion.

3 - And finally, the big one ... Our custom built WebKit can't run in Carbon on Leopard.
I don't know the deep 
details of this yet, but I've reproduced the crash in a pure carbon app. I know that
WebKit's Carbon interop 
underwent some changes (r25102 seems to be the larger of those). I'm still exploring
at this point and 
evaluating options, so I still can't offer an ETA.

I'll keep posting here as I learn more. Thanks everyone for your patience and to those
who have posted 
information, crashdumps and stack traces, double thanks.

/kel 

Reported by gwt.team.knorton on 2007-11-01 20:40:18

[dankurka]

I'm not sure how difficult this would be at this point, but could the OSX hosted mode
switch to using Gecko/Mozilla? Thanks for all the hard work.

-Ray

Reported by cromwellian on 2007-11-01 21:29:59

[dankurka]

Kelly,

In our (Instantiations) GWT Designer product, we've developed our own
JSNI implementation which requires no custom WebKit (greetings to
Mark Rowe (bdash) and big thanks for his great help :)). Although we
have not tested it on Leopard, it works very well with (and requires)
the Safari 3/Nightly WebKit on Tiger.

Instantiations is willing to offer you the Obj-C source code for our
native JSNI dylib for free on the condition of keeping credit for
Instantiations and Alexander Mitin.

Regards,

Alexander Mitin
Instantiations, Inc.

P.S. We've also developed a JSNI implementation for Linux which works
with any modern Mozilla/FireFox and requires no special version of
Mozilla or the SWT Browser widget.

Reported by alexander.mitin on 2007-11-02 13:56:48

[dankurka]

I used Leopard's new Disk Utility (after booting from the install disk) to re-partition
my boot drive. It took a 
while but worked great.

I then installed Tiger on the new partition and I'm totally back in business.

Windows?

JUST SAY NO!

S.

Reported by sam@alloymms.com on 2007-11-02 17:28:07

[dankurka]

S.

I just opted for using the Java tools in my Windows environment under parallels...

Can't stand it, but at least I can use the browser until Google fixes this issue.

Reported by codethought on 2007-11-03 04:31:06

[dankurka]

This is also affecting me... it is worth pointing out that the web mode (i.e. compilation)
still works, but the script 
which is autogenerated by GWT includes the JVM option "-XstartOnFirstThread". You must
remove this 
parameter to enable web-mode compilation from the command line.

Reported by Sam.Halliday on 2007-11-03 14:19:26

[dankurka]

Problem #4 has emerged and I believe it is a bug in Leopard's 1.5 JVM.

@skovatch: If you're still following this thread, perhaps you can shed some light on
this:

The basic problem is that when -XstartOnFirstThread is passed to the vm, the main thread
does not have a 
context class loader. So, take the following code:

public class Zee {
  public static void main(String[] args) {
    System.out.println(Thread.currentThread().getContextClassLoader());
  }
}

On Leopard:
$ java -XstartOnFirstThread Zee
null

On Tiger:
$java -XstartOnFirstThread Zee
sun.misc.Launcher$AppClassLoader@....

This is the reason for the stack trace reported by fmcamargo.

@alexander.mitin - I will send email to your  gmail address so we can discuss the details.
If you guys have the 
c++ glue code to work against JavaScriptCore's new public API, I'm interested in using
that to put together a 
quick fix for Leopard's WebKit issues. I've updated our code that uses the private
API's for JavaScriptCore, but 
running against system webkit on public API's would be much saner now that apple has
exposed them. One 
nice thing is that we're currently working on a new model where the hosted mode support
will be embedded 
in a standard browser. If it all works out, I think it will make life easier for all
of us as it will remove our 
dependencies on SWT's browser.

Reported by gwt.team.knorton on 2007-11-04 00:22:50

[dankurka]

Kelly,

OK, I wait for your message.

-- 
Alexander Mitin
Instantiations, Inc.

Reported by alexander.mitin on 2007-11-05 11:41:21

[dankurka]

Filed Apple Radar #5580914 for the context class loader issue.
Title: Java: main thread has no context class loader with -XstartOnFirstThread

Reported by gwt.team.knorton on 2007-11-05 23:23:29

[dankurka]

Kelly,

Can you work around that issue in any way?

Reported by codethought on 2007-11-05 23:30:51

[dankurka]

Yes, I have a work around for the class loader issue. In fact, I'm one issue away from
having a build that will 
work on Leopard. I'm hoping to put a link to an unofficial build up soon (tomorrow
... fingers crossed) that will 
get all you Leopard folks unstuck. Then I'll figure out how to make this a part of
an official GWT build.

Reported by gwt.team.knorton on 2007-11-05 23:48:02

[dankurka]

Ha,

Chances look even better for a build tomorrow. Part of the xerces issue seems to have
been related to the 
context class loader bug and I can now run all the examples on hosted mode in Leopard.

Reported by gwt.team.knorton on 2007-11-05 23:55:27

[dankurka]

Hyia, 

Hey K, are those changes on SVN? I think we can help you guys testing before the
unofficial release. 

What do you think?

Reported by fferrari.drive on 2007-11-06 03:34:40

[dankurka]

Awesome news Kelly, next time you are in Mountain View, I will buy you lunch! :)
(oh damn, I forgot how good Google food is)

Reported by cromwellian on 2007-11-06 03:37:24

[dankurka]

thanks alot for swift fix =)

Reported by prentesvarten on 2007-11-06 13:22:43

[dankurka]

I'm curious... what is the -XstartOnFirstThread command-line arg for, anyway?

Reported by codethought on 2007-11-06 14:33:05

[dankurka]

codethought: the following FAQ is the best explanation I've been able to find...

http://www.eclipse.org/swt/faq.php#carbonapp

Reported by pohl.longsine on 2007-11-06 15:14:19

[dankurka]

Reported by gwt.team.knorton on 2007-11-06 19:26:23

• Status changed: Started

[dankurka]

Hi there,

Will be happy to make test with Leopard too.

Reported by sebastien.degardin on 2007-11-06 22:37:01

[dankurka]

i know you guys are hitting it hard.  i'll test, too, if you want more eyes on it.

Reported by burton.miller on 2007-11-07 01:04:45

[dankurka]

I have put a build up for testing at
http://google-web-toolkit.googlecode.com/files/gwt-leopard-1.4.61.tar.gz

Some things to note:
1 - This is not considered a release build, so you won't find it in the main download
area.
2 - This build still doesn't use the System installed WebKit. It includes a pretty
current build of WebKit that should 
be very similar to Safari3. Down the road, I think we'll end up using system webkit,
but this build at least gives us 
some more time to plan accordingly.
3 - If you have trouble with this build, please post details here. 

Reported by gwt.team.knorton on 2007-11-07 07:46:23

[dankurka]

Thaks guys great job! up to now no problem yet! it seems to work fine! if I find
something i will post asap!

thanks again!

Reported by nicco82 on 2007-11-07 11:53:31

[dankurka]

no problems in IntelliJ 7.01 so far.

Reported by prentesvarten on 2007-11-07 12:28:14

[dankurka]

It works fine so far Eclipse 3.3 with and without Cypal-studio (formely Googlipse).
Thanks a lot guys!

Reported by sebastien.degardin on 2007-11-07 12:33:19

[dankurka]

Kelly.. this is working great!!  Thanks for turning this around!!

Reported by codethought on 2007-11-07 15:48:17

[dankurka]

Created change branch to hold the changes associated with the test build:
changes/knorton/leopard-1.4

Reported by gwt.team.knorton on 2007-11-07 18:34:54