Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 838359 - alpine crashes when suspending in password prompt mode
Summary: alpine crashes when suspending in password prompt mode
Alias: None
Product: Fedora
Classification: Fedora
Component: alpine
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Joshua Daniel Franklin
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-07-08 19:13 UTC by Paul Wouters
Modified: 2013-12-11 19:34 UTC (History)
4 users (show)

Fixed In Version: alpine-2.11-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-11-09 03:38:52 UTC
Type: Bug

Attachments (Terms of Use)
pinerc I use (stripped only from most folder names for privacy) (28.43 KB, text/plain)
2012-07-09 17:30 UTC, Paul Wouters
no flags Details
updated spec file (8.49 KB, text/x-rpm-spec)
2013-07-08 17:49 UTC, 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 18:12 UTC, Paul Wouters
no flags Details | Diff

Description Paul Wouters 2012-07-08 19:13:26 UTC
Description of problem:
[paul@bofh ~]$ alpine

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

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

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):

How reproducible:

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 13:37:13 UTC
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

In .pinerc I have Google Mail IMAP:
folder-collections="gmail" {}[]

Run alpine, it prompts for gmail IMAP

HOST:  USER: agmailaddr  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:

I also ran 

alpine -z 

And was able to suspend at the IMAP prompt and come back.

Comment 2 Paul Wouters 2012-07-09 17:30:56 UTC
Created attachment 597115 [details]
pinerc I use (stripped only from most folder names for privacy)

Probably the important part is the folder collection:

        "Red Hat" {}[]

I do have enable-suspend set

Comment 3 Joshua Daniel Franklin 2012-07-12 00:56:20 UTC
Confirmed with your .pinerc on f17, thanks. Specific IMAP server does not seem to matter.

curl -O ''

grep -v '^#' attachment.cgi\?id\=597115 | sed -e 's;paul;myuser;' | sed -e 's;"Red Hat.*;"gmail" {}[];' > .pinerc 

# select IMAP, Ctrl-Z at IMAP password prompt

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

I'll report upstream to

Comment 4 Joshua Daniel Franklin 2012-07-12 01:07:56 UTC

I'll track via the Re-alpine-bugs list.

Comment 5 Paul Wouters 2012-07-12 17:16:20 UTC
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 14:12:36 UTC
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-25 03:02:19 UTC
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

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 \

cd alpine
gdb ./alpine

signal SIGCONT

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:  USER: agmailaddr  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", 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",
    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") 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 "{}x",
    options=options@entry=80) at mail.c:1338
#7  0x00000000005e58db in mail_open (stream=stream@entry=0x0,
    name=name@entry=0x7fffffff8f70 "{}x", options=options@entry=80)
    at mail.c:1260
#8  0x00000000005a7a03 in pine_mail_open (stream=stream@entry=0x0,
    mailbox=mailbox@entry=0x7fffffff8f70 "{}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 18:09:41 UTC
Joshua et al.,

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

  Thank you.


Comment 9 Paul Wouters 2013-03-15 20:01:28 UTC
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-18 01:18:38 UTC
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:

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-18 03:10:26 UTC
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.


Comment 12 Joshua Daniel Franklin 2013-03-19 13:31:27 UTC
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:
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,

Comment 13 Paul Wouters 2013-03-19 17:20:52 UTC
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 18:55:27 UTC
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 at

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

  I am also thinking of moving development to, 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.


Comment 15 Joshua Daniel Franklin 2013-03-23 00:48:17 UTC
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:

Thank you,

Comment 16 Joshua Daniel Franklin 2013-04-22 14:45:55 UTC
Hi Eduardo or Paul,

Did you happen to hear back from Stephen Chung?

Comment 17 Paul Wouters 2013-04-22 14:56:51 UTC
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 05:56:51 UTC
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 17:48:14 UTC
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 17:49:44 UTC
Created attachment 770603 [details]
updated spec file

Comment 21 Paul Wouters 2013-07-08 18:12:26 UTC
Created attachment 770605 [details]
patch to fedora alpine repo to move to 2.10 and fix dates

Comment 22 Paul Wouters 2013-07-08 18:13:20 UTC
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 20:13:12 UTC
Go for it, no worries

Comment 24 Fedora Update System 2013-10-31 18:38:06 UTC
alpine-2.10-4.fc19 has been submitted as an update for Fedora 19.

Comment 25 Fedora Update System 2013-10-31 18:39:54 UTC
alpine-2.10-4.fc18 has been submitted as an update for Fedora 18.

Comment 26 Fedora Update System 2013-10-31 18:40:35 UTC
alpine-2.10-4.el6 has been submitted as an update for Fedora EPEL 6.

Comment 27 Fedora Update System 2013-11-01 03:53:42 UTC
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:
then log in and leave karma (feedback).

Comment 28 Fedora Update System 2013-11-08 04:36:52 UTC
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 17:58:55 UTC
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:
then log in and leave karma (feedback).

Comment 30 Fedora Update System 2013-11-09 03:38:52 UTC
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 19:34:26 UTC
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.