[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#516301: Seeing similar problem in scrollkeeper-update



On Fri, Mar 20, 2009 at 11:57:09AM -0700, Adar Dembo wrote:
> [621008.442024] scrollkeeper-up[5978]: segfault at 4 ip f7cf2ef5 sp 
> ffd71dc8 error 6 in libc-2.9.so[f7c5f000+13c000]
> [621013.664302] scrollkeeper-up[6001]: segfault at 4 ip f7ce0ef5 sp 
> ff95f1b8 error 6 in libc-2.9.so[f7c4d000+13c000]
> [621017.352766] scrollkeeper-up[6018]: segfault at 4 ip f7cb6ef5 sp 
> ffd33588 error 6 in libc-2.9.so[f7c23000+13c000]
>
> I dug into this some more, and saw that scrollkeeper-update is calling  
> create_database_directory on empty paths. Backtracking a bit, it seems 
> that this was happening because the calls to popen("scrollkeeper-config 
> ...", "r") were returning file pointers to pipes that could not be read 
> from.
>
> I wrote a small unit test to see what's going with popen():
>
> #include <stdio.h>
>
> int main(int argc, char *argv[]) {
>         char buf[64];
>         int matches;
>
>         FILE *f = popen("echo foo", "r");
>         if (f == NULL) {
>                 printf("got back bad filedes from popen\n");
>         }
>         matches = fscanf(f, "%s", buf);
>         if (matches == EOF) {
>                 perror("matches");
>         }
>         pclose(f);
>         printf("Found %d matches\n", matches);
>         return 0;
> }
>
> When run on my machine, I get:
> foo
> matches: Bad file descriptor
> Found -1 matches
>
> The "matches: ..." output is to stderr, the rest to stdout. What's 
> striking about this is that it appears the popen() pipe is being 
> redirected to stdout instead of to the new pipe.
>
> Note that my system is semi-broken at the moment; a lot of packages 
> failed to upgrade because I think their postinst scripts rely on this 
> behavior working properly. As an example, invoking zless on a gzipped 
> text file prints the entire file contents to stdout instead of into less.
>

Hmm, it looks like a different problem, as you get an error 4 and seems
to use an i386 system, while the original bug report is about error 14
and an amd64 system.

If that is correct, it's a known bug. amd64 kernels >= 2.6.26 and 
< 2.6.29 are affected by a bug, which cause popen to fail with a recent 
glibc. Possible workaround is to install libc6-i686, or to use a plain
i386 kernel.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net



Reply to: