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:
__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 read(0,
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.
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!
Whiel reading through the dig documentation today I came across the “nssearch” option:
dig +nssearch @192.168.1.1 daemons.net
SOA olympus.daemons.net. hostmaster.daemons.net. 1128483301 16384 2048 1048576 2560 from server olympus.daemons.net in 27 ms. SOA olympus.daemons.net. hostmaster.daemons.net. 1128483259 16384 2048 1048576 2560 from server elysium.daemons.net 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.
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.
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!