Checking the size of the stack using HP aCC

[Andrew Herrmann]

Is there a way that I can view the size of the stack and the amount of memory available on the stack at various points within my code?

I don't think there's a standard C/C++ function to do this.

I'm receiving a "Bus error" at a point in my code where a variable is "created" (instantiating a class) . I'm trying to figure out whether something is getting corrupted due to a stack overrun or whether the problem lies somewhere else.

Thanks,

Andy

[Olav Baadsvik]

Hello,

You may use the function mallinfo to
see how much memory your program has
allocated.
To know how much more you can allocate you
will need to know the value of the kernel-parameter maxdsiz.
Lack of swap-space could also be a problem.

Olav

[Olav Baadsvik]

Hello again,

The struct pst_status returned from
pstat_getproc also has a lot of interesting
info, like pages used for data, pages used
for stack etc.

Olav

[Paddy_1]

to find the location of the stack run this small program
main()
{
int i;
printf("The Stack Top is near %#X\n",&i);
}
also run
%echo;echo "text data bss total"; size a.out
to look for different segment sizes.

I would typically use a debugger like "gdb" for this kind of diagnostics.

A Bus Error typically means a misalignment.That is somewhere something funky happened.Mostly as a result of irregular memory allocation.

[Andrew Herrmann]

It looks like mallinfo returns information about the heap, not the stack. I'm still looking into the pstat_getproc to see if that will help.

Thanks,

Andy

[Andrew Herrmann]

Here's a good one for you -- Maybe I should post this as another thread. I tried using gdb on this application:

$gdb filename
(gdb) b main
Abort(coredump)

Strange, huh? Now how do you go about debugging that :(

[Adam J Markiewicz]

Hi

gdb also has some bugs, unfortunately - nothing really new.

But I think you can try run the program even without this breakpoint. It should be stopped by gdb at the moment of signal generation.

[Benedict Adamson]

I came across a bus error the other day. My first for about a decade. As the compiler is guaranteed to produce well-aligned memory references, I had always thought that bus errors indicated that the object code (.o) files were inconsistent, so we recompiled everything. It made no difference.

The failing program had been compiled with a high optimisation level, so we recompiled it without optimisation and with debugging information, hoping to get more clues using the debugger. Interestingly, it then failed with a SIGSEGV instead of a bus error and we could immediately locate a (the?) fault. Perhaps the compiler optimisations can transform a segmentation-violation into a bus error? (Compiler Writer's Motto - Optimization Pass: Making a wrong program worse is no sin- Bill McKeeman, Wang Institute)