Bug 471987 - Skillsoft viewer crashes/doesn't work
Skillsoft viewer crashes/doesn't work
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-11-17 20:27 EST by Bradley
Modified: 2009-02-02 10:34 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-02 10:34:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
firefox stdout/stderr for a crash (96.26 KB, text/plain)
2008-11-17 20:27 EST, Bradley
no flags Details
java.stderr (71.62 KB, text/plain)
2008-11-17 20:28 EST, Bradley
no flags Details
Screenshot of cropped image (145.32 KB, image/png)
2008-11-17 20:35 EST, Bradley
no flags Details
Backtrace (13.11 KB, text/plain)
2008-11-18 16:10 EST, Bradley
no flags Details
firefox stdout/stderr for a crash (64-bit flash) (96.33 KB, text/plain)
2008-11-18 17:08 EST, Bradley
no flags Details
java.stderr (64-bit flash) (71.58 KB, text/plain)
2008-11-18 17:09 EST, Bradley
no flags Details
firefox stdout/stderr (113.79 KB, text/plain)
2008-11-23 09:09 EST, Bradley
no flags Details
java.stderr (99.36 KB, text/plain)
2008-11-23 09:09 EST, Bradley
no flags Details

  None (edit)
Description Bradley 2008-11-17 20:27:31 EST
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

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:


Additional info:

I've only tried this with the nspluginwrapper 32 bit flash, not the newly-released 64-bit version.
Comment 1 Bradley 2008-11-17 20:28:30 EST
Created attachment 323823 [details]

Those two logs were created with ICEDTEAPLUGIN_DEBUG=1 set.
Comment 2 Bradley 2008-11-17 20:35:13 EST
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.
Comment 3 Deepak Bhole 2008-11-18 14:07:05 EST
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.
Comment 4 Bradley 2008-11-18 15:48:39 EST
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.
Comment 5 Deepak Bhole 2008-11-18 15:54:09 EST
Ah, so it is intermittent... when running under gdb, you said it doesn't crash -- does the applet function correctly in that case then?
Comment 6 Bradley 2008-11-18 16:10:08 EST
Created attachment 323963 [details]

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.
Comment 7 Deepak Bhole 2008-11-18 16:43:27 EST
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.
Comment 8 Bradley 2008-11-18 16:49:43 EST
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.
Comment 9 Deepak Bhole 2008-11-18 16:56:23 EST
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?
Comment 10 Bradley 2008-11-18 17:00:50 EST
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	    }
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

Something not rooted right for the JS GC, possibly?
Comment 11 Bradley 2008-11-18 17:08:27 EST
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.
Comment 12 Bradley 2008-11-18 17:09:10 EST
Created attachment 323972 [details]
java.stderr (64-bit flash)
Comment 13 Bradley 2008-11-18 17:23:35 EST
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.
Comment 14 Deepak Bhole 2008-11-18 17:44:37 EST
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*
Comment 15 Bradley 2008-11-18 18:44:28 EST
[bbaetz@plum ~]$ rpm -q java-1.6.0-openjdk-plugin
[bbaetz@plum ~]$ readlink -f /usr/lib64/mozilla/plugins/*java*
[bbaetz@plum ~]$ readlink -f ~/.mozilla/plugins/*java*
[bbaetz@plum ~]$
Comment 16 Deepak Bhole 2008-11-18 19:00:16 EST
Hmm, one last command:

rpm -qfV /usr/lib/jvm/java-1.6.0-openjdk-

This is very odd. Looks like everything so far is as it should be, in which case there should never be an overflow.
Comment 17 Bradley 2008-11-18 19:08:56 EST
[bbaetz@plum ~]$ rpm -qfV /usr/lib/jvm/java-1.6.0-openjdk-
[bbaetz@plum ~]$ 

I don't have a 32-bit setup here to see if its a 64-bit specific issue.
Comment 18 Bradley 2008-11-23 09:08:33 EST
Still dies with java-1.6.0-openjdk- 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
parse javascript id -1616104432
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.
Comment 19 Bradley 2008-11-23 09:09:11 EST
Created attachment 324432 [details]
firefox stdout/stderr
Comment 20 Bradley 2008-11-23 09:09:49 EST
Created attachment 324433 [details]
Comment 21 Deepak Bhole 2008-11-23 14:20:52 EST
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.
Comment 22 Deepak Bhole 2008-11-24 13:14:55 EST
Okay, .6 is built. Can you please give it a try? 

Comment 23 Bradley 2008-11-25 00:19:05 EST
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.
Comment 24 Bug Zapper 2008-11-26 00:32:52 EST
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:
Comment 25 Lillian Angel 2009-02-02 10:34:07 EST
this should be in rawhide within the next couple of days:

Note You need to log in before you can comment on or make changes to this bug.