abrt 1.0.3 detected a crash.
How to reproduce
2.Copy Web Page (Credit Report) From Chase Identity Monitor
3.Pasted from Ctrl+v -OR- Edit Paste -OR- Right click paste
Comment: Everything freezes in Calc but the title bar which is enough to force it to quit. I installed the open office word processor while calc was in use, not sure if that made a difference.
Attached file: backtrace
cmdline: /usr/lib64/openoffice.org3/program/scalc.bin -calc
reason: Process was terminated by signal 11 (Segmentation fault)
Created attachment 382738 [details]
dtardon->mrteye: The crash has nothing whatever common with calc. It crashes on formatting a comment (note) inside a nested HTML table in writer. Are you sure the steps you have given us are correct? Could you perhaps try it again? Or give us the URL to that page, if possible?
The information is secured and sensitive. I was able to recreate the problem by copying a small table of the html page and pasting it into calc. When I tried this in writer with the same content (clipboard) it worked as expected.
I also copied another page into calc without any problems. If I find a good example I will post it here.
dtardon->mrteye: You can send saved web page to me by email. As a Red Hat employee I'm expected to keep it confidential.
Here is some culprit html:
<img src="https://b2b.pullcreditreports.com/resources/11.gif" width="535" height="30"></td></tr></tbody></table><br><table class="c1"><tbody><tr class="headerText hdrRight"><td class="i1"></td><td class="hdrUnderline" width="99" align="left">Account Type</td><td class="hdrUnderline" width="87">Count</td><td class="hdrUnderline" width="87">Balance</td><td class="hdrUnderline" width="87">Payments</td><td class="hdrUnderline" width="87">Open</td><td class="hdrUnderline" width="88">Closed</td><td class="hdrUnderline" width="120">Deferred/Unknown</td>
I was able to copy the html off the page and paste into calc to break it. Not quite sure what's happening here. Writer takes the same html correctly. It seems like some kind of https issue with images.
Well, I can't reproduce the crash, but the hang definitely. So lets take that one then. Tweaking neon to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR fixes that.
Ah ha. It's a _freeze_, not a _crash_. I must have overlooked or unconsciously ignored the comment in description.
dtardon->mrteye: Please, do not use abrt for reporting bugs unrelated to catched crashes.
Created attachment 382944 [details]
Created attachment 382945 [details]
neon patch that makes it go away
man gnutls_bye says...
GNUTLS_SHUT_RDWR actually sends an alert containing a close request and waits for
the peer to reply with the same message.
In case of GNUTLS_SHUT_WR then the TLS connection gets terminated and further sends will be disallowed. In order to reuse the connection
you should wait for an EOF from the peer. GNUTLS_SHUT_WR sends an alert containing a close request.
So I guess this particular server isn't replying to the close request so neon waits for it forever/long default timeout.
Does it make sense to instead have neon use GNUTLS_SHUT_WR to not wait for a reply on close ?
Thanks a lot Caolan!
I had a report of the same behaviour with OpenSSL last week. It seems some servers (IIS) ignore the close_notify alert sent by the client and just hang the connection, which is both weird and dumb. I'll release neon 0.29.3 with these changes soon and get updates shipped.
Please confirm this build works for you:
Yup, that one doesn't hang.
(In reply to comment #7)
> Ah ha. It's a _freeze_, not a _crash_. I must have overlooked or unconsciously
> ignored the comment in description.
> dtardon->mrteye: Please, do not use abrt for reporting bugs unrelated to
> catched crashes.
Don't use the Automatic Bug Reporting Tool to report bugs? I Why is that? It is an awfully handy tool and I probably would not have reported anything if it did not exist, I keep pretty busy you know. Perhaps there is a bug in abrt which reported a crash on top of a freeze?
dtardon->mrteye: No, there is no 'bug' in abrt, it works as designed. The original development name of that tool was CrashCatcher, i.e. its ability to catch application crashes was strongly emphasized. Then it was felt the name didn't quite cover its expected (and planned) usage, so it was changed to ABRT. But in its current state it's still a tool for handling _crashes_ only--any report from abrt is always related to some crash it has catched.
(In reply to comment #14)
> But in its current state it's still a tool for handling _crashes_ only--any
> report from abrt is always related to some crash it has catched.
It appears there was some kind of crash. The only crash I can imagine is when I right clicked on the title bar and closed the window. After which I had to click force quit. I don't believe this was a crash now that I think about it.
It looks like we found a solution to the problem though. Nice work all.
On a side note. If the information that is reported by abrt is not useful, I will stop using it out of concern for wasting valuable developer time. If there is another tool more useful that will handle the situation almost completely automatically as abrt did, let me know so I can use it. It is difficult to find time other wise.
This is my first bug report for Fedora. I have to admit it was a pretty fun process.
Avatar rocks btw...have a good night!
dtardon->mrteye: abrt _is_ useful, it's just its reporting ability that is limited currently. It's perfectly fine (and encouraged) to use it for reporting if you've encountered a crash of any application. It's not useable for reporting "standalone" problems, like freezes, wrong behaviour etc. Not yet, at least: according to main abrt developer this is planned, but I don't know details. Therefore, for now, I you encounter any problem that is not a crash and want to report it, you have to go to bugzilla.redhat.com and go through the "classical" bug reporting process...
Have a good night; I'll have to wait a while for it, as it's half past eight a.m. here :)
neon-0.29.3-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update neon'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0491
neon-0.29.3-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.