Created attachment 323822 [details] firefox stdout/stderr for a crash Description of problem: The ACM has a bunch of online courses. These use a combination of java/flash, but don't work with IcedTeaPlugin Note that you need ACM membership to log in, but thats hopefully common enough to be OK. Version-Release number of selected component (if applicable): F10 to-be java-1.6.0-openjdk-1.6.0.0-4.b12.fc10.x86_64 How reproducible: Most of the time Steps to Reproduce: 1. Go to http://pd.acm.org/skillsoft.cfm 2. Log in with an ACM username/password 3. Pick one of the courses (I'm using some of the Cisco ones) 4. Press play Actual results: About 40% of the time, the browser crashes. It doesn't do it under a debugger, but I'll attach java.stderr and stdout/stderr from firefox in case that helps About 30% of the time it loads, but rather than filling the whole window the content fills the middle third. When then happens the right part of the visible area is cropped, so I can't click on the 'next' button to see if it gets any further. The rest of the time it works up until it gets to a stage where you have to pick an option to answer a question. Whats meant to happen is that a 'done' button appears in the HTML section of the window, but it doesn't. Not sure if this is flash or java, though. Expected results: Works Additional info: I've only tried this with the nspluginwrapper 32 bit flash, not the newly-released 64-bit version.
Created attachment 323823 [details] java.stderr Those two logs were created with ICEDTEAPLUGIN_DEBUG=1 set.
Created attachment 323824 [details] Screenshot of cropped image Note that it takes ages to load for some reason; if you get a blank screen or the loading splash page then wait 30-40 seconds for it to keep going. It does this on windows, too. I guess this one may be a firefox bug not java. firefox-3.0.4-1.fc10.x86_64 if that matters.
I hate to have to ask you this, but can you run firefox from gdb and attach the backtrace of the segfault? I went through the logs, and unfortunately they do not indicate what the problem is. From the looks of it, the plugin is doing everything right, making a request to mozilla code, and then something goes wrong. A trace would help me track what variable is causing the issue and work from there. To get a trace, start firefox from a terminal with firefox -g , visit the site till it crashes, and then type "bt" and hit enter on the console (gdb shell) from where firefox was started.
I tried, but it doesn't seem to crash under -g (race condition that ptrace slows down enough to not trigger?). Let me see if I can get it to dump a useful core file.
Ah, so it is intermittent... when running under gdb, you said it doesn't crash -- does the applet function correctly in that case then?
Created attachment 323963 [details] Backtrace No, it ends up cropped, like in the screenshot. (Actually, it displays correctly for an instant before it crops itself) It crashed first time without -g - heres the full backtrace from the core dump.
Thanks! The trace certainly helps. Looking at that and the logs, this does appear to be due to the use of the 32-bit plugin via plugin wrapper. The plugin uses variable length unsigned int for memory mapping and it seems to be set to 32 in this case, while mozilla is providing it 64-bit addresses. The plugin is using a variable length unsigned int data type which is expected to be provided by the mozilla runtime, but I guess the wrapper it not what decides its type. It should be possible to force it to use 64-bit unsigned int on all systems, but before that, can you try it with the native 64-bit and confirm that it doesn't crash? Once that is confirmed, we'll proceed to the cropping issue.
That was with the native 64-bit flash plugin and x86_64 java (and I don't see flash in the backtrace; not sure if it even got that far). The only thing nspluginwrapper is now wrapping (according to about:plugins) is realplayer.
Doh! I was so sure that was the issue. Okay, then can you please also attach the console log and java.stderr (ICEDTEAPLUGIN_DEBUG=1) from a 64-bit run/crash?
Oh, and: (gdb) frame 3 #3 nsCLiveconnect::GetMember (this=0x7f475c50e100, jEnv=0x7f475c80e440, obj=1550535904, name=0x7f475c6b4650, length=8, principalsArray=0x0, numPrincipals=0, securitySupports=0x0, pjobj=0x7fff767ff2a8) at nsCLiveconnect.cpp:261 261 JSObject *js_obj = handle->js_obj; (gdb) p handle No symbol "handle" in current context. (gdb) l 256 return NS_ERROR_FAILURE; 257 } 258 259 JSJavaThreadState *jsj_env = NULL; 260 JSObjectHandle *handle = (JSObjectHandle*)obj; 261 JSObject *js_obj = handle->js_obj; 262 JSContext *cx = NULL; 263 jobject member = NULL; 264 jsval js_val; 265 int dummy_cost = 0; (gdb) p obj $1 = 1550535904 (gdb) p (JSObjectHandle*)obj; Invalid character ';' in expression. (gdb) p (JSObjectHandle*)obj $2 = (JSObjectHandle *) 0x5c6b4ce0 (gdb) p *(JSObjectHandle*)obj Cannot access memory at address 0x5c6b4ce0 (gdb) Something not rooted right for the JS GC, possibly?
Created attachment 323971 [details] firefox stdout/stderr for a crash (64-bit flash) Attached, but the only difference is 64-bit flash vs nspluginwrapper'd 32-bit flash, and this is all crashing in the java side of things.
Created attachment 323972 [details] java.stderr (64-bit flash)
Also see https://bugzilla.mozilla.org/show_bug.cgi?id=463836 - the stacktrace is slightly different, but the symptoms are the same - callback from icedtea back through liveconnect, only happens sometimes, never under gdb, and it ends up with handle being invalid. Plus that one has a public test case.
Thanks again. I see this in the log: Calling GETMEMBER: -1657059744, 8 That is a bad sign. That is an integer overflow that shouldn't happen. Okay, let's verify first that things are correct. Can you post the output of the following: rpm -q java-1.6.0-openjdk-plugin readlink -f /usr/lib64/mozilla/plugins/*java* readlink -f ~/.mozilla/plugins/*java*
[bbaetz@plum ~]$ rpm -q java-1.6.0-openjdk-plugin java-1.6.0-openjdk-plugin-1.6.0.0-4.b12.fc10.x86_64 [bbaetz@plum ~]$ readlink -f /usr/lib64/mozilla/plugins/*java* /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so [bbaetz@plum ~]$ readlink -f ~/.mozilla/plugins/*java* [bbaetz@plum ~]$
Hmm, one last command: rpm -qfV /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so This is very odd. Looks like everything so far is as it should be, in which case there should never be an overflow.
[bbaetz@plum ~]$ rpm -qfV /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so [bbaetz@plum ~]$ I don't have a 32-bit setup here to see if its a 64-bit specific issue.
Still dies with java-1.6.0-openjdk-1.6.0.0-5.b12.fc10.x86_64. End of firefox stdout is: Received message: instance 0 ToString -1616104432 PIPE: plugin read: instance 0 ToString -1616104432 ICEDTEA PLUGIN: Instance::ConsumeMsgFromJVM received message: instance 0 ToString -1616104432 POSTING ToString parse javascript id -1616104432 POSTING ToString DONE Processing complete ICEDTEA PLUGIN: Instance::ConsumeMsgFromJVM return ICEDTEA PLUGIN: plugin_in_pipe_callback return Calling ToString: -1616104432 /usr/lib64/firefox-3.0.4/run-mozilla.sh: line 131: 25999 Segmentation fault "$prog" ${1+"$@"} I'll attach the full logs.
Created attachment 324432 [details] firefox stdout/stderr
Created attachment 324433 [details] java.stderr
Yeah, .5 release fixes only part of the problem... I realized that only after the build was underway. I have the other part of the fix ready -- just waiting for commit access to cvs so I can commit and build. The .6 release should fix this bug. I'll add a note to the bug when it is ready.
Okay, .6 is built. Can you please give it a try? http://koji.fedoraproject.org/koji/taskinfo?taskID=948263
I tried it three times. Once it seemed to work without problems, and once I got the cropped image, and once I got the java applet bringing up a window complaining about a NullPointerException (with no stacktrace, pointing me at skillsoft support). Can't repro that, and I didn't have logging on for that run. I also got http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=263 a few times.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
this should be in rawhide within the next couple of days: http://koji.fedoraproject.org/koji/taskinfo?taskID=1098935