abrt version: 2.0.0 comment: I was retesting bug 632795 which originated in F13 but hasn't been resolved. Essentially if you hit http://download.oracle.com/javase/tutorial/deployment/applet/getStarted.html with Midori, it crashes evertime. package: midori-0.3.3-1.fc15 cmdline: midori component: midori executable: /usr/bin/midori kernel: 2.6.38.1-6.fc15.i686.PAE reason: Process /usr/bin/midori was killed by signal 11 (SIGSEGV) architecture: i686 uid: 500 username: watzkej os_release: Fedora release 15 (Lovelock) time: 1301268911 Text file: event_log, 5332 bytes Text file: smaps, 192293 bytes Binary file: coredump, 194654208 bytes Text file: dsos, 29398 bytes Text file: maps, 33225 bytes
Created attachment 488058 [details] File: event_log
Created attachment 488059 [details] File: smaps
Created attachment 488060 [details] File: dsos
Created attachment 488061 [details] File: maps
I hope you aren't uploading the 194MB coredump. ;) can you provide: rpm -q webkitgtk java-1.6.0-openjdk-plugin also, are you using any other plugins? sun java?
I can duplicate this here with openjdk. The page loads and works fine without it... So, it seems like a java-1.6.0-openjdk-plugin-1.6.0.0-53.1.9.6.fc15.x86_64 issue. ;) Trying to get a backtrace out of the retrace server and can see if we can move over to that component for them to look at.
Okay, see if you can get a backtrace. I was going to replicate it on F14 so I could get a proper backtrace. Unfortunately, ABRT 2.0 is hosed up a little in F15 (which explains the above uploads) and the retrace server seems to be hosed up too.
Yeah, retrace failed here too. ;( Unexpected HTTP response from server: 413 HTTP/1.1 413 Request Entity Too Large :( If you can get a f14 trace that would be great.
ABRT should't allow user to create a bug report without backtrace, so this is a bug. Unexpected HTTP response from server: 413 HTTP/1.1 413 Request Entity Too Large - we will look into this and try tweak the limits if possible..
Retrace server's upload size limit has been increased from 50 to 100 MB. You can retry - I guess it should be enough.
Michael, the coredump file was reported to be 194654208 bytes so the limit needs to be a lot larger than that. If we can get a large enough upload limit then I can try to do a F15 trace through the retrace server.
Created attachment 488320 [details] F14 Backtrace This is a F14 backtrace. Hopefully it is the same condition that's affecting F15 but we won't know until we somehow get a F15 backtrace.
The coredump is compressed before uploading (together with other required files). The limit is now 100M for uploaded archive and 1G for unpacked archive content. If 100M is not enough for you, I can increase it, but I don't know if it's really useful. Most users probably don't want to upload more than 100M - I'd say even 50M is enough.
ok. I'm not sure if this is a webkit issue, or a openjdk one. Moving to openjdk first to see if they can track anything down with it...
(In reply to comment #13) When trying to upload debugging information to retrace01.fedoraproject.org, the operation gets closed before completion because the upload limit seems to have been exceeded. However, % du -hs ccpp-2011-04-12-23:53:57-2027/ 35M ccpp-2011-04-12-23:53:57-2027/ shows that only 35M would have been uploaded. The message is Certificate is signed by an untrusted issuer: 'E=mtoman,CN=retrace01.fedoraproject.org,OU=BaseOS,O=Red Hat,L=Brno,C=CZ'. Unexpected HTTP response from server: 413 HTTP/1.1 413 Request Entity Too Large Date: Wed, 13 Apr 2011 11:50:01 GMT Server: Apache/2.2.15 (Red Hat) Content-Length: 0 AppTime: D=215402110 AppServer: retrace01.fedoraproject.org Connection: close Content-Type: text/plain I have not found a related bug report, but I can open one if needed.
(In reply to comment #15) > (In reply to comment #13) > When trying to upload debugging information to retrace01.fedoraproject.org, the > operation gets closed before completion because the upload limit seems to have > been exceeded. However, > I think you have the wrong bug :)
(In reply to comment #14) > ok. I'm not sure if this is a webkit issue, or a openjdk one. > > Moving to openjdk first to see if they can track anything down with it... Thanks, this is indeed a Java plugin issue. The plugin allows the code in NP_Initialize to run only once. This works for other browsers, but Midori makes two NP_Initialize calls, and uses the function pointers set in the latter. Since NP_Initialize was returning immediately, all plugin functions pointed to 0x0, causing a SIGSEGV. I have proposed a patch upstream. Once it is in there, it should make it into Fedora shortly. http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013650.html
Er, and ignore my erroneous comment 16 please.
*** Bug 709967 has been marked as a duplicate of this bug. ***
(In reply to comment #19) Is this a bug in abrt? If the bug is a duplicate, it should have simply added me to the CC list instead of creating a new bug.
Sorry, I am not familiar enough with abrt to know. I have however seen it file duplicate bugs on occasion.
icedtea-web-1.0.3-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/icedtea-web-1.0.3-1.fc15
The build mentioned in comment #22 fixes this bug. Please give it a try and add karma as applicable. Thanks!
Update icedtea-web-1.0.3-1.fc15 fixes this issue. Accordingly, the component should be set to icedtea-web and not to java-1.6.0-openjdk.
Thanks for trying it! I have changed the component to icedtea-web. The bot will close this issue when the update is pushed to stable.
Package icedtea-web-1.0.3-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing icedtea-web-1.0.3-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/icedtea-web-1.0.3-1.fc15 then log in and leave karma (feedback).
icedtea-web-1.0.3-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.