Created attachment 13068 [details]
test program

When using socket_wrapper on a 32bit system, calls to open() do not get wrapped properly (or the loading of the wrapped function does not persist). Since wrapping open() is necessary for tracking stale wrapper fds, this can lead to failed writes in some situations. The test program attached simulates this with a scenario where socket() is followed up by an internal close() letting the fd leak. When the open() is not wrapped on 32bit, the following write() fails with ENOTCONN as open() returned the leaked fd. Comparing the relevant portion of the LD_DEBUG output between 32-bit and 64-bit: 

$ LD_PRELOAD=libsocket_wrapper.so SOCKET_WRAPPER_DIR=sockets SOCKET_WRAPPER_DEBUGLEVEL=4 LD_DEBUG=symbols ./test

On 32-bit:
..
      1525:     symbol=open;  lookup in file=./test [0]
      1525:     symbol=open;  lookup in file=/lib/libsocket_wrapper.so [0]
      1525:     symbol=open;  lookup in file=/lib/libdl.so.2 [0]
      1525:     symbol=open;  lookup in file=/lib/libc.so.6 [0]
open() returned 3
      1525:     symbol=strlen;  lookup in file=./test [0]

On 64-bit:
..
     21379:     symbol=open;  lookup in file=./test [0]
     21379:     symbol=open;  lookup in file=/lib64/libsocket_wrapper.so [0]
     21379:     binding file ./test [0] to /lib64/libsocket_wrapper.so [0]: normal symbol `open' [GLIBC_2.2.5]
     21379:     symbol=open;  lookup in file=/lib64/libc.so.6 [0]
     21379:     binding file /lib64/libc.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `open'
SWRAP_TRACE(21379) - _swrap_load_lib_function: Loaded open from libc
SWRAP_TRACE(21379) - swrap_remove_stale: remove stale wrapper for 3
open() returned 3

One thing maybe notable about the problem is that running it as "bash -c ./test" in the LD_DEBUG output on 32-bit there does appear to be a properly wrapped open() before control is passed to ./test. Any open() in ./test at that point on is not wrapped. However I suspect there may be some compile time optimization in socket_wrapper (or perhaps glibc) that is interfering, I'm just not sure which one it would be.

socket_wrapper-1.1.6-1.fc25.i686
glibc-2.24-4.fc25.i686
Linux test.example.com 4.8.6-300.fc25.i686+PAE #1 SMP Tue Nov 1 12:54:54 UTC 2016 i686 i686 i386 GNU/Linux

$ rpm -q --queryformat="%{OPTFLAGS}\n" socket_wrapper
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables
$ rpm -q --queryformat="%{OPTFLAGS}\n" glibc
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables