** Description changed:
+ SRU justification:
+
+ Impact: A bug in the syscall implementation can cause incorrect behavior
+ when trying to use syscalls that are not implemented.
+
+ Fix: Cherry pick from upstream to correctly return an error code in that
+ situation.
+
+ Testcase: see test below.
+
+ ---
+
There is something very wrong with the popen() implementation in Jaunty
on i386. It works fine when run on the Jaunty kernel, but when run on
the Lenny 2.6.26-1-amd64 kernel, it misbehaves as follows. The output
of the subcommand, instead of being fed to the pipe, is fed directly to
stdout; the pipe either returns errors or hangs forever.
This causes weird errors in many programs running in a Jaunty i386
chroot on our Lenny build server.
Attached is a small 5-line test program. Run
gcc -static popen-test.c -o popen-test
and then copy popen-test to a Lenny machine to see the problem.
Correct output:
$ uname -r
2.6.28-8-generic
$ ./popen-test
popen returned 0x1ec6400
ferror returned 0
fread returned 19
ferror returned 0
pclose returned 0
Incorrect output:
$ uname -r
2.6.26-1-amd64
$ ./popen-test
popen returned 0x935f688
ferror returned 0
SHOULD NOT DISPLAY
This has been reproduced independently by two of us with two different
Jaunty i386 installs and two different Lenny installs.
** Changed in: linux (Ubuntu Intrepid)
Status: In Progress => Fix Committed
--
Jaunty i386 popen() misbehaves on x86_64 kernel 2.6.26
https://bugs.launchpad.net/bugs/339743
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
