topic Re: 64-bit program segmentation fault in Operating System - HP-UX

64-bit program segmentation fault

Ravil Bikmukhametov — Tue, 15 Aug 2006 07:04:43 GMT

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?

Re: 64-bit program segmentation fault

Don Morris_1 — Tue, 15 Aug 2006 10:58:24 GMT

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)?

Re: 64-bit program segmentation fault

Ravil Bikmukhametov — Tue, 15 Aug 2006 22:36:56 GMT

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".

Re: 64-bit program segmentation fault

A. Clay Stephenson — Tue, 15 Aug 2006 22:50:52 GMT

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.

Re: 64-bit program segmentation fault

Ravil Bikmukhametov — Tue, 15 Aug 2006 23:54:11 GMT

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

After preprocessing phase:

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

Re: 64-bit program segmentation fault

Don Morris_1 — Wed, 16 Aug 2006 10:52:38 GMT

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.

Re: 64-bit program segmentation fault

Ravil Bikmukhametov — Wed, 16 Aug 2006 23:03:41 GMT

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?

Re: 64-bit program segmentation fault

A. Clay Stephenson — Wed, 16 Aug 2006 23:26:05 GMT

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.

Re: 64-bit program segmentation fault

Ravil Bikmukhametov — Thu, 17 Aug 2006 00:18:02 GMT

..
(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?

Re: 64-bit program segmentation fault

Don Morris_1 — Thu, 17 Aug 2006 00:29:20 GMT

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

Re: 64-bit program segmentation fault

Ravil Bikmukhametov — Thu, 17 Aug 2006 01:02:42 GMT

Thank you very much for help.

Insert #include - work!!!

Re: 64-bit program segmentation fault

Ravil Bikmukhametov — Thu, 17 Aug 2006 01:05:33 GMT

Thank you all for help

Re: 64-bit program segmentation fault

Tom Henning — Thu, 17 Aug 2006 05:29:59 GMT

Ravil:

I know the thread is closed and I will get no points for this, but I was going to add this comment yesterday before I got pulled away.

1. Never cast the return of malloc/calloc calls. This will mask the error you encountered every time. The cast is not required.

2. Always, always, always check the return from a molloc/calloc call to ensure that the call worked.