Bug 838359 - alpine crashes when suspending in password prompt mode
alpine crashes when suspending in password prompt mode
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: alpine (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Joshua Daniel Franklin
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-08 15:13 EDT by Paul Wouters
Modified: 2013-12-11 14:34 EST (History)
4 users (show)

See Also:
Fixed In Version: alpine-2.11-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-08 22:38:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
pinerc I use (stripped only from most folder names for privacy) (28.43 KB, text/plain)
2012-07-09 13:30 EDT, Paul Wouters
no flags Details
updated spec file (8.49 KB, text/x-rpm-spec)
2013-07-08 13:49 EDT, Paul Wouters
no flags Details
patch to fedora alpine repo to move to 2.10 and fix dates (3.39 KB, patch)
2013-07-08 14:12 EDT, Paul Wouters
no flags Details | Diff

  None (edit)
Description Paul Wouters 2012-07-08 15:13:26 EDT
Description of problem:
[paul@bofh ~]$ alpine

Alpine suspended. Give the "fg" command to come back.

[1]+  Stopped                 alpine
[paul@bofh ~]$ fg
alpine


Problem detected: "Received abort signal(sig=11)".
Alpine Exiting.


Unfortunately, alpine's buildin crash handler is preventing me from getting a core. Perhaps disable that detection as it does not provide anything useful? I also did not get .pine-debug* files.


Version-Release number of selected component (if applicable):
alpine-2.02-2.fc15.x86_64


How reproducible:
Always

Cause an IMAP / Kerberos  password prompt

Steps to Reproduce:
1. Cause an IMAP / Kerberos  password prompt
2. ctrl-z
3. fg
  
Actual results:
crash witout core

Expected results:
more email ;) and a core :)

Additional info:
Comment 1 Joshua Daniel Franklin 2012-07-09 09:37:13 EDT
Hmm, I cannot reproduce in Fedora 17. What TERM are you using and how are you connecting (i.e., I'm using ssh) and have "TERM=xterm-256color". Also I guess post your .pinerc (scrub username if you want) and what IMAP server you are using.

What I did:

rpm -q alpine
alpine-2.02-3.fc17.x86_64

In .pinerc I have Google Mail IMAP:
folder-collections="gmail" {imap.gmail.com:993/ssl/user=agmailaddr@gmail.com}[]

Run alpine, it prompts for gmail IMAP

HOST: yx-in-f108.1e100.net:993  USER: agmailaddr@gmail.com  ENTER PASSWORD:                                                                                                       

Ctrl-Z does nothing. If I then do a Ctrl-C it gives me the following:

[Alpine suspension not enabled - see help text]               

Then I looked at the tech notes:

less /usr/share/doc/alpine-2.02/tech-notes.txt 

I see there are two settings:
   _enable-suspend_
   _use-subshell-for-suspend_

I also ran 

alpine -z 

And was able to suspend at the IMAP prompt and come back.
Comment 2 Paul Wouters 2012-07-09 13:30:56 EDT
Created attachment 597115 [details]
pinerc I use (stripped only from most folder names for privacy)

Probably the important part is the folder collection:


folder-collections=Mail/[],
        "Red Hat" {mail.corp.redhat.com/ssl/novalidate-cert/user=pwouters@redhat.com}[]

I do have enable-suspend set
Comment 3 Joshua Daniel Franklin 2012-07-11 20:56:20 EDT
Confirmed with your .pinerc on f17, thanks. Specific IMAP server does not seem to matter.


curl -O 'https://bugzilla.redhat.com/attachment.cgi?id=597115'

grep -v '^#' attachment.cgi\?id\=597115 | sed -e 's;paul;myuser;' | sed -e 's;"Red Hat.*;"gmail" {imap.gmail.com:993/ssl/user=agmailaddr@gmail.com}[];' > .pinerc 

alpine
# select IMAP, Ctrl-Z at IMAP password prompt
fg

Problem detected: "Received abort signal(sig=11)".
Alpine Exiting.


I'll report upstream to 
http://sourceforge.net/projects/re-alpine/
Comment 4 Joshua Daniel Franklin 2012-07-11 21:07:56 EDT
Reported:

https://sourceforge.net/tracker/?func=detail&aid=3542853&group_id=264924&atid=1128048


I'll track via the Re-alpine-bugs list.
Comment 5 Paul Wouters 2012-07-12 13:16:20 EDT
Is there a good reason for pine to catch the segfaults itself, instead of letting it segfault normally so our regular reporting functionality takes it on and we get easier ways to log these into bugzilla with more information from the backtrace?

My preference would be to not have it catch the segfault with a user friendly message.
Comment 6 Joshua Daniel Franklin 2012-07-17 10:12:36 EDT
That's a good question. I'm assuming it goes back to alpine/pine's history as something that was often installed on timeshare systems and the ops did not want lots of core files littering the filesystem. Could also have to do with support for lots of platforms. At this point I would guess it could be taken out, or disabled for Linux at least. Patches accepted. :)
Comment 7 Joshua Daniel Franklin 2012-07-24 23:02:19 EDT
Well, no one at Sourceforge has touched the bug so I guess we're on our own. :)
Thanks for the patch in 841025


I also loaded it in gdb, looks like it crashes due to update_option_screen getting called with a null "screen" which probably shouldn't happen. That's all the time I've got for now.


Setup with:


yum -y install @development-tools
yum -y install aspell gettext inews krb5-devel ncurses-devel openldap-devel openssl-devel pam-devel

_sysconfdir=/etc/
touch imap/ip6
./configure \
  --enable-debug=yes \
  --without-tcl \
  --with-c-client-target=lfd \
  --with-smtp-msa=/usr/sbin/sendmail \
  --with-npa=/usr/bin/inews \
  --with-passfile=.alpine.passfile \
  --with-simple-spellcheck=hunspell \
  --with-interactive-spellcheck=hunspell \
  --with-system-pinerc=%{_sysconfdir}/pine.conf \
  --with-system-fixed-pinerc=%{_sysconfdir}/pine.conf.fixed

cd alpine
gdb ./alpine

run
signal SIGCONT
backtrace

Program received signal SIGSEGV, Segmentation fault.
update_option_screen (ps=0xb55030, screen=0x0, cursor_pos=0x0) at confscroll.c:3046
warning: Source file is more recent than executable.
3046        if((ctmp = screen->top_line) != NULL)
(gdb) bt
#0  update_option_screen (ps=0xb55030, screen=0x0, cursor_pos=0x0) at confscroll.c:3046
#1  0x00000000005c616e in optionally_enter (utf8string=utf8string@entry=0x7fffffff6e70 "", y_base=<optimized out>,
    y_base@entry=-3, x_base=x_base@entry=0, utf8string_size=utf8string_size@entry=100,
    utf8prompt=utf8prompt@entry=0x7fffffff5dc0 "HOST: pb-in-f108.1e100.net:993  USER: agmailaddr@gmail.com  ENTER PASSWORD: ", escape_list=escape_list@entry=0x0, help=help@entry=0x0, flags=flags@entry=0x7fffffff5a6c) at termin.gen.c:923
#2  0x000000000045a551 in mm_login_work (mb=mb@entry=0x7fffffff6ac0,
    user=user@entry=0x7fffffff7270 "agmailaddr@gmail.com", pwd=pwd@entry=0x7fffffff6e70 "", trial=trial@entry=0,
    usethisprompt=usethisprompt@entry=0x0, altuserforcache=altuserforcache@entry=0x0) at imap.c:961
#3  0x000000000054b6bb in mm_login (mb=mb@entry=0x7fffffff6ac0, user=user@entry=0x7fffffff7270 "agmailaddr@gmail.com",
    pwd=pwd@entry=0x7fffffff6e70 "", trial=trial@entry=0) at imap.c:859
#4  0x000000000060827b in imap_login (stream=0xb71330, mb=0x7fffffff6ac0, pwd=0x7fffffff6e70 "",
    usr=0x7fffffff7270 "agmailaddr@gmail.com") at imap4r1.c:1203
#5  0x000000000060e152 in imap_open (stream=0xb71330) at imap4r1.c:913
#6  0x00000000005df71a in mail_open_work (d=0xa9c6c0, stream=0xb71330, stream@entry=0x0,
    name=0x438540 "H\213=\231\302q", name@entry=0x7fffffff8f70 "{imap.gmail.com:993/ssl/user=agmailaddr@gmail.com}x",
    options=options@entry=80) at mail.c:1338
#7  0x00000000005e58db in mail_open (stream=stream@entry=0x0,
    name=name@entry=0x7fffffff8f70 "{imap.gmail.com:993/ssl/user=agmailaddr@gmail.com}x", options=options@entry=80)
    at mail.c:1260
#8  0x00000000005a7a03 in pine_mail_open (stream=stream@entry=0x0,
    mailbox=mailbox@entry=0x7fffffff8f70 "{imap.gmail.com:993/ssl/user=agmailaddr@gmail.com}x", openflags=80,
    openflags@entry=201326672, retflags=retflags@entry=0x0) at stream.c:588
#9  0x00000000005aa576 in mail_cmd_stream (context=context@entry=0xb6f840, closeit=closeit@entry=0x7fffffff93cc)
    at stream.c:3355
#10 0x0000000000547f78 in build_folder_list (stream=0x7fffffffc078, context=context@entry=0xb6f840, pat=0xb6f7e0 "%",
    pat@entry=0x0, content=content@entry=0x0, flags=<optimized out>) at folder.c:964
Comment 8 Eduardo Chappa 2013-03-15 14:09:41 EDT
Joshua et al.,

  This problem is fixed in Alpine 2.10, which can be obtained from

http://patches.freeiz.com/alpine/info/alpine.html

  Thank you.

-- 
Eduardo
http://patches.freeiz.com/alpine/
Comment 9 Paul Wouters 2013-03-15 16:01:28 EDT
I confirmed this is fixed using a build of this alpine-2.10 version

I'm going to test this client version some more over the next few days, as it contains a lot more then just this fix.
Comment 10 Joshua Daniel Franklin 2013-03-17 21:18:38 EDT
Hi Eduardo,

Thanks so much! It appears the "Alpine 2.10" from your site the README file says it is licensed under ASL2.0, but the rcs update is from hubert@u and not you and you have not added your copyright notice to that file but you did add it to many other files. Can you therefore confirm you are licensing your contributions under ASL2.0 ? In the past you explicitly did not:
http://mailman2.u.washington.edu/pipermail/alpine-info/2011-April/004056.html

Also, I know this may not be your main concern but I see you're still including the conflicting non-commercial licensed file "pico/msmem.c" (BZ #888204).

To be clear: I am extremely grateful for your work and thank you!
Comment 11 Eduardo Chappa 2013-03-17 23:10:26 EDT
Dear Joshua,

  I am starting to use git to maintain my work, this is mostly due to the crashing of my computer and losing pretty much everything in it, so the transition to a new rcs is being done slowly. If you have suggestions on what to change, I will be happy to read. It will be probably easy to release new versions of Alpine in the future than maintain patches, given the current state of affairs: I still have not sent my hard drive to be recovered, and doubt it will happen any time soon.

  In terms of licensing, Alpine 2.10 is licensed under the Apache License Version 2.0, my patches not included there are copyright me. I am transitioning from going from patches to releases of Alpine. I have at least 2 more releases, where more patches, and new features will go too. After that, probably only new features will go. Some current patches will stay as such.

  I understand your concern on removing code that is not clearly licensed. You might want to investigate if the person that actually wrote that code would be willing to license it. The code is not necessary for anything. I have never built nor run msmen.c, but it seems like a legacy from the time RAM was a rare commodity (as in "640K is sufficient for everyone").

  The message you refer to in your message talks about licensing patches to re-alpine. Nothing has changed in that regard, because the patches are still in my copyright, what changed was that I added some of those patches to the svn version of Alpine, and the resulting code was released under the Apache License 2.0 as version 2.10.

  I hope this clarifies the issue you are inquiring about. If not, just let me know.

-- 
Eduardo
Comment 12 Joshua Daniel Franklin 2013-03-19 09:31:27 EDT
Hi Eduardo,

Thanks for the reply. I should have mentioned, I attempted to contact Stephen Chung listed as author of the msmen.c file but both email addresses listed (from 1992) bounce, and it's a common enough name that I wasn't able to find anything recent for him.

In my opinion, it makes the most sense for your alpine 2.10 to become the upstream for Fedora/Red Hat but that file would need to be removed. 

Also, I've been added as an admin of the "re-alpine" SourceForge project so if you'd like to use the git there feel free:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
I'd be happy to make you admin on the project as well, as noted above development is not very active there, but SF does have a lot of downloads. 

Thank you,
Joshua
Comment 13 Paul Wouters 2013-03-19 13:20:52 EDT
I tried to contact him as well at those email addresses, but also at linkedin,where I do believe I found him. But he has not responded to me yet.
Comment 14 Eduardo Chappa 2013-03-19 14:55:27 EDT
Dear Paul and Joshua,

  Thank you for your messages. I did not know that an attempt had been made to contact him. In case it helps, there is a Stephen Chung in stackoverflow.com at

http://stackoverflow.com/users/650891/stephen-chung

It looks like it is him. I do not know if this is the same person that you attempted to contact earlier. I do agree that it would be better to have the permissions that are necessary for redistribution, etc.

  In regards to the specific file msmem.c, there is no harm in removing it, it does nothing. If you would like to remove it from the current release of Alpine 2.10, I would appreciate that. I will remove it from the next one for sure, unless I hear otherwise. Packaging Alpine is much harder now than it used to be without all the tools I use to package it - particularly due to the inclusion of patches, and creation/update of files that were done automatically in the past with the scripts I used to run, but if you give me a couple of days, I might be able to get an updated version up, without that file.

  In regards to git access, I am still struggling with that issue. I have my own local repository, which I'd like people to try and give feedback on. I have plans for a new release this year, but I am behind schedule, so I am not sure when will that happen. In any case, re-alpine is not an option at this time for me. My version of why I am not part of that effort is at

http://patches.freeiz.com/

  I am also thinking of moving development to github.com, but with so many projects using the word Alpine, it might not be the best idea.

  If I left anything unanswered please let me know.

-- 
Eduardo
Comment 15 Joshua Daniel Franklin 2013-03-22 20:48:17 EDT
Hi Eduardo,

Thanks for the reply. I hope that you are able to recover the environment you use for patching alpine. Regarding git, that seems like the best approach for the future, either at your website (as long as clone is available) or github. 

Lastly, just FYI if you are working on this anyway, a new BZ 924984 was just opened requesting support for ARM 64 (aarch64) and it came with an autoconf patch:
http://ausil.fedorapeople.org/aarch64/alpine/alpine-aarch64.patch

Thank you,
Joshua
Comment 16 Joshua Daniel Franklin 2013-04-22 10:45:55 EDT
Hi Eduardo or Paul,

Did you happen to hear back from Stephen Chung?
Comment 17 Paul Wouters 2013-04-22 10:56:51 EDT
No I did not. The one I thought was the right person on linked in was someone else.
Comment 18 Fedora End Of Life 2013-07-04 01:56:51 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 
'version' of '17'.

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 prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.

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.
Comment 19 Paul Wouters 2013-07-08 13:48:14 EDT
2.10 fixed the problem for me, but this version is not yet in a fedora branch

joshua: any objection to the attached spec file for making new releases?
Comment 20 Paul Wouters 2013-07-08 13:49:44 EDT
Created attachment 770603 [details]
updated spec file
Comment 21 Paul Wouters 2013-07-08 14:12:26 EDT
Created attachment 770605 [details]
patch to fedora alpine repo to move to 2.10 and fix dates
Comment 22 Paul Wouters 2013-07-08 14:13:20 EDT
joshua: if you want, I can push these changes. I just wanted to double check with you because of the sort-of-change of upstream
Comment 23 Joshua Daniel Franklin 2013-07-08 16:13:12 EDT
Go for it, no worries
Comment 24 Fedora Update System 2013-10-31 14:38:06 EDT
alpine-2.10-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/alpine-2.10-4.fc19
Comment 25 Fedora Update System 2013-10-31 14:39:54 EDT
alpine-2.10-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/alpine-2.10-4.fc18
Comment 26 Fedora Update System 2013-10-31 14:40:35 EDT
alpine-2.10-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/alpine-2.10-4.el6
Comment 27 Fedora Update System 2013-10-31 23:53:42 EDT
Package alpine-2.10-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing alpine-2.10-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20421/alpine-2.10-4.fc19
then log in and leave karma (feedback).
Comment 28 Fedora Update System 2013-11-07 23:36:52 EST
alpine-2.10-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 29 Fedora Update System 2013-11-08 12:58:55 EST
Package alpine-2.11-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing alpine-2.11-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12008/alpine-2.11-1.el6
then log in and leave karma (feedback).
Comment 30 Fedora Update System 2013-11-08 22:38:52 EST
alpine-2.10-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 31 Fedora Update System 2013-12-11 14:34:26 EST
alpine-2.11-1.el6 has been pushed to the Fedora EPEL 6 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.