Solaris, Perl and the “inet_aton” problem

In past week I had to compile a new version of Perl in a Solaris box.

This Solaris machine had a GNU compiler (gcc, make, etc.) and I used them on this task.

Everything went fine on compilation, but when I had to use some modules dependent of socket library I faced with this error:

ld.so.1: perl: fatal: relocation error: \
file /home/xxx/utils/perl/lib/5.12.3/sun4-solaris/auto/Socket/Socket.so: \
symbol inet_aton: referenced symbol not found Killed

Reading some documentation about the inet_aton on Solaris systems I noted the function is not implemented on old versions of Solaris and the inet_pton function is used instead.

To solve this problem I had to change the script Configure and recompile the sources:

from:

d_inetaton='$d_inetaton'

to:

d_inetaton='undef'

Just to inform you, in new versions of Solaris (9 and so) the inet_aton function is implemented on libresolv library.

My 2 cents

Memory Debugging on (Open)Solaris

We know there are many commercial tools to debug memory on Solaris systems as Dynamic Suite and Purify. But I prefer to use open source tools always it is possible.

Well, Linux has many open source tools and the best in my opinion is Valgrind, but Valgrind will not be ported to sparc architecture as well to (open)solaris. Then, what tool I should use ?

(Open)Solaris has useful tools to debug memory, the most known is DTrace, but I’ll talk of two important and easiest tools to use: libumem and watchmalloc (equivalent to MALLOC_CHECK from linux).

Using libumem

It’s not need to recompile your application. The library is loaded dynamically by LD_PRELOAD environment variable.

• Prepare your environment

$ setenv UMEM_DEBUG default

$ setenv UMEM_LOGGING transaction

$ setenv LD_PRELOAD libumem.so.1

• Run the application normally

 $ ./myapp

• After the program has passed by all fluxes, generate a core to analyze with mdb

$ gcore `pgrep myapp`

• mdb means Solaris Modular Debugger

$ mdb myapp core.pid

• With mdb opened, just run a simple command (findleaks):

> ::findleaks -dvf
CACHE     LEAKED   BUFCTL CALLER
0014f12f       1 00067000 libumem.so.1`malloc+0x0
----------------------------------------------------------------------
 Total       1 buffer, 48 bytes

Using watchmalloc

Watchmalloc is the linux equivalent to MALLOC_CHECK. The use is most simple than libumem. See it:

• Prepare your environment

$ setenv MALLOC_DEBUG=WATCH,RW

$ setenv LD_PRELOAD watchmalloc.so.1

• Run the application normally

$ ./myapp

• When a leakage happens the program will generate a core dumped and will be possibly to analyze with gdb.