gdb has duplicate backtrace entries

[jeet_xp]

Hi,
I am debugging a multithreaded program on HPUX(Itanium), this is a 64-bit application.
My program crashes and when I see the stack, I find that it has as many as 80000 frames even I can go to 80000'th frame by saying frame 80000
on gdb prompt. Can you please suggest what is happening out there.

Version of gdb
HP gdb 5.5.1 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x

HPUX version: B.11.23 U ia64 3018900438

[Dennis Handly]

You have a recursive stack overflow.

I assume you do have recursion??

[A. Clay Stephenson]

Yep, this is the absolutely classic symptom of infinite (or nearly so) recursion. Somehow the condition to exit the function is not being met. It could be something as trivial as:
if (a = b)
when you actually intended:
if (a == b)

[Mithun R N]

Hi,

Check out for the improper recursions that have been suggested.
Also ensure that you are using the same versions of the shared libs that were in picture when the core was dumped.
What type of "backtrace" are you getting ?
Do you see the same frame (function, PC, line) being shown from frame-1 to frame-80000 ?

Also try using the latest wdb(5.7) available at
http://www.hp.com/go/wdb.

Regards,
Mithun

[jeet_xp]

I have figured out the problem it was a casting error. A long value was getting trunctated somewhere which infact making one variable in the range of 634992 or something which ideally should be in range of 9-10.
It was worst case of stack overflow I would say. Thanks all for your responses.

Anybody have any idea about how long a stack can grow? how to change the size of stack for a
process.

[Dennis Handly]

>Anybody have any idea about how long a stack can grow? how to change the size of stack for a process.

As big as maxdsiz or maxdsiz_64bit. And further limited by "ulimit -s".

>Or the size of your much smaller thread stack.

You use kctune to change maxdsiz or maxdsiz_64bit. To change the size of a thread stack you use pthread_attr_setstacksize(3) or pthread_default_stacksize_np(3), or an env var PTHREAD_DEFAULT_STACK_SIZE for the right libphread patch.

[Dennis Handly]

You of course can figure out the size of your stack overflow with recursion:
(gdb) frame 0
(gdb) p /x $save_sp = $sp
(gdb) frame 80000 # or more
(gdb) p $save_sp - $sp

[Mithun R N]

Also, try having an alternate stack defined to host the signal handler for stack-overflow conditions.
Refer to man pages for sigaltstack.

Mithun

[Dennis Handly]

It appears you have solved your problem. You should close this thread, so people know that. (There is no bunny.)
And of course, if you want to assign more points, that's fine too. :-)

[jeet_xp]

I found the solution as described in my last post in this thread, thank you all for suggesions.