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 wrapper. 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 _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("unlink\n"); unlink("/tmp/test"); printf("... done\n"); printf("fopen\n"); fd = fopen("/tmp/test", "a+"); printf("... done\n"); printf("fputc\n"); fputc('7', fd); printf("... done\n"); printf("fseek\n"); fseek(fd, 0, SEEK_SET); printf("... done\n"); printf("freopen\n"); fd = freopen("/tmp/test", "r", fd); printf("... done\n"); printf("fgetc "); printf("%c\n", fgetc(fd)); printf("... done\n"); printf("fseek\n"); fseek(fd, 0, SEEK_SET); printf("... done\n"); printf("fclose\n"); fclose(fd); printf("... done\n"); } /**** 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 ?
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. Aron
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! mutt says: 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) 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/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 found)... Program received signal SIGSEGV, Segmentation fault. 0x4020a289 in _IO_seekoff () from /lib/libc.so.6 (gdb) bt #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 ] * net-mail/mutt Latest version Available: 1.4 Latest version Installed: 1.4 Homepage: http://www.mutt.org Description: 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 Homepage: http://www.gnu.org/software/libc/libc.html Description: 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. Scott Robbins scottro@despammed.com
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 in sandbox.
Bug #59676 looks very similar to this one - freopen() in a sandbox fails (I am using glibc 2.3.3.20040420-r1). Please visit this bug and help.
