Blog O' Matty

Using the Linux ltrace utility to trace library calls

This article was posted by Matty on 2005-10-22 13:51:00 -0400 EDT

While debugging an application on a Linux server this week, I needed to view the library calls (specifically malloc and free) that were being called by a process. This was super easy to do with the Linux ltrace(1) utility:

$ ltrace /bin/cat

__libc_start_main(0x8048f49, 1, 0xbfbec464, 0x804ae98, 0x804aeec
setlocale(6, "") = "en_US.UTF-8"
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") = "coreutils"
__cxa_atexit(0x8048f1f, 0, 0, 0x804cb70, 0xbfbec3d8) = 0
getopt_long(1, 0xbfbec464, "benstuvAET", 0x804c9c0, NULL) = -1
__fxstat64(3, 1, 0xbfbec360) = 0
__fxstat64(3, 0, 0xbfbec360) = 0
malloc(1024) = 0x8c5f858

ltrace(1) also allows you to selectively trace library calls when executed with the “-e” option and a set of calls to trace:

$ ltrace -e malloc /bin/cat

malloc(1024) = 0x8883858

If you need to view the library calls from a live process, you can use ltrace(1)’s “-p” option:

$ ps auxw | grep [g]am_server

root 2644 0.0 0.2 2212 1064 ? S 12:51 0:00 /usr/libexec/gam_server

$ ltrace -p 2644

--- SIGSTOP (Stopped (signal)) ---
--- SIGSTOP (Stopped (signal)) ---
time(NULL) = 1130003202
__xstat64(3, "/etc/xdg/menus/server-settings-m"..., 0xbfe342bc) = -1
__errno_location() = 0xb7f266a0
memcpy(0x84a56e0, "|q221", 96) = 0x84a56e0
g_dir_open(0x84a5748, 0, 0, 0x8b59c1, 0x8499fe8) = 0
__xstat64(3, "/root/.config/menus/server-setti"..., 0xbfe342bc) = -1
__errno_location() = 0xb7f266a0
memcpy(0x84a55f8, "330B343277_i256", 96) = 0x84a55f8
g_dir_open(0x84a5660, 0, 0, 0x8b59c1, 0x8499fe8) = 0
__xstat64(3, "/etc/xdg/menus/system-settings-m"..., 0xbfe342bc) = -1

This is a super cool utility, and is invaluable tool for debugging application problems on Linux systems.

Recovering root passwords with Fedora Core

This article was posted by Matty on 2005-10-22 13:33:00 -0400 EDT

I performed a Fedora core 4 installation today, and for some reason the root password I typed in during the installation got munged (or I typed it incorrectly two times). Since Fedora Core uses grub as a boot loader, I was able to recover from this situation relatively quickly.

To get to a shell where I could use the passwd(1) utility or vi(P) to change the password, I first needed to reboot the box to get to the grub menu. Once I was greeted with the grub menu, I used the up and down arrow keys to select a kernel, and then hit the ‘e’ key to edit the boot paramaeters. Once the editor displayed the kernel boot string, I added a 1 immediately following the LABEL definition:

kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=LABEL=/ 1 rhgb quiet

The number following the LABEL definition indicates the run level to boot into, and in this case 1 refers to single user mode. Once you finish editing the boot definition, you can hit ‘b’ to boot. This will boot to single user mode, and should dump you into a shell if everything goes well. Once your in the shell, you can use passwd(1) or vi(P) to update the root users password. Since I haven’t tinkered with grub for quite some time, this experience reminded me how important physical security and grub passwords are!

Comparing SOA records with dig

This article was posted by Matty on 2005-10-20 21:33:00 -0400 EDT

Whiel reading through the dig documentation today I came across the “nssearch” option:

$ dig +nssearch @

SOA 1128483301 16384 2048 1048576 2560 from server in 27 ms.
SOA 1128483259 16384 2048 1048576 2560 from server in 41 ms.

This nifty little option can be used to view the SOA record maintained by all servers authoritative for a domain. If you choose to avoid using AXFR and manually update zone files, this option could be extremely useful.

What is this mDNSResponder process?

This article was posted by Matty on 2005-10-19 20:56:00 -0400 EDT

While reviewing the running processes on my Linux desktop, I noticed a process named mDNSResponder. I have seen this process numerous times on my OS X desktops, but have never taken the time to determine what function it served. Being the curious guy I am, I read through the mDNSResponder(1) manual page, and found the following description:

“The mDNSResponder daemon publishes and browses available services on a link according to the IETF Zeronconf (aka “Rendezvous”) draft standard. Only one instance of mDNSResponder needs to run on a host. Once started, mDNSResponder runs continuously.”

This explains how iTunes is able to discover airtunes capable airport express base stations, and is most likely the foundation of peer-to-eer service discovery in Apple networks.

PCI Express and DDR2 -- worth the money?

This article was posted by Matty on 2005-10-18 00:18:00 -0400 EDT

While ignoring my own advice and reading various Mac rumor sites today, I saw that the next generation Powermacs may ship with DDR2 memory and PCI express video cards. Being the geek I am, I wandered off to see how much throughput could be achieved with each technology.

I started my knowledge quest by reading PCSTATS PCI Express tutorial, and was blown away by the potential of PCI Express. Not only does PCI express move considerably more data than PCI (250MB/s vs. 133 MB/s), it uses serial switched lanes to move data, and allows devices on the same PCI express BUS to communicate directly without involving the chipset.

Now DDR2 doesn’t look as promising as PCI express, and requires the memory to run at a high clock rate to achieve higher throughput than good old DDR memory. I am always curious to see what Apple does, and look forward to reviewing the specifications of the next generation powermacs!