| Summary: | konqueror crashes when uploading attachements into webmail | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Marcel Högl <mh> |
| Component: | general | Assignee: | Konqueror Bugs <konqueror-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | andresbajotierra, kdelibs-bugs-null, maksim, mh |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Marcel Högl
2010-02-19 22:22:22 UTC
Looks like some kind of problem with the FileDialog or the Qt library. - Could you try this on other websites containing an upload field? It could be useful to have a complete backtrace (if you could at least recompile kdelibs with debuginformation enabled) Regards seems like the error is combined with felamimail in egroupware, works in firefox and the upload thing in konqueror works with other websites, can't find another one causing the same problem, tried four. I'm just upgrading to kde sc 4.4.1 and will try again konqueror 4.4.1 doesn't change the situation, but we've found some trouble with a java-script function in felamimail/egroupware:
extract from relevant js file:
...
function fm_compose_addFile() {
document.getElementById('statusMessage').innerHTML = 'Sending file to server ...';
document.getElementById('fileSelectorDIV1').style.display = 'none'; //konqueror crashes here! It's not at form.submit()!
document.getElementById('fileSelectorDIV2').style.display = 'inline';
document.fileUploadForm.submit();
}
...
extract from relevant html site:
<div id="fileSelectorDIV1" style="height:80px; border:0px solid red; background-color:white; padding:0px; margin:0px;">
<script type="text/javascript" src="/egroupware/felamimail/js/jscode/composeMessage.js?1248272883"></script>
<form method="post" enctype="multipart/form-data" name="fileUploadForm" action="/egroupware/index.php?menuaction=felamimail.uicompose.fileSelector&composeid=1fe788a3797bd75325d6e391f4b123d0">
<table style="width:99%;">
<tr>
<td style="text-align:center;">
<span id="statusMessage"> </span>
</td>
</tr>
<tr>
<td style="text-align:center;">
<input id="addFileName" name="addFileName" size="50" style="width:450px;" type="file" onchange="fm_compose_addFile()"/>
</td>
</tr>
<tr>
<td style="text-align:center;">
maximal DateigröÃe: 32M
</td>
</tr>
</table>
</form>
<div id="fileSelectorDIV2" style="position:absolute; display:none; heigh
add to former comment:
//konqueror crashes here! It's not at form.submit()!
means the line above itself, which says:
document.getElementById('fileSelectorDIV1').style.display = 'none';
That line is likely destroying the file selector widget; and presumably that happens while onchange is being dispatched. Can probably be fixed by a ref/deref pair in RenderFileButton::handleFocusOut, though I would really prefer to know exactly what's happening. If you have a nice and fast machine, it would be appreciated if you could get a valgrind trace of this bug as described here: http://techbase.kde.org/Contribute/Bugsquad/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_Valgrind but also passing in --num-callers=50 to valgrind. #valgrind --num-callers=50 --log-file=/home/macl/projects/konqueror konqueror quits with "Illegal instruction" creating following log-file: ==11243== Memcheck, a memory error detector ==11243== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==11243== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==11243== Command: konqueror ==11243== Parent PID: 6413 ==11243== vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xFF 0xB0 ==11243== valgrind: Unrecognised instruction at address 0xbbe332a. ==11243== Your program just tried to execute an instruction that Valgrind ==11243== did not recognise. There are two possible reasons for this. ==11243== 1. Your program has a bug and erroneously jumped to a non-code ==11243== location. If you are running Memcheck and you just saw a ==11243== warning about a bad jump, it's probably your program's fault. ==11243== 2. The instruction is legitimate but Valgrind doesn't handle it, ==11243== i.e. it's Valgrind's fault. If you think this is the case or ==11243== you are not sure, please let us know and we'll try to fix it. ==11243== Either way, Valgrind will now raise a SIGILL signal which will ==11243== probably kill your program. ==11243== ==11243== Process terminating with default action of signal 4 (SIGILL) ==11243== Illegal opcode at address 0xBBE332A ==11243== at 0xBBE332A: ??? (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBE33E4: ??? (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBE4482: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBA17DC: g_array_sized_new (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBEF988: g_static_private_set (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBAF2CA: g_get_filename_charsets (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBAF34D: ??? (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBEFBF9: g_thread_init_glib (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0x7344C2E: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /usr/lib64/qt4/libQtCore.so.4.6.2) ==11243== by 0x7D2EA6E: ??? (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x7D2EB5E: ??? (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x7CF9130: QApplicationPrivate::createEventDispatcher() (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x731D9B9: QCoreApplication::init() (in /usr/lib64/qt4/libQtCore.so.4.6.2) ==11243== by 0x731DAA4: QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (in /usr/lib64/qt4/libQtCore.so.4.6.2) ==11243== by 0x7C88EA8: QApplication::QApplication(int&, char**, bool, int) (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x6698676: KApplication::KApplication(bool) (in /usr/lib64/libkdeui.so.5.4.0) ==11243== by 0x4E67A79: KonquerorApplication::KonquerorApplication() (in /usr/lib64/libkdeinit4_konqueror.so) ==11243== by 0x4EF08B4: kdemain (in /usr/lib64/libkdeinit4_konqueror.so) ==11243== by 0xA0B7BBC: (below main) (in /lib64/libc-2.11.so) ==11243== ==11243== HEAP SUMMARY: ==11243== in use at exit: 99,764 bytes in 970 blocks ==11243== total heap usage: 1,416 allocs, 446 frees, 126,148 bytes allocated ==11243== ==11243== LEAK SUMMARY: ==11243== definitely lost: 0 bytes in 0 blocks ==11243== indirectly lost: 0 bytes in 0 blocks ==11243== possibly lost: 11,734 bytes in 230 blocks ==11243== still reachable: 88,030 bytes in 740 blocks ==11243== suppressed: 0 bytes in 0 blocks ==11243== Rerun with --leak-check=full to see details of leaked memory ==11243== ==11243== For counts of detected and suppressed errors, rerun with: -v ==11243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) ####################################### do I have to rebuild all corresponding packages with debug-features enabled, for now it's just glibc, kdelibs and konqueror # valgrind -v --num-callers=50 --leak-check=full --log-file=/home/macl/projects/konqueror konqueror gives pretty much questionmarks #valgrind --num-callers=50 --log-file=/home/macl/projects/konqueror konqueror quits with "Illegal instruction" creating following log-file: ==11243== Memcheck, a memory error detector ==11243== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==11243== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==11243== Command: konqueror ==11243== Parent PID: 6413 ==11243== vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xFF 0xB0 ==11243== valgrind: Unrecognised instruction at address 0xbbe332a. ==11243== Your program just tried to execute an instruction that Valgrind ==11243== did not recognise. There are two possible reasons for this. ==11243== 1. Your program has a bug and erroneously jumped to a non-code ==11243== location. If you are running Memcheck and you just saw a ==11243== warning about a bad jump, it's probably your program's fault. ==11243== 2. The instruction is legitimate but Valgrind doesn't handle it, ==11243== i.e. it's Valgrind's fault. If you think this is the case or ==11243== you are not sure, please let us know and we'll try to fix it. ==11243== Either way, Valgrind will now raise a SIGILL signal which will ==11243== probably kill your program. ==11243== ==11243== Process terminating with default action of signal 4 (SIGILL) ==11243== Illegal opcode at address 0xBBE332A ==11243== at 0xBBE332A: ??? (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBE33E4: ??? (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBE4482: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBA17DC: g_array_sized_new (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBEF988: g_static_private_set (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBAF2CA: g_get_filename_charsets (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBAF34D: ??? (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0xBBEFBF9: g_thread_init_glib (in /usr/lib64/libglib-2.0.so.0.2200.4) ==11243== by 0x7344C2E: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (in /usr/lib64/qt4/libQtCore.so.4.6.2) ==11243== by 0x7D2EA6E: ??? (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x7D2EB5E: ??? (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x7CF9130: QApplicationPrivate::createEventDispatcher() (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x731D9B9: QCoreApplication::init() (in /usr/lib64/qt4/libQtCore.so.4.6.2) ==11243== by 0x731DAA4: QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (in /usr/lib64/qt4/libQtCore.so.4.6.2) ==11243== by 0x7C88EA8: QApplication::QApplication(int&, char**, bool, int) (in /usr/lib64/qt4/libQtGui.so.4.6.2) ==11243== by 0x6698676: KApplication::KApplication(bool) (in /usr/lib64/libkdeui.so.5.4.0) ==11243== by 0x4E67A79: KonquerorApplication::KonquerorApplication() (in /usr/lib64/libkdeinit4_konqueror.so) ==11243== by 0x4EF08B4: kdemain (in /usr/lib64/libkdeinit4_konqueror.so) ==11243== by 0xA0B7BBC: (below main) (in /lib64/libc-2.11.so) ==11243== ==11243== HEAP SUMMARY: ==11243== in use at exit: 99,764 bytes in 970 blocks ==11243== total heap usage: 1,416 allocs, 446 frees, 126,148 bytes allocated ==11243== ==11243== LEAK SUMMARY: ==11243== definitely lost: 0 bytes in 0 blocks ==11243== indirectly lost: 0 bytes in 0 blocks ==11243== possibly lost: 11,734 bytes in 230 blocks ==11243== still reachable: 88,030 bytes in 740 blocks ==11243== suppressed: 0 bytes in 0 blocks ==11243== Rerun with --leak-check=full to see details of leaked memory ==11243== ==11243== For counts of detected and suppressed errors, rerun with: -v ==11243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) ####################################### do I have to rebuild all corresponding packages with debug-features enabled, for now it's just glibc, kdelibs and konqueror # valgrind -v --num-callers=50 --leak-check=full --log-file=/home/macl/projects/konqueror konqueror gives pretty much questionmarks please del comment #7, is identical to #6 and was my fault, sorry Looks like a valgrind bug: https://bugs.kde.org/show_bug.cgi?id=180217 Will probably be easiest to give you a patch to try, but my tree is currently a mess (in the middle of integrating some stuff...) works now with konqueror-4.4.2 |