(No comment was entered for this change.)

This is pretty obscure, so I'm not sure it will help, but:  I've been running into
this bug lately and I've noticed that (at least in one case), I can make it stop by
moving some code into the constructor.

For instance:
public class Foo extends FlexTable {
  MyPanel a = new MyPanel();

  Foo() {
    ...
    add(a);
    ...
  }
}

will cause it to crash.  But if I change the code to the following:

public class Foo extends FlexTable {
  MyPanel a;

  Foo() {
    ...
    a = new MyPanel();
    add(a);
    ...
  }
}

... everything works.  Why this is I have no idea.  Posting on the off chance that
someone will be able to divine meaning from this.

John Lablanca has provided a project which consistently crashes here, so hopefully it
will be easy to track down now.

(No comment was entered for this change.)

Sigh, unable to reproduce jlablanca's crash on my machine.  After his meeting, we are
going to look into what is different between our machines.  Failing that, I will just
try and debug it running on his machine, assuming it still crashes reliably.

same bug found also with Google Web Toolkit 1.3.3, but conditions are very obscure...

Christophe Macabiau
http://tellmewhere.com/

jlablanca can no longer reproduce the crash, so given the rarity of the crash (at
least in setups I have been able to duplicate), it is unlikely anything will be done
for it for 1.4RC2.  I have seen this particular crash exactly once in thousands of
tests, so it simply isn't productive to try and track it down when we will soon be
rewriting all of hosted mode anyway.

If anyone has sample code that can reproduce the crash on the order of 1 in 10 tries
or more frequently, please post it here complete with all the details of your
environment.  Otherwise, this will remain closed as not reproduceable.

Ok - for what it's worth, I can reproduce this crash semi-regularly.

Details of my environment are the same as they were for  issue 1105 :
Fedora Core release 6 (Zod)

[pelkey@pelkey etc]$ uname -a
Linux pelkey.cos.cassatt.com 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 10:42:48 EDT 2007
i686 i686 i386 GNU/Linux

[pelkey@pelkey etc]$ java -version
java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
Java HotSpot(TM) Client VM (build 1.5.0_09-b01, mixed mode)

I am going to attach a tar file of the prototype project we have that I see this in
fairly regularly - at least 1 in every 10 tries - probably more like 1 in 4 or less. 
There are several hs_err_pid*.log files in there as well.

The project contains a Tree in the WEST panel of a DockPanel that is updated
regularly.  TreeItems are added/deleted/updated based on updates from an RPC call. 
Note that this RPC call is a stub that randomly generates the updates right now, so
the order of adds/deletes/updates is different every time.  It takes anywhere from
maybe 3+ minutes for it to happen, to upwards of 20-30 minutes, but it does
eventually almost always happen.  Sorry for the randomness part of it - not real
great from a debugging standpoint, I realize...

Since there is no ability to add an item in a certain position on the current
Tree/TreeItem implementation, I am following a suggestion from the forum and removing
all the items and re-adding them when I add a new item  (gross - but the best
workaround I had for now).  Anyway - it looks like most, if not all, of the eventual
segv's are happening in the guts of those adds/deletes.

BTW - since I needed to get past  issue 1105 , I am building the version of GWT I am
running with from subversion.  I updated that as of this morning (7/11/07) and am
running with that - NOT with 1.4RC1.  Am also using GWTx-20070605.jar for the
property change support.  I did trim out a bunch of other unrelated cruft - hopefully
it's manageable enough now for your purposes.

issue1281.tar.gz 467 KB   Download

jopelkey: could you try applying the patch in  issue 1358  and seeing if this fixes the
problem?  You'll need to run the Makefile in the jni/linux directory to build a new
.so file and copy it over your existing .so file.

I ran into some issues with memory corruption that gwt.team.jat fixed and it's
possible that it might have been related to this problem.

Presuming I did everything correctly with the patch from  issue 1358 , I did just
manage to still reproduce this.  I'm guessing I got the patch in correctly since I
now have a gwt-ll.log file I haven't seen before...

I just managed to get the same crash with that patch as well.

I think that it might have something to do with running low on memory.  I find that
it's usually when GWT's hosted mode is getting slow and needs to be restarted that
this crash happens.  Perhaps a Java object is getting GC'd at an inopportune moment,
or something is failing to allocate?  I did do some System.gc() testing before that
didn't turn anything up, however.

I now have an Google-internal application which reliably reproduces the problem, so
hopefully I can track down the root cause.

I believe the problem is that currently we store the JavaScript execution context
with the jsval, and use that when we need to interact with the JSVM regarding that
value.  In the crashes I can reproduce, it happens from an event handler using a new
JS context different from the one stored in the value, and just after a bunch of
values were cleaned up under the old context.  So, I think the old context is not
valid any more, and the crash occurs when trying to use the old context.

I have modified the implementation to maintain a stack of JS contexts like the Safari
implementation, and whenever the native code needs to interact with the JSVM it uses
the top context on the stack.  I am running a bunch of tests on it over the weekend,
but I am hopeful that this will fix the problem.

I believe I have a solution for this -- it is undergoing final testing now and should
be submitted for review today.  There were two basic problems:
 1) as mentioned above, we were keeping the JSContext with the value and it seemed
like perhaps there are cases where it is no longer valid at the time it is used.
 2) inside _setWrappedObject and _setWrappedFunction, we allocated new objects but
didn't root them immediately, so they were subject to GC after further calls into the
JSVM.
With these changes, the repro case I was given no longer fails, and I am running the
full tests to make sure it didn't break anything else.

Submitted for review by scottb.

Committed as r1268.

1.4 RC2 now released.