Bug 554021 - hang in ne_sock_close -> gnutls_bye
Summary: hang in ne_sock_close -> gnutls_bye
Alias: None
Product: Fedora
Classification: Fedora
Component: neon
Version: 12
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
Whiteboard: abrt_hash:b72ecd6db2ddebb1dd712d328f3...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-01-10 01:40 UTC by Tyler Gillispie
Modified: 2010-02-02 01:16 UTC (History)
3 users (show)

Fixed In Version: 0.29.3-1.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-02-02 01:16:27 UTC

Attachments (Terms of Use)
File: backtrace (55.79 KB, text/plain)
2010-01-10 01:40 UTC, Tyler Gillispie
no flags Details
standalone demo (670 bytes, text/x-c)
2010-01-11 10:01 UTC, Caolan McNamara
no flags Details
neon patch that makes it go away (526 bytes, patch)
2010-01-11 10:04 UTC, Caolan McNamara
no flags Details | Diff

Description Tyler Gillispie 2010-01-10 01:40:57 UTC
abrt 1.0.3 detected a crash.

How to reproduce
1.Open Calc
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
component: openoffice.org
executable: /usr/lib64/openoffice.org3/program/scalc.bin
package: openoffice.org-calc-1:3.1.1-19.14.fc12
rating: 4
reason: Process was terminated by signal 11 (Segmentation fault)

Comment 1 Tyler Gillispie 2010-01-10 01:40:59 UTC
Created attachment 382738 [details]
File: backtrace

Comment 2 David Tardon 2010-01-10 07:44:22 UTC
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?

Comment 3 Tyler Gillispie 2010-01-10 08:14:12 UTC
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.

Comment 4 David Tardon 2010-01-10 08:36:44 UTC
dtardon->mrteye: You can send saved web page to me by email. As a Red Hat employee I'm expected to keep it confidential.

Comment 5 Tyler Gillispie 2010-01-10 08:59:41 UTC
Page: https://www.chaseidprotection.com/credit-reports.aspx

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.

Comment 6 Caolan McNamara 2010-01-11 09:25:34 UTC
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.

Comment 7 David Tardon 2010-01-11 09:27:39 UTC
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.

Comment 8 Caolan McNamara 2010-01-11 10:01:12 UTC
Created attachment 382944 [details]
standalone demo

standalone demo

Comment 9 Caolan McNamara 2010-01-11 10:04:17 UTC
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 ?

Comment 10 Joe Orton 2010-01-11 10:53:38 UTC
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.

Comment 11 Joe Orton 2010-01-11 21:02:01 UTC
Please confirm this build works for you:


Comment 12 Caolan McNamara 2010-01-12 08:44:23 UTC
Yup, that one doesn't hang.

Comment 13 Tyler Gillispie 2010-01-12 14:56:16 UTC
(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?

Comment 14 David Tardon 2010-01-12 16:30:32 UTC
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.

Comment 15 Tyler Gillispie 2010-01-13 07:12:46 UTC
(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!

Comment 16 David Tardon 2010-01-13 07:36:25 UTC
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 :)

Comment 17 Fedora Update System 2010-01-14 01:19:30 UTC
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

Comment 18 Fedora Update System 2010-02-02 01:16:21 UTC
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.

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