SIGILL when using popen-noshell

[GoogleCodeExporter]

This is a problem I've come across when popen-noshell is built as a shared 
library (this only happens randomly though):

Program terminated with signal 4, Illegal instruction.
#0  0x00007f7427cc3ce9 in _dl_x86_64_restore_sse () from 
/lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00007f7427cc3ce9 in _dl_x86_64_restore_sse () from 
/lib64/ld-linux-x86-64.so.2
#1  0x00007f7427cbd025 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#2  0x00007f7427cc3675 in _dl_runtime_resolve () from 
/lib64/ld-linux-x86-64.so.2
#3  0x00007f7426baabc1 in popen_noshell_child_process_by_clone (raw_arg=<value 
optimized out>) at popen_noshell.c:176
#4  0x00007f7425965ccd in clone () from /lib64/libc.so.6
(gdb) up
#1  0x00007f7427cbd025 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
(gdb) up
#2  0x00007f7427cc3675 in _dl_runtime_resolve () from 
/lib64/ld-linux-x86-64.so.2
(gdb) up
#3  0x00007f7426baabc1 in popen_noshell_child_process_by_clone (raw_arg=<value 
optimized out>) at popen_noshell.c:176
176     _popen_noshell_child_process(arg, arg->pipefd_0, arg->pipefd_1, 
arg->read_pipe, arg->ignore_stderr, arg->file, arg->argv);

The problem here is that _popen_noshell_child_process is an externally visible 
symbol and thanks to "-z lazy" (which is the default for GNU ld the dynamic 
linker) tries to lazily resolve that symbol at runtime. Ordinarily this would 
be required to make things like LD_PRELOAD work.

Note that this can also happen for any of the other symbols the child process 
accesses, e.g. close(), dup2() and whatever other symbols these functions use 
internally, however most likely the libc has already resolved those symbols 
before we even get to our popen_noshell() call.

Explicitly using the "-z now" flag for ld seems to have fixed this problem for 
me.

Original issue reported on code.google.com by gun...@beutner.name on 22 Jun 2012 at 1:47

[GoogleCodeExporter]

Actually, here's another stacktrace where it happened while resolving open(), 
so apparently -z now isn't working in all cases:

(gdb) bt
#0  0x00007f398544cce9 in _dl_x86_64_restore_sse ()
   from /lib64/ld-linux-x86-64.so.2
#1  0x00007f3985446025 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#2  0x00007f398544c675 in _dl_runtime_resolve ()
   from /lib64/ld-linux-x86-64.so.2
#3  0x00007f3984332743 in popen_noshell_reopen_fd_to_dev_null (fd=0)
    at popen_noshell.c:67
#4  0x00007f39843327d1 in _popen_noshell_child_process (
    arg_ptr=<value optimized out>, pipefd_0=<value optimized out>,
    pipefd_1=<value optimized out>, read_pipe=<value optimized out>,
    ignore_stderr=<value optimized out>,
    file=0x7f39740009e0,
    argv=0x7f3974000a10) at popen_noshell.c:142
#5  0x00007f3984332bc1 in popen_noshell_child_process_by_clone (
    raw_arg=<value optimized out>) at popen_noshell.c:176
#6  0x00007f39830edccd in clone () from /lib64/libc.so.6
(gdb) up
#1  0x00007f3985446025 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
(gdb)
#2  0x00007f398544c675 in _dl_runtime_resolve ()
   from /lib64/ld-linux-x86-64.so.2
(gdb)
#3  0x00007f3984332743 in popen_noshell_reopen_fd_to_dev_null (fd=0)
    at popen_noshell.c:67
67              dev_null_fd = open("/dev/null", O_RDWR);
(gdb)

Original comment by gun...@beutner.name on 22 Jun 2012 at 7:34

[GoogleCodeExporter]

I'm really sorry for the late reply. It turned out that I wasn't getting any 
notifications for new issues here.

Please provide an example along with its source code, in order for me to be 
able to reproduce this on my machine. Otherwise I don't think I can help in 
fixing this.

Original comment by ivan.zah...@gmail.com on 23 May 2013 at 6:36

• Changed state: Accepted

[GoogleCodeExporter]

I'm closing this issue since no feedback was provided by the original reporter.

Original comment by ivan.zah...@gmail.com on 9 Jun 2013 at 1:06

• Changed state: WontFix