Bug#516301: Seeing similar problem in scrollkeeper-update

[Adar Dembo <adembo@gmail.com>]

Aurelien, you're absolutely right. After installing libc6-i686,
popen() is now working properly. My system is indeed a 32-bit system
but with a 64-bit kernel.

Would you mind pointing me at the bug report for the popen bug?

On Fri, Mar 20, 2009 at 3:07 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> 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
>