Bug 1079810

Correction, old passfile is not necessary.  If any existing file is given for -passfile parameter, the crash occurs.

This makes it difficult to manage many e-mail accounts.  Can anyone help?

I can't reproduce this crash.   alpine works with both my old passfile, and any new (empty) one I create.

Can you let abrt produce a backtrace to upload?

You know, that's something else odd about this particulear crash.  ABRT didn't alert.  It alerts for other seg faults, though; I just forced one.

Can I make you a crash file manually, somehow?

alpine has its own segfault catching code. It should be disabled to these things to go abrtd and we get reports of crashers from our users.

oh icky.  definitely need to quash that.

(In reply to Paul Wouters from comment #5)
> alpine has its own segfault catching code. It should be disabled to these
> things to go abrtd and we get reports of crashers from our users.

Was this comment for me?  If so, I don't understand, sorry.

I know that I have used abrt to report Alpine bugs before.

I assume if I use gdb, I can make a backtrace for you, but I don't know if I can write a coredump file so you can inspect it.  Unless you know how I can override this internal catcher.

Wait, alpine used to report via ABRT; I remember doing it.  Here's one: bug 1039234 .

Also, I tested this on another computer with F20.  This was also an upgrade from F19, but the system has many fewer cusomizations.  The symptoms are the same there, it still crashes, but I noticed that it didn't crash immediately at the Main Menu because the local mailbox is still the INBOX.  I had to go to the Incoming Meassge Folder and that's when it crashed.

Created attachment 880210 [details]
core

I used gdb to produce a core file for you.  Here is the backtrace

Program received signal SIGSEGV, Segmentation fault.                                     
0x0000003c2768661a in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003c2768661a in strlen () from /lib64/libc.so.6
#1  0x0000003c2766c81f in fputs () from /lib64/libc.so.6
#2  0x000000000045ba3c in write_passfile ()
#3  0x000000000045bb8c in pine_delete_pwd ()
#4  0x0000000000620816 in imap_auth ()
#5  0x00000000006275cf in imap_open ()
#6  0x00000000005fe2ad in mail_open_work ()
#7  0x00000000005ffb42 in mail_open ()
#8  0x00000000005bb84b in pine_mail_open ()
#9  0x0000000000529c89 in context_open ()
#10 0x0000000000564ac9 in do_broach_folder ()
#11 0x0000000000409817 in main ()

I suppose I could install debuginfo first.  Let me know if that would be helpful.

Isn't there a way to mark a bug as sensitive or locked or something?  If someone could do that, I'd apreciate it.

backtrace is largely useless, please do:

debuginfo-install alpine

and try again.

(And why do you want this marked private?)

Yeah, I figured, but the core file isn't useless, right?

I suppose I didn't actually get to login to my account, so private isn't imporant.  I was just thinking that it has all my account passwords, but of course, this bug means it doesn't.

Okay, so I'm not sure how helpful this is, but I have a new backtrace.   Here is part of it:

#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x0000003c2766c81f in __GI__IO_fputs (str=0x0, fp=fp@entry=0xe2b8f0) at iofputs.c:35
#2  0x000000000045ba3c in write_passfile (pinerc=<optimized out>, l=0x0) at imap.c:2719
#3  0x000000000045bb8c in pine_delete_pwd (mb=<optimized out>, user=0x7fffffff8390 "")
    at imap.c:2121
#4  0x0000000000620816 in imap_auth (stream=stream@entry=0xd1e330, 
    mb=mb@entry=0x7fffffff7be0, 
    tmp=tmp@entry=0x7fffffff7f90 "00000000 AUTHENTICATE GSSAPI", 
    usr=usr@entry=0x7fffffff8390 "") at imap4r1.c:1159
#5  0x00000000006275cf in imap_open (stream=0xd1e330) at imap4r1.c:912
...

Is there any new information in the corefile now that I have debuginfos installed?  No, right?  So, you don't need a new core file.  Let me know if that will help.

(BTW, why isn't the core file backtrace the same as the one I get from the live debugger?)

I know you are in ernest, Rex.  But, I cannot get it to work.  I take it you are convinced this is not happening to anyone but me.  If so, please send suggestions.  I'm happy to troubleshoot.  It is highly reproducable.

I tried starting from scratch, again, and this time I added other IMAP servers first.  I didn't crash on them; only when I added my main IMAP server.  So, I tried many variations on the server spec I had been using, and they all result in SEGV.  However, if I authenticat with Kerberos, the problem is gone!

I noticed that Alpine doesn't seem to try Kerberos on any of the other servers, but it always tried Kerberose first for this particular server.  I just never use Kerb and haven't had any trouble using the passfile before now.

So, the revised procedure should be:

* do not authenticate with Kerberos RELM
* start alpine with new pinerc, not passfile
* add INBOX/Folder/Collection using server that accepts Kerberos AUTH
* give password
* read some mail and then quite alpine
* start alpine again with same rc, but now give a passfile
* goto the box or collection added previously
* SEGV

I hope this helps.

Okay, I have more information about this bug.  The problem also goes away if you disable GSSAPI authentication.  So, I think it's clear that there is a bug in the way alpine is using GSSAPI.

* start alpine with clean pinerc and with a new passfile
* M > S > C > add GSSAPI to "Disable These Authenticators"
* add server which accepts Kerberos AUTH
* authenticate via one of the other fallback mechanisms
* read your messages
* quit
* restart alpine with the passfile
* this should login you in automatically
* M > S > C > remove GSSAPI from "Disable These Authenticators"
* quit
* restart alpine with passfile
* crash

Will someone please look into this?

Dear Paul,

  Thank you for the backtrace, I see the problem now. There are two issues here. One is that redhat is distributing a modified version of Alpine (the function pine_delete_pwd is not in the distribution of Alpine) so you are running modified code. Having said that, the code crashes in a piece which is present in Alpine 2.11, so I will fix this bug in the code of version 2.11. Would you like me to send you a patch?

Thank you.

-- 
Eduardo

I'm not sure about your assertion of modified code, see
http://pkgs.fedoraproject.org/cgit/alpine.git/tree/
there are no modifications applied to fedora's packaging of the alpine-2.11 source.

Maybe Paul can tell us where he downloaded his version from. He came here for some reason. As I said before the function pine_delete_pwd is in his backtrace, but not in the source code of Alpine, so he is running modified code. If you look at the title for this thread, it contains the string  alpine-2.11-1.fc20.x86_64, so no wonder he is here asking for help. That's where my assertion of modified code comes from.

The next release of Alpine will protect against this crash, so even with modified code this will not happen.

I hope this makes sense.

-- 
Eduardo

To be clear, I'm using the "stock" Fedora alpine, i.e the most up-to-date 'alpine' package in Fedora 20.  I've never compiled Alpine, for myself.  I wasn't kidding when I said it was from package alpine-2.11-1.fc20.x86_64.  That's what I'm using.

Thank you very much for looking into it, Eduardo.  I know this is an atypical case.

This experience certainly had me considering compiling my own, though.  That's were this was headed, if you hadn't spotted the problem so fast.  Since I don't currently have source ready to build, right now, there is no need to send me a patch; but, thanks for the offer.

The most likely thing for me, now that the workaround I have is working, is that I will just wait, watch for the patch to make it's way downstream to my Fedora installation.  If I have a need for GSSAPI before then, I will compile my own.

I'm assuming the patch you offer will be posted on your web-site and/or a maintenance branch or something like that?  That way I'll just pick it up when I do go to download it.  If not, then yes, please send me a copy if it's not too much trouble.

Created attachment 889184 [details]
patch to avoid crash in alpine/imap.c

this patch will avoid the crash. There are other ways to fix this problem, but this one will stand the test of time. If the variable "text" happens to be null (which under normal conditions should not happen), then the code will not execute the part that makes Alpine crash and nothing will happen.

Apply this patch in the alpine-2.11/alpine directory of the source code.

Thanks, Eduardo!

Rex, unless there is something else I can do for you, could you please assign this bug.

I can also confirm that this problem is resolved by Alpine 2.20, just released.

I was able to remove GSSAPI from the disabled authenticators list and now my Alpine is trying Kerberos but doesn't crash.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.