1

Always after running for a while, process creation reports an error that seems link to a memory allocation error.
I says seems because the process is forked and works.

For instance forking a shell report boost::interprocess::bad_alloc but run with the pid that reports the allocation problem :

pi@raspberrypi ~ $ sh
error pid:30704, boost::interprocess::bad_alloc
$ echo $$
30704
$ 

The command free -l, reports memory is still available :

error pid:31304, boost::interprocess::bad_alloc
             total       used       free     shared    buffers     cached
Mem:        187936     135708      52228          0      20560      62728
Low:        187936     135708      52228
High:            0          0          0
-/+ buffers/cache:      52420     135516
Swap:       524284        588     523696

The command vmstat, also :

error pid:31568, boost::interprocess::bad_alloc
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0    588  54352  20600  62728    0    0    12    30  221   21 52  4 44  0

The stranger is that the process that reports the error works, then I suppose the message is coming from one of dynamic linked library ?

From where this message comes ? and what it means ?

UPDATE: add ldd /bin/sh

pi@raspberrypi ~ $ ldd /bin/sh
    /usr/lib/uv4l/uv4lext/armv6l/libuv4lext.so (0xb6f29000)
    /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f1e000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6dc5000)
    /lib/ld-linux-armhf.so.3 (0xb6f8c000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6db2000)
    librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6d9b000)
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6cbf000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6c44000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6c17000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6bef000)
  • I can't see how it would be coming from the loader or the shell because it is an exception thrown by a C++ library. It's a header only library, so it is compiled into something, but that thing could not be the shell or the loader since they are written in plain C. – goldilocks Nov 6 '14 at 15:49
  • You're right then its comes probably from a dynamic library linked to sh, but even libstdc++ dosenot use boost ? I edit the question to remove the bad hypothesis of loader. – mpromonet Nov 6 '14 at 15:58
  • @goldilocks : Thanks you give the direction ! I had a old LD_PRELOAD variable that load some boost code. Removing it should fix the problem. – mpromonet Nov 6 '14 at 16:19
1

Boost::interprocess is a C++ IPC library. It is "header only", so you will not find a .so for it; it would be built into something statically (template heavy C++ libs suffer this limitation).

That's really unlikely to be the shell (presuming the shell is bash) or the loader, since those are written in plain C. They do link to some esoteric base libraries on the pi (raspbian seems to have some specific pieces unique to it), however, since those don't link to the C++ library either, it is again very very unlikely to be anything in that chain since the whole thing would then need to have been compiled in.

Since "boost::interprocess" is an IPC library, it could easily be that the pid in the error is not the culprit. If not, then it's almost certainly something that does link to libstdc++, which on raspbian is located in /usr/lib/arm-linux-gnueabihf; libstdc++.so.6 is a symlink but lsof will follow that, so:

lsof /usr/lib/arm-linux-gnueabihf/libstdc++.so.6

Should give you a list of running processes using the C++ library. On a default raspbian system that's not anything, so the list should be pretty short.

  • No, but whatever is using boost must be using libstdc++ unless it is a static binary. – goldilocks Nov 6 '14 at 16:38
1

The environment contains LD_PRELOAD=/usr/lib/uv4l/uv4lext/armv6l/libuv4lext.so

This library (that is closed-source) contains boost as shown using strings :

pi@raspberrypi ~ $ strings /usr/lib/uv4l/uv4lext/armv6l/libuv4lext.so | grep boost::interprocess::bad_alloc
boost::interprocess::bad_alloc
::boost::interprocess::bad_alloc

Removing LD_PRELOAD, ldd /bin/sh becomes more simple

/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6eca000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d71000)
/lib/ld-linux-armhf.so.3 (0xb6ef4000)

And the problems disappear.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.