Some programmers assume that a NULL character pointer is the same as a pointer to a NULL string. However de-referencing a NULL pointer (ie., location
0x00000000
in the address space of a 32-bit process) results in a segmentation fault on Solaris; and hence the process dies with a signal SEGV. On Solaris, typically application text loads at
0x00001000
. All the address space between
0x00000000
and
0x0000FFFF
(that is about 64K of address space) is not used.
I still need to find out why?. [Update: 04/26/06] According to
Chris, first few pages were intentionally unmapped to catch poorly written code.
Thanks Chris.The following simple C program illustrates the NULL pointer de-referencing, and the subsequent process crash:
% cat strlen.c
#include <stdio.h>
#include <string.h>
int main()
{
char *string = NULL;
printf("\nString length = %d", strlen(string));
return (0);
}
% cc -g -o strlen strlen.c
% ./strlen
Segmentation Fault (core dumped)
% dbx strlen core
Reading strlen
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0xff2b44e4: strlen+0x0080: ld [%o1], %o2
Current function is main
8 printf("\nString length = %d", strlen(string));
(dbx) print $o1
$o1 = 0
(dbx) where
[1] strlen(0x0, 0x0, 0x36a2c, 0x7efefeff, 0x81010100, 0xff3cdc4c), at 0xff2b44e4
=>[2] main(), line 8 in "strlen.c"
(dbx) whatis string
char *string;
(dbx) examine string
0x00000000: 0x00000000
(dbx) regs
current frame: [2]
g0-g1 0x00000000 0x00000000 0x00000000 0xff2b4464
g2-g3 0x00000000 0x00000000 0x00000000 0x00000000
g4-g5 0x00000000 0x00000000 0x00000000 0x00000000
g6-g7 0x00000000 0x00000000 0x00000000 0x00000000
o0-o1 0x00000000 0x00000000 0x00000000 0x00000000
o2-o3 0x00000000 0x00036a2c 0x00000000 0x7efefeff
o4-o5 0x00000000 0x81010100 0x00000000 0xff3cdc4c
o6-o7 0x00000000 0xffbff8b8 0x00000000 0x00010c14
l0-l1 0x00000000 0x00000000 0x00000000 0x00010c70
l2-l3 0x00000000 0xff342070 0x00000000 0x00000000
l4-l5 0x00000000 0x00000000 0x00000000 0x00000000
l6-l7 0x00000000 0x00000000 0x00000000 0xff3ee7c4
i0-i1 0x00000000 0x00000001 0x00000000 0xffbff984
i2-i3 0x00000000 0xffbff98c 0x00000000 0x00020c00
i4-i5 0x00000000 0x00000000 0x00000000 0x00000000
i6-i7 0x00000000 0xffbff920 0x00000000 0x000107d0
y 0x00000000 0x00000000
ccr 0x00000000 0xfe400006
pc 0x00000000 0x00010c14:main+0x14 call strlen [PLT] ! 0x20cdc
npc 0x00000000 0xff2b44e8:strlen+0x84 inc 4, %o1
Observe that
dbx
is actually showing six arguments (addresses) instead of just one argument that is the address of the string being passed to this routine. These six arguments are the registers
%o0
to
%o5
which hold the
outgoing arguments. You can match the arguments to
strlen()
in the call stack with the addresses in
regs
output. Note that the registers
%i0
to
%i5
hold the
incoming arguments.
How to prevent the crash?The recommended way is to modify the source code. The quick and dirty way is to pre-load the Solaris specific
/usr/lib/0@0.so.1
library into process address space.
/usr/lib/0@0.so.1
is an user compatibility library that Sun started shipping with Solaris 2.6, provides a mechanism that will cause location
0x00000000
{for 32-bit processes} to be mapped to a valid address containing the value
0
. Note that the address
0x00000000
(or
0x0
in short) of the virtual address space is not mapped, by default.
eg.,
% setenv LD_PRELOAD_32 /usr/lib/0@0.so.1
%./strlen
String length = 0
Read man page of run-time linker,
ld.so.1, for more.
Acknowledgements:
Jim Fiori
___________________
Technorati tags:
Solaris |
Open Solaris |
dbx