Other notes - using SVN version from a few days ago, but was working fine until
something in the code (unsure what) was added today.

Could be a large string getting converted somewhere based on the symbol "mbsnrtowcs"
in the stack

Can you save off a project in the state that repros the issue and perhaps send it to us?

Unfortunately, I won't be able to save a project unless I can reproduce with a
different bit of code.

I can try to debug it a bit if I can figure out how to compile the JNI code and
enable tracing (it fails right now with a C/C++ linkage error):

  g++ -c -ggdb -m32 -Os -fPIC -fno-omit-frame-pointer -fno-strict-aliasing
-D_REENTRANT -MMD -MP -Wno-system-headers  -I ../../build/out/jni/linux/ -isystem
/usr/java/jdk1.6.0_01//include -isystem /usr/java/jdk1.6.0_01//include/linux -isystem
../../../tools/sdk/mozilla-1.7.13/include -isystem
../../../tools/sdk/mozilla-1.7.13/include/extra -o
../../build/out/jni/linux/NativeWrapper.o NativeWrapper.cpp
gwt-jni.h:27: error: previous declaration of ‘JSClass gwt_nativewrapper_class’ with
‘C++’ linkage
NativeWrapper.cpp:82: error: conflicts with new declaration with ‘C’ linkage
gwt-jni.h:28: error: previous declaration of ‘JSClass gwt_functionwrapper_class’ with
‘C++’ linkage
NativeWrapper.cpp:90: error: conflicts with new declaration with ‘C’ linkage
make: *** [../../build/out/jni/linux/NativeWrapper.o] Error 1

OK - I got it compiled.  I'll post more info here as I get it.

Interesting:

Looks like it might be a really large XMLHTTPRequest returnvalue:

 ENTER LowLevelMoz._invoke
 
method=@com.google.gwt.http.client.XMLHTTPRequest::getResponseText(Lcom/google/gwt/core/client/JavaScriptObject;),
jsthis=0a32e2f0, #args=1
  jsThis=object @ 0a049a50, class Window
  arg[0]=object @ 0a01edb8, class XMLHttpRequest
An irrecoverable stack overflow has occurred.

Yeah..  that's the problem.

PrintJSValue is using a stack buffer for strings.  

I #if'd out the function and that fixes things:

Index: LowLevelMoz.cpp
===================================================================
--- LowLevelMoz.cpp     (revision 1223)
+++ LowLevelMoz.cpp     (working copy)
@@ -45,6 +45,7 @@
 jclass lowLevelMozClass;
 
 static void PrintJSValue(JSContext* cx, jsval val, char* prefix="") {
+#if 0
   JSType type = JS_TypeOfValue(cx, val);
   const char* typeString=JS_GetTypeName(cx, type);
   char buf[256];
@@ -83,9 +84,9 @@
     }
   }
   Tracer::log("%s", buf);
+#endif
 }
 
-
 static bool InitGlobals(JNIEnv* env, jclass llClass) {
   if (savedJNIEnv)
     return false;

I am not sure why the stack buffer in PrintJSValue would be an issue, as snprintf is
used with the remaining space in the buffer.

However, I can't find any place where a multi-byte string (presumably UTF8) would be
converted to wchar_t and the stack trace is useless as it doesn't show anything above
the call.  So, I am not sure what might be doing something that calls mbsnrtowcs
under the hood.

Looking over this code, I found two possible problems:
 1. snprintf doesn't seem to document whether the output string is null terminated if
the count is exhausted.  It implies it, by saying the count includes the null
terminator, but it doesn't come out and say specifically.  So, I modified
PrintJSValue to always make sure it is null terminated before calling Tracer::log().
 2. The JNI function GetStringChars isn't guaranteed to null-terminate the
UTF16-encoded output, and we were using JS_NewStringUCZ which expects it to be null
terminated.  I added another JsRootedValue setString method which takes a length, and
modified JsValueMoz::_setString to use it.

While I was there, I also conditionalized PrintJSValue on one of the trace flags
being defined, as it doesn't need to do the work it does if nothing is being traced.

Could you please test the attached patch and see if that fixes your problem, even
with tracing enabled?

Also, could you describe the patches you had to make to get around the C++ linkage
error?  If I that change doesn't break other platforms I would be happy to include it.

	native-string.patch
	3.7 KB Download

If it matters, my LANG is set to en_US.utf8.  I can't see any place where the
function was even called either, but it was a stack overflow and the stack might have
been corrupted beyond what the stack display could parse. 

#ifdef'ing out PrintJSValue should help performance a bit across the JS<->Java bridge.

The extern patch is pretty simple - just extern "C"'d around any extern usage of the
JSClass objects:

Index: gwt-jni.h
===================================================================
--- gwt-jni.h   (revision 1223)
+++ gwt-jni.h   (working copy)
@@ -23,9 +23,12 @@
 extern JNIEnv* savedJNIEnv;
 extern jclass lowLevelMozClass;
 
+
 // JavaScript class objects
+extern "C" {
 extern JSClass gwt_nativewrapper_class;
 extern JSClass gwt_functionwrapper_class;
+}
 
 extern jobject NewJsValueMoz(JSContext* context);
 extern jobject NewJsValueMoz(JsRootedValue* js_rooted_value);
Index: JsRootedValue.h
===================================================================
--- JsRootedValue.h     (revision 1223)
+++ JsRootedValue.h     (working copy)
@@ -21,7 +21,9 @@
 
 #include "Tracer.h"
 
+extern "C" {
 extern JSClass gwt_nativewrapper_class;
+}
 
 /*
  * Holds a root for Javascript objects, so the JS interpreter knows not to

OK..  that still crashes for me.  It looks like the stack is being overwritten:

Stack: [0xb7e9f000,0xb7ef0000),  sp=0xb7eed618,  free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x90909091
J  com.google.gwt.dev.shell.moz.LowLevelMoz._invoke(ILjava/lang/String;I[II)Z
J  com.google.gwt.dev.shell.moz.LowLevelMoz.invoke(ILjava/lang/String;I[II)V

I'm running with JAVATRACE instead of FILETRACE.

	hs_err_pid3786.log
	46.1 KB Download

More info - it happens immediately after the PrintJSValue call that was causing
trouble for me before (a big return value).

Happens in FILETRACE and JAVATRACE.

Commenting out body of PrintJSValue fixes it.  Also, commenting out only the string
parts of PrintJSValue fixes it.

Perhaps this stack corruption could be causing the JS_SetReservedSlot crash?

It's possible that the contents of the string it is trying to read are causing it to
fail (this particular string contains a number of Unicode characters from a UTF-8
request).  If you'd like, mail me at matthew@mastracci.com and I can point you at a
private URL that you can request with the HTTPRequest object that causes the crash
100% reliably on my machine with tracing enabled.

It seems like this could be something important to fix, and hopefully will be easy to
reproduce.

Here is a new patch, which resolves the issue for me.  Please try it and see if it
fixes the problem for you as well.

	native-string.patch
	5.5 KB Download

Perfect..  builds fine after svn revert'ing (extern "C" fixes are good).  I tested
FILETRACE, JAVATRACE and no tracing.

Seems to be slightly faster with no tracing at all - hopefully a small performance
win.  :)

Patch sent to scottb for review.

(No comment was entered for this change.)

Committed as r1254.

1.4 RC2 now released.