Bug 10668 - regression: since glibc 2.9 one app can not execute another one
Summary: regression: since glibc 2.9 one app can not execute another one
Status: RESOLVED WORKSFORME
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.10
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-19 17:44 UTC by Zbigniew Luszpinski
Modified: 2014-07-01 06:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zbigniew Luszpinski 2009-09-19 17:44:17 UTC
After updating glibc 2.7/2.8 to 2.9 or 2.10.1 some apps which execute another
app stopped working on this functionality without any sign of error.

examples:
midnight commander: keys: F3 (launches mcview app) and F4 (launches mcedit app)
stopped working. Pressing these keys does nothing.

kde 3 or 4:
kdesu anyapp: execution returns nothing. The app launched via kdesu does not start.

Downgrading to glibc 2.8 resolves problem. Recompiling mc or kde after glibc
does not make difference. I encounter problem in glibc 2.9 and 2.10.1 built from
official sources. This is the only bug I found in these releases.

Can you please tell me if this is because old kernel headers? I use kernel
headers 2.6.23 and use linux-2.6.31

This regression happened between glibc 2.8 and 2.9 and continues to 2.10.1

parameters I use for configure:
               --prefix=/usr                           \
               --infodir=/usr/share/info               \
               --mandir=/usr/share/man                 \
               --with-elf                              \
               --without-gd                            \
               --without-cvs                           \
               --enable-shared                         \
               --enable-kernel=2.6.23                  \
               --enable-omitfp                         \
--with-headers=/usr/include \
--enable-add-ons=nptl,libidn \
--with-__thread \
--with-tls
Comment 1 Petr Baudis 2009-09-19 21:07:01 UTC
Linux headers version doesn't matter as long as you pass proper configure
parameters and they aren't newer than your kernel.

Unfortunately, we cannot support problems in your applications, which might e.g.
call glibc incorrectly and got away with it in older versions, or whatever else.
Also, many people use these glibc versions without any problems, so it seems
likely to be a problem in your local setup.

Please provide a self-contained test-case C code if you believe this is a
problem in glibc, or at the very least ltrace/latrace and corresponding strace
output for the failed execution.
Comment 2 Ulrich Drepper 2009-10-29 23:25:32 UTC
No answer in more than a month.  Given the severity such a problem would have
and that nobody else reported anything like this it is a safe assumption that it
was a local problem.