64-bit program segmentation fault

[Ravil Bikmukhametov]

Hello.

I use HP-UX in two servers: PA-RISC and IA64
I compile one 64-bit program with aCC compiler.
When i run program, it create core file with error "Segmentation Fault".
In gdb I see next:

bash-3.00$ gdb pvm
HP gdb 5.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) b 363
Breakpoint 1 at 0x4000000000018800:1: file ../../console/cons.c, line 363 from /home/ravil/local/pvm/lib/hppa/pvm.
(gdb) r
Starting program: /home/ravil/local/pvm/lib/hppa/pvm

Breakpoint 1, main (argc=1, argv=0x9ffffffffffff5f0)
at ../../console/cons.c:363
363 aliases = TALLOC(1, struct alias, "alias");
(gdb) print aliases
$1 = (struct alias *) 0x0
(gdb) n
364 BZERO((char*)aliases, sizeof(struct alias));
(gdb) print aliases
$2 = (struct alias *) 0x1df30
(gdb) print *aliases
Error accessing memory address 0x1df30: Bad address.
(gdb) n

Program received signal SIGSEGV, Segmentation fault
si_code: 1 - SEGV_MAPERR - Address not mapped to object.
0x9fffffff7c0a72a0:0 in memset+0x140 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0x9fffffff7c0a72a0:0 in memset+0x140 () from /usr/lib/hpux64/libc.so.1
#1 0x9fffffff7c05d290:0 in bzero+0x30 () from /usr/lib/hpux64/libc.so.1
#2 0x4000000000018880:0 in main (argc=1, argv=0x9ffffffffffff5f0)
at ../../console/cons.c:364
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q
bash-3.00$

What is wrong?

[Don Morris_1]

Well, given that user allocated data on IPF HP-UX should start at 0x60000000'00000000, I
really doubt that TALLOC() [whatever it is] worked unless you're allocating shared address space using mmap() or shmget/shmat() under that macro.

Garbage in, garbage out.

What's TALLOC()? If its a custom allocation wrapper (as I suspect), does it check for allocation failure cleanly (as I suspect it doesn't)?

[Ravil Bikmukhametov]

TALLOC is wrapper for malloc (macros):

#define MY_ALLOC(n,g) malloc((unsigned)(n))
#define TALLOC(n,t,g) (t*)MY_ALLOC((n)*sizeof(t),(g))

I try to use malloc() without this wrapper - also "Segmentation Fault".

[A. Clay Stephenson]

Your ALLOC macros are rather scary. It appears that your TALLOC macro is kinda, sorta a calloc() but without calloc()'s implicit alignment. Consider allocating a array of odd-sized structs; you could have very serious alignment problems. In any event, I would make the compiler stop at the preprocess phase and have a look at how your macros are actually being instantiated.

[Ravil Bikmukhametov]

aliases = TALLOC(1, struct alias, "alias");

After preprocessing phase:

aliases = (struct alias*)malloc((unsigned)((1)*sizeof(struct alias)));

[Don Morris_1]

Ok... so you're getting garbage from malloc() itself... which says to me "Corrupted the heap". Check the code before that point for double frees or buffer overrun/underruns.

I think Purify would help here (http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,282,00.html) - it looks like there's an evaluation period if you don't have it already and want to try it out.

Barring that, I'd be looking at the flow of execution prior checking for double frees, buffer over or underruns.

[Ravil Bikmukhametov]

I analyse the heap in program.

-bash-3.00$ gdb pvm
Detected 64-bit executable.
Invoking /opt/langtools/bin/gdb64.
HP gdb 5.4.0 for PA-RISC 2.0 (wide), HP-UX 11.00
and target hppa2.0w-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.4.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) b 364
Breakpoint 1 at 0x400000000000e958: file ../../console/cons.c, line 364 from /home/ravil/local/pvm/lib/hppa/pvm.
(gdb) set heap-check on
(gdb) r
Starting program: /home/ravil/local/pvm/lib/hppa/pvm

Breakpoint 1, main (argc=1, argv=0x800003ff7fff0920) at ../../console/cons.c:364
364 aliases = (struct alias*)malloc(1*sizeof(struct alias));
Current language: auto; currently c++
(gdb) n
365 BZERO((char*)aliases, sizeof(struct alias));
(gdb) info heap
Analyzing heap ...


48 bytes allocated in 1 blocks

No. Total bytes Blocks Address Function
0 48 1 0x8000000100868c68 main()
(gdb) print aliases
$1 = (struct alias *) 0x868c68
(gdb) print sizeof(aliases)
$2 = 8
(gdb)

malloc() work correctly, but assign wrong value to pointer (aliases)
If I manual set in gdb correct address (0x8000000100868c68) to pointer
(set aliases=0x8000000100868c68), program work correctly (until next memory allocation)

Where the problem?

[A. Clay Stephenson]

Notice that the low-order 4 bytes are correct. It looks as though you have a type mismatch because the hi-order 4 bytes are being discarded.

[Ravil Bikmukhametov]

..
(gdb) b 364
Breakpoint 1 at 0x400000000000e948: file ../../console/cons.c, line 364 from /home/ravil/local/pvm/lib/hppa/pvm.
(gdb) set heap-check on
(gdb) r
Starting program: /home/ravil/local/pvm/lib/hppa/pvm

Breakpoint 1, main (argc=1, argv=0x800003ff7fff0920) at ../../console/cons.c:364
364 printf("Malloc: 0x%lx\n",malloc(48));
Current language: auto; currently c++
(gdb) n
Malloc: 0x8000000100868c88
365 unsigned long ptr = malloc(48);
(gdb) n
366 printf("Malloc: 0x%lx\n",ptr);
(gdb) n
Malloc: 0x86ad18
367 aliases = (struct alias*)malloc(1*sizeof(struct alias));
(gdb) print ptr
$1 = 8826136
(gdb)

When I print malloc() return value, 64-bit value printed, if I at first assign malloc() return value to unsigned long variable, 32-bit value printed.

Why so?

[Don Morris_1 · Accepted solution]

Did you include in this file? (And when you compile, is there any warning about no definition for malloc, assuming return type of "int" perchance?

If you don't include the proper header to define a function in C, the compilers will assume a return type of int. So malloc returns an int, which gets cast to an unsigned long (or a pointer) -- but you've already been truncated. [printf gets away with this due to the difference in how it uses argument definitions compared to lvalues... I don't remember details and its way too late to go look right now... ask on comp.lang.c if you want gory details...]

To whit:

# more bad.c
#include

int
main(int argc, char *argv[])
{
uintptr_t ptr = NULL;

printf("Malloc: 0x%lx\n", malloc(48));

ptr = malloc(48);

printf("ptr got: 0x%lx\n", ptr);

exit(0);
}

# cc +DD64 -o bad bad.c
# ./bad
Malloc: 0x80000001000042b0
ptr got: 0x6310

# more good.c
#include
#include

int
main(int argc, char *argv[])
{
uintptr_t ptr = NULL;

printf("Malloc: 0x%lx\n", malloc(48));

ptr = malloc(48);

printf("ptr got: 0x%lx\n", ptr);

exit(0);
}
# cc +DD64 -o good good.c
cc: "good.c", line 11: warning 526: Pointer implicitly converted to integral value in assignment.
# ./good
Malloc: 0x80000001000042b0
ptr got: 0x8000000100006310