Why would the same binary want linux-vdso.so.1 on one 64-bit RHEL 5.4 server and not another?
Asked Answered
S

1

11

I have a customer running a file parsing program called cleanfileg and as of the last update, he is getting date-format error when parsing a file.

What's bizarre is that we're both running the same program, on the same file, with the same builds of gcc, pthread, libc etc. on the same release of RHEL64 (5.4) and I cannot replicate his issue. He can roll back to last month's version of cleanfileg and everything works fine, so I'm pretty sure that a line-by-line through the source will likely find me an answer, but what's confusing to me is that on a whim, I asked him to run ldd on his executable to see if he was pulling in some different verions of the shared objects.

His-

# ldd cleanfileg
linux-vdso.so.1 =>  (0x00002ad4c98d1000)
libmdGeo.so => /tools/clean_address/bin/libmdGeo.so (0x00002ad4c98d6000)
libmdName.so => /tools/clean_address/bin/libmdName.so (0x00002ad4c9a70000)
libmdPhone.so => /tools/clean_address/bin/libmdPhone.so (0x00002ad4c9df1000)
libmdAddr.so => /tools/clean_address/bin/libmdAddr.so (0x00002ad4ca28c000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003833600000)
libAddressDoctor5.so => /tools/clean_address/bin/libAddressDoctor5.so (0x00002ad4ca96d000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003831600000)
libm.so.6 => /lib64/libm.so.6 (0x000000382b200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003830a00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000382ba00000)
libc.so.6 => /lib64/libc.so.6 (0x000000382ae00000)
librt.so.1 => /lib64/librt.so.1 (0x000000382d200000)
/lib64/ld-linux-x86-64.so.2 (0x000000382aa00000)

-Mine

#ldd cleanfileg
libmdGeo.so (0x00002ab5d3342000)
libmdName.so (0x00002ab5d34cf000)
libmdPhone.so (0x00002ab5d3850000)
libmdAddr.so (0x00002ab5d3ceb000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00000034bde00000)
libAddressDoctor5.so (0x00002ab5d43bf000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000034c9000000)
libm.so.6 => /lib64/libm.so.6 (0x00000034b6200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000034c7c00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034b6a00000)
libc.so.6 => /lib64/libc.so.6 (0x00000034b5e00000)
librt.so.1 => /lib64/librt.so.1 (0x00000034b6e00000)
/lib64/ld-linux-x86-64.so.2 (0x00000034b5a00000)

Is linux-vdso.so.1 something that is needed (or not) as dictated by configuration somehow? How/why would it be required by what other wise seem to be identical machines running identical code?

Any next steps anyone could suggest for debugging?

Seismology answered 8/10, 2014 at 21:18 Comment(0)
J
22

Is linux-vdso.so.1 something that is needed (or not) as dictated by configuration somehow?

The linux-vdso.so.1 is a "library" that is injected into every process by the kernel. Read more about it here.

You likely have different kernel versions, which would explain why you are seeing different ldd output.

Jitterbug answered 12/10, 2014 at 16:16 Comment(2)
Hi, is linux-vdso.so.1 injected into every process or this .so exists in kernel? thanksOutlast
archived copy is inaccessibleAnglophobia

© 2022 - 2024 — McMap. All rights reserved.