Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 501 - sandbox breaks mutt
Summary: sandbox breaks mutt
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Khayyam
Depends on:
Reported: 2002-02-02 14:14 UTC by Aron Griffis (RETIRED)
Modified: 2011-10-30 22:19 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Aron Griffis (RETIRED) gentoo-dev 2002-02-02 14:14:23 UTC
When sandbox lib is in /etc/, then mutt segfaults trying to write a
mailbox.  I haven't tracked this down yet; I'll try to add debugging information
in the future.

Note that this is true with Portage 1.8.7.
Comment 1 Geert Bevin 2002-02-04 10:52:10 UTC
I have never used mutt. Could you give me a short and quick setup-from-scratch
description to be able to reproduce this behaviour?
Comment 2 Aron Griffis (RETIRED) gentoo-dev 2002-02-16 10:49:45 UTC
I think that the following will demonstrate the problem:

(1) Install mutt
(2) Add the sandbox lib to /etc/ (to simulate emerging something)
(3) Run "mutt -f mboxfile" where mboxfile is a mailbox in mbox format
(4) Press 'd' to mark a message for deletion
(5) Press '$' to commit the changes to the mailbox

Mutt should segfault at this point.  Let me know if it doesn't work.  You should
be able to attach to mutt with ltrace (or gdb) to track down the problem.

Sorry for the delay.
Comment 3 Geert Bevin 2002-03-18 06:09:38 UTC
I identified what goes wrong, but I haven't found how to fix it yet. Apparenly,
glibc isn't able to reopen files that have been opened through an

Compile the following source to a library by using :

gcc -Wall -O2 -ldl --shared -o libsandbox_muttbug.c

/**** BEGIN libsandbox_muttbug.c ****/
#define _GNU_SOURCE
#define _REENTRANT

#define open xxx_open
#include <dlfcn.h>
#include <errno.h>
#include <stdio.h>
#undef open

extern FILE* fopen(const char*, const char*);
FILE* (*orig_fopen)(const char*, const char*) = 0;
FILE* fopen(const char* a1, const char* a2)
	int old_errno = errno;
	if (!orig_fopen)
		orig_fopen = dlsym(RTLD_NEXT, "fopen");
	errno = old_errno;
	return orig_fopen(a1, a2);
/**** END libsandbox_muttbug.c ******/

Compile the following executable by using :

gcc -g -o sandbox_muttbug sandbox_muttbug.c

/**** BEGIN sandbox_muttbug.c ****/
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
	FILE *fd ;
	printf("... done\n");
	fd = fopen("/tmp/test", "a+");
	printf("... done\n");
	fputc('7', fd);
	printf("... done\n");
	fseek(fd, 0, SEEK_SET);
	printf("... done\n");
	fd = freopen("/tmp/test", "r", fd);
	printf("... done\n");
	printf("fgetc ");
	printf("%c\n", fgetc(fd));
	printf("... done\n");
	fseek(fd, 0, SEEK_SET);
	printf("... done\n");
	printf("... done\n");
/**** END sandbox_muttbug.c ******/

Now when you execute sandbox_muttbug everything works, however when you put in /etc/, you get a segmentation fault after
to file has been reopened.
Comment 4 Geert Bevin 2002-04-03 15:22:52 UTC
Fixed in glibc-2.2.5-r3
Comment 5 Geert Bevin 2002-04-05 01:58:49 UTC
Masked glibc-2.2.5-r3 since it apparently causes problems with relocated
functions (atexit) in some prebuilt binaries (win4lin, accurev)
Maybe it would be best to hold off with this until the next official glibc release.
Comment 6 Martin Schlemmer (RETIRED) gentoo-dev 2002-06-10 13:52:39 UTC
Erm .. new sandbox ?
Comment 7 Aron Griffis (RETIRED) gentoo-dev 2002-06-10 17:39:51 UTC
Hey Azarah!

What do you mean by "new sandbox"?  This was still a problem as of a couple days
ago...  I haven't tested since then.

Comment 8 Martin Schlemmer (RETIRED) gentoo-dev 2002-06-11 14:53:19 UTC
I mean: we need a new sandbox ... too many issues with the current one ;)
Comment 9 José Fonseca 2002-06-24 17:37:00 UTC
I've experienced this same bug. It took a while until I noticed that this only
happened when emerging stuff!

mutt says:

  Sorting mailbox...Segmentation fault

and here is a stack backtrace from mutt:

  #0  0x40210811 in _IO_seekoff () from /lib/
  #1  0x4020f6e6 in ftell () from /lib/
  #2  0x08072c3e in mbox_sync_mailbox (ctx=0x80e1bc8, index_hint=0xffffffff)
    at mbox.c:798
  #3  0x080790cc in sync_mailbox (ctx=0x80f9d08, index_hint=0x0) at mx.c:779
  #4  0x08079312 in mx_close_mailbox (ctx=0x0, index_hint=0xbfffebac) at mx.c:999
  #5  0x0805dfc5 in mutt_index_menu () at curs_main.c:822
  #6  0x08070e36 in main (argc=3, argv=0xbffff984) at main.c:841
  #7  0x401c7142 in __libc_start_main () from /lib/

This is rather annoying as prevent one from switching mboxes when using emerge...
Comment 10 José Fonseca 2002-07-14 08:22:51 UTC
Wouldn't it be preferrable to specify /lib/ in the LD_PRELOAD environment variable instead of /etc/ ? The chance of that variable being overriden during a emerge is probably very small, and at any rate, it would be preferrable taking that chance than being unable to check the email or completely disable the sandbox...

Please consider this... This is not only an annoying but also a quite serious bug: god knows what other side effects that the sandbox may have in other (perhaps critical) apps one may have, so it shouldn't be left open like this so much time already.
Comment 11 Thomas Zimmerman 2002-07-24 20:33:40 UTC
Mutt continues to segfault here if the mailbox was locked during an 
emerge...(yes I read mail with an emerge going on in the background...hadn't 
noticed that it only segfaults when a mailbox is locked during a emerge). 
anyway, my backtrace is somewhat different:  
Sorting mailbox...(no debugging symbols found)...(no debugging symbols 
Program received signal SIGSEGV, Segmentation fault. 
0x4020a289 in _IO_seekoff () from /lib/ 
(gdb) bt 
#0  0x4020a289 in _IO_seekoff () from /lib/ 
#1  0x4020f3a9 in fseek () from /lib/ 
#2  0x08072728 in strcpy () 
#3  0x08078ffc in strcpy () 
#4  0x08079989 in strcpy () 
#5  0x0805dcbd in strcpy () 
#6  0x08070e02 in strcpy () 
#7  0x401c24b2 in __libc_start_main () from /lib/ 
Can't change any mailbox that had mail delivered while an emerge was 
happening...sort of sucks. 
qubes@darklands:~>emerge search mutt glibc 
[ Results for search key : mutt ] 
[ Applications found : 1 ] 
*  net-mail/mutt 
      Latest version Available: 1.4 
      Latest version Installed: 1.4 
      a small but very powerful text-based mail client 
*  sys-libs/glibc 
      Latest version Available: 2.2.5-r5 
      Latest version Installed: 2.2.5-r5 
      GNU libc6 (also called glibc2) C library 
Comment 12 Seemant Kulleen (RETIRED) gentoo-dev 2002-08-16 22:04:55 UTC
calum, this should prove interesting to you, being a mutt guy
Comment 13 Martin Schlemmer (RETIRED) gentoo-dev 2002-08-18 17:54:02 UTC
Did I mention glibc-2.2.5-r7 with gcc3 or gcc-2.95.3-r7 (atexit bug fixed)
fixes this problem ? =)
Comment 14 Scott Robbins 2002-09-07 12:59:06 UTC
This seems to be fixed with gcc 3.2 and glibc-2.2.5-r6.  Tested on three 
installs of 1.4_beta.  

Scott Robbins
Comment 15 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-07 13:52:45 UTC
Not really ... sandbox just no longer use /etc/ ....
Comment 16 Khayyam 2002-09-07 14:06:59 UTC
I'm closing this as from scott's account this seems to be fixed with glibc-2.2.5-r6. Also as i'm not able to test any sandbox issues with ppc (no sandbox).
Comment 17 Khayyam 2002-09-07 14:12:05 UTC
Ok .. so if it's not fixed then it needs to be reasigned to x86 as there
is no way for me to track this one down.
Comment 18 Martin Schlemmer (RETIRED) gentoo-dev 2002-09-07 14:38:17 UTC
No, you do not understand correctly.  The problem with mutt was if
was in /etc/  Our sandbox no longer use /etc/ to
load, so mutt no longer should segfault.  My original comment
was thus that it is *not* gcc and glibc that is the fix, but rather the changes
in sandbox.
Comment 19 Patrick Kursawe (RETIRED) gentoo-dev 2004-09-29 06:51:23 UTC
Bug #59676 looks very similar to this one - freopen() in a sandbox fails (I am using glibc Please visit this bug and help.