When sandbox lib is in /etc/ld.so.preload, 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.
I have never used mutt. Could you give me a short and quick setup-from-scratch
description to be able to reproduce this behaviour?
I think that the following will demonstrate the problem:
(1) Install mutt
(2) Add the sandbox lib to /etc/ld.so.preload (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.
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 ld.so.preload
Compile the following source to a library by using :
gcc -Wall -O2 -ldl --shared -o libsandbox_muttbug.so libsandbox_muttbug.c
/**** BEGIN libsandbox_muttbug.c ****/
#define open xxx_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;
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 ****/
int main(int argc, char *argv)
FILE *fd ;
fd = fopen("/tmp/test", "a+");
fseek(fd, 0, SEEK_SET);
fd = freopen("/tmp/test", "r", fd);
fseek(fd, 0, SEEK_SET);
/**** END sandbox_muttbug.c ******/
Now when you execute sandbox_muttbug everything works, however when you put
libsandbox_muttbug.so in /etc/ld.so.preload, you get a segmentation fault after
to file has been reopened.
Fixed in glibc-2.2.5-r3
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.
Erm .. new sandbox ?
What do you mean by "new sandbox"? This was still a problem as of a couple days
ago... I haven't tested since then.
I mean: we need a new sandbox ... too many issues with the current one ;)
I've experienced this same bug. It took a while until I noticed that this only
happened when emerging stuff!
Sorting mailbox...Segmentation fault
and here is a stack backtrace from mutt:
#0 0x40210811 in _IO_seekoff () from /lib/libc.so.6
#1 0x4020f6e6 in ftell () from /lib/libc.so.6
#2 0x08072c3e in mbox_sync_mailbox (ctx=0x80e1bc8, index_hint=0xffffffff)
#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/libc.so.6
This is rather annoying as prevent one from switching mboxes when using emerge...
Wouldn't it be preferrable to specify /lib/libsandbox.so in the LD_PRELOAD environment variable instead of /etc/ld.so.preload ? 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.
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/libc.so.6
#0 0x4020a289 in _IO_seekoff () from /lib/libc.so.6
#1 0x4020f3a9 in fseek () from /lib/libc.so.6
#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/libc.so.6
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 ]
Latest version Available: 1.4
Latest version Installed: 1.4
a small but very powerful text-based mail client
Latest version Available: 2.2.5-r5
Latest version Installed: 2.2.5-r5
GNU libc6 (also called glibc2) C library
calum, this should prove interesting to you, being a mutt guy
Did I mention glibc-2.2.5-r7 with gcc3 or gcc-2.95.3-r7 (atexit bug fixed)
fixes this problem ? =)
This seems to be fixed with gcc 3.2 and glibc-2.2.5-r6. Tested on three
installs of 1.4_beta.
Not really ... sandbox just no longer use /etc/ld.so.preload ....
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).
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.
No, you do not understand correctly. The problem with mutt was if libsandbox.so
was in /etc/ld.so.preload. Our sandbox no longer use /etc/ld.so.preload to
load libsandbox.so, 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
Bug #59676 looks very similar to this one - freopen() in a sandbox fails (I am using glibc 220.127.116.1140420-r1). Please visit this bug and help.