Carlos Rodrigues wrote:
On 1/24/06, Jay Estabrook <Jay.Estabrook@hp.com> wrote:I think you can use "ldd /wherever/you/find/ulogd" to print the libraries used by "ulogd" and where they are relocated to; that should at least give the library the unaligned accesses come from...Ok, so here it is... ulisses:~# ldd /usr/sbin/ulogd libdl.so.2.1 => /lib/libdl.so.2.1 (0x0000020000038000) libc.so.6.1 => /lib/libc.so.6.1 (0x000002000004c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020000000000) Not much there. So, it seems that those addresses belong to something related to glibc. Any ideas how I can trace this down? One of the machines isn't on production, so I can try to see exactly where these messages are triggered. However, I don't exactly see how to do this using ltrace/strace... (since the messages are generated by the kernel).
See if this helps any: As root, try cat /proc/<pid>/maps (where pid is the process ID number of ulogd) to see if it shows anything useful. The first column of each line should have an address range in the form of start-end and the last column of the line should be the executable, library or identification of the storage (stack, heap). (I checked this on a 2.6 kernel, I _think_ it's there in 2.4 too...) If that address shows it is a executable or library, you can use the objdump command to display the symbols and addresses of the code in binary. The command to do that is objdump -t -T <binary>. You'll want to pipe the output to more as it can be long. If you can match the address from the kernel message into the range of a symbol, that will tell you what routine it is executing at the time of the fixup. Once you have an idea at what routine it is, you can then look at ulogd source to see what it is passing into the routine to see if it is ok. If that looks ok, you need to get the library's source and look at that routine in the library. Alan