[feisty] Firefox Crashed -libjavaplugin- [@JavaPluginFactory5::CreateSecureEnv]

Thanks for your bug report.

Taking for retrace.

I get the following traceback when trying to retrace this crash report. I have filed this bug before on apport see bug #92739 for more details. Im going to assign this to hjmf to see if he can retrace it but from the maintainer of apport its a bad coredump. Can you please send another crash report here if you can reproduce it, if not can you please try to obtain a backtrace by following the instructions at: https://wiki.ubuntu.com/MozillaTeam/Bugs. I would perfer a backtrace if you can grab one. I will talk to the apport maintainer about this to see how the coredump is getting corrupted.

Traceback (most recent call last):
  File "/usr/bin/apport-retrace", line 377, in <module>
    report = report_from_launchpad(reportfile)
  File "/usr/bin/apport-retrace", line 99, in report_from_launchpad
    report[key] = gzip.open(att.filename).read()
  File "/usr/lib/python2.5/gzip.py", line 220, in read
    self._read(readsize)
  File "/usr/lib/python2.5/gzip.py", line 292, in _read
    self._read_eof()
  File "/usr/lib/python2.5/gzip.py", line 309, in _read_eof
    isize = U32(read32(self.fileobj)) # may exceed 2GB
  File "/usr/lib/python2.5/gzip.py", line 40, in read32
    return struct.unpack("<l", input.read(4))[0]
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
    return o.unpack(s)
struct.error: unpack requires a string argument of length 4

~$ gunzip CoreDump.gz

gunzip: CoreDump.gz: unexpected end of file

This report cannot be retraced. For some reason the Coredump file got corrupted.

Sam, If you still have the crash report in /var/crash and if you are able to unpack that coredump[1] file w/o problems please upload the FULL crash report here.

[1] For example run:
~$ apport-unpack /var/crash/_usr_lib_firefox_firefox-bin.1000.crash some_tmp_dir/
~$ gunzip some_tmp_dir/CoreDump.gz

If no error arise, please upload again to https://launchpad.net/ubuntu/+source/firefox/+bug/94882/+addcomment the file _usr_lib_firefox_firefox-bin.1000.crash

Then we'll reopen this crash report. Rejected meanwhile.

I ran the apport-unpack command you suggested against the crash file create when firefox blew-up. I did not see a CoreDump.gz file. Instead I just saw an umpacked CoreDump file, which appeared to be intact.

I am taking the CoreDump file and running it through bzip2 to produce a smaller file then I'm uploading it as part of this message. Hopefully this will help. When the program trace was initially being uploaded it seemed to abort early, but there was no error window. Perhaps thats why the file wasn't complete...

Good Luck

Thank you Sam for uploading the coredump. Assigned to me for retrace.

... mmm I'm getting the same error with the coredump you have uploaded. I'm going to do some tests, but if you get another crash, please upload the new crash report.

(feisty_chroot)retraces@paleo:/home/bugsquad/retrace_tmp/f_94882# apport-retrace --core-file=CoreDump.gz --procmaps=ProcMaps.txt -s -v -u 94882 > retrace.out
Traceback (most recent call last):
  File "/usr/bin/apport-retrace", line 377, in <module>
    report = report_from_launchpad(reportfile)
  File "/usr/bin/apport-retrace", line 99, in report_from_launchpad
    report[key] = gzip.open(att.filename).read()
  File "/usr/lib/python2.5/gzip.py", line 220, in read
    self._read(readsize)
  File "/usr/lib/python2.5/gzip.py", line 292, in _read
    self._read_eof()
  File "/usr/lib/python2.5/gzip.py", line 309, in _read_eof
    isize = U32(read32(self.fileobj)) # may exceed 2GB
  File "/usr/lib/python2.5/gzip.py", line 40, in read32
    return struct.unpack("<l", input.read(4))[0]
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
    return o.unpack(s)
struct.error: unpack requires a string argument of length 4
Error in sys.excepthook:
Traceback (most recent call last):
  File "/var/lib/python-support/python2.5/apport/python_hook.py", line 54, in apport_excepthook
    pr.add_proc_info()
  File "/var/lib/python-support/python2.5/apport/report.py", line 294, in add_proc_info
    self['ExecutablePath'] = os.readlink('/proc/' + pid + '/exe')
OSError: [Errno 2] No such file or directory: '/proc/10349/exe'

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/apport-retrace", line 377, in <module>
    report = report_from_launchpad(reportfile)
  File "/usr/bin/apport-retrace", line 99, in report_from_launchpad
    report[key] = gzip.open(att.filename).read()
  File "/usr/lib/python2.5/gzip.py", line 220, in read
    self._read(readsize)
  File "/usr/lib/python2.5/gzip.py", line 292, in _read
    self._read_eof()
  File "/usr/lib/python2.5/gzip.py", line 309, in _read_eof
    isize = U32(read32(self.fileobj)) # may exceed 2GB
  File "/usr/lib/python2.5/gzip.py", line 40, in read32
    return struct.unpack("<l", input.read(4))[0]
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
    return o.unpack(s)
struct.error: unpack requires a string argument of length 4

I guess that apport is still using CoreDump.gz form launchpad instead of local coredump :/

attaching gdb output

...
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d924f1 in raise () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08057836 in nsProfileLock::FatalSignalHandler (signo=-1210478604) at nsProfileLock.cpp:206
#3 <signal handler called>
#4 0xb08e6427 in CNSAdapter_NSPR::JDFileDesc_To_FD ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/plugin/i386/ns7/libjavaplugin_oji.so
#5 0xb08ae383 in JavaPluginFactory5::CreateSecureEnv ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/libjavaplugin_nscp.so
#6 0xb08e2046 in CNSAdapter_JavaPluginFactory::CreateSecureEnv ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/plugin/i386/ns7/libjavaplugin_oji.so
#7 0xb5f780fd in ProxyJNIEnv (this=0xaac8e18, jvmPlugin=0xafc2a58, secureEnv=0x0) at ProxyJNI.cpp:1725
#8 0xb5f7819b in CreateProxyJNI (jvmPlugin=0xafc2a58, inSecureEnv=0x0) at ProxyJNI.cpp:1745
#9 0xb5f74d6f in JVM_GetJNIEnv () at jvmmgr.cpp:289
#10 0xb5f809c3 in create_java_vm_impl (jvm=0x82fcc74, initialEnv=0x82fcc78, initargs=0x0) at lcglue.cpp:343
#11 0xb5f5db21 in jsj_ConnectToJavaVM (jsjava_vm=0x82fcc70) at jsj.c:474
#12 0xb5f5e295 in JSJ_AttachCurrentThreadToJava (jsjava_vm=0x82fcc70, name=0x0, java_envp=0x0) at jsj.c:698
...

... stripped from above gdb log.

Let's do things rightly :)

Marking as dup of bug #86002