Re: ulogd unaligned trap
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.