PA-RISC Executable on Integrity server

[Rao Uppuluri]

Thank you all for quick responses.

* I can't really re-compile on Itanium because I am using a third party library calls and they are not supported under Itanium. So, I really want to compile it under PA Risk and run it on Itanium. If it helps, I ran this same PA executable on a different Itanium server (located at a diff location in the company) and it works! That server is also has 11iv2. Couldn't really figured out the differences between our servers yet.

Dennis,
>The real problem is on line 1029 of multibyte.c. What's on that line?
>Since the executable has debug info, why not use it? ;-)

Can you please elobarate on how I can examine this issue?
Thank you

[Dennis Handly]

>I ran this same PA executable on a different Integrity server and it works! That server is also has 11iv2. Couldn't really figured out the differences between our servers yet.

Check the patch levels of Aries, libc and linker.

>>The real problem is on line 1029 of multibyte.c. What's on that line?

>Can you please elaborate on how I can examine this issue?

I assume you have the source file multibyte.c?
Otherwise you could do "info locals".

Or you can debug at machine level:
(gdb) disas $pc-4*20 $pc+4*4
(gdb) info reg

[Rao Uppuluri]

Dennis
I am getting the patch info for linker,aries and libc.
I don't have source for multibyte.c ( there is a manpage for multibyte).
when I tried the steps you provided in gdb, it provided output that I can't comprehend.

TFYH
Rao

[Dennis Handly]

>I don't have source for multibyte.c (there is a manpage for multibyte).

The man page for multibyte(3C) is HP's code. fnc_mbStrLen is your code.

>when I tried the steps you provided in gdb, it provided output that I can't comprehend.

;-)
Just attach them to the thread and I'll look at them.

[Don Morris_1]

Not to disagree slightly with Dennis as to the pertinence of the address -- but with that address being just over 4Gb, and maxdsiz_64bit defaulting to 4Gb... I can't help but wonder if you did something like realloc() of an array without checking the return for failure and assuming the reallocation succeeded... then walking off the end of the array into unallocated virtual memory.

Based on perusing documentation -- "maint info sections" should dump the executable+core memory ranges... it might be worth seeing what's there (and what isn't). If the data ends at 0x10000000 (or very close... you fail the allocation that pushes you over, it doesn't mean you always get exactly there).. that would fit.

[Srimalik]

Rao,

The top two frames in the stack are:
#########################################
#0 fnc_mbStrLen (string=0x80000001000065d7 "") at multibyte.c:1029
#1 0xc0000000080693b0 in fnc_StrLen (string=0x9fffffffe00033a8 "\n")
at str.c:767
##########################################
In frame 1 (fnc_StrLen) it seems you are trying to calculate the length of string "\n"
which should be 1.

Then from this function you are calling fnc_mbStrLen with a empty string(length 0).
Maybe you should look into this.

Secondly the address passed to both these functions are in different areas(not near each other 0x8000000 and 0x9fffffff).

How does "\n" becomes ""...you need to trace the flow in your code.

Try to find out: how you end up calling fnc_mbStrLen("") from fnc_StrLen("\n").
Note that the parameters are changed.

It may help.

-Sri

[Don Morris_1]

0x9ffffff.... would be at the top of the private octant for data/heap/mmf/stack, so is very likely a stack variable address. 0x80000... is more likely a heap allocation address [or is meant to be but may rather be a bad pointer arithmetic result after a failed allocation, hence my query about a realloc() in this path]. That's because it is near the low end of the octant (where the heap/BSS starts and then grows towards the memory mappings, thread stacks and main process stack that live on the other end and come towards lower addresses).

[Srimalik]

Hi, Don
I am not familiar with the octant concept.
As per your comments
0x80000... should heap area
0x9ffff... should be on stack

I see a different range of address in frame 8
i.e 0xc0000000080.. It lies near to the code seg, are these the environment variables?

It may be off topic for this thread, may not be related to the thread in any way.

[Dennis Handly]

>Don: Not to disagree slightly with Dennis as to the pertinence of the address -- but with that address being just over 4Gb, and maxdsiz_64bit defaulting to 4Gb.

That address is trivially close to the start of the PA64 data area, 26071 bytes.

I'm assuming two things:
1) If 64 bit, it needs more than 4 Gb. ;-)
2) The debugger would give an error when tracing the stack if the "string" had a bad address, rather than just "".
#0 fnc_mbStrLen (
string=0x80000001000065d7 )

This address is big for IPF64 but not for PA64.
Also, the debugger won't complain about bad alignment though.

>Don: Based on perusing documentation - "maint info sections" should dump the executable+core memory ranges.

A better option would just be to use gdb's "info file".

Or better yet, use the command:
$ elfdump -S -o core

>Sri: Try to find out: how you end up calling fnc_mbStrLen("") from fnc_StrLen("\n").
>Note that the parameters are changed.

Yes, looking at the source would help.

>Don: 0x80000... is more likely a heap allocation address

Or a global/static variable. Try using:
info sym 0x80000001000065d7

>Sri: I am not familiar with the octant concept.

(PA has quadrants, IPF has octants. They are related to space or region registers.)

>0x80000... should heap area
>0x9ffff... should be on stack
>I see a different range of address in frame 8. i.e 0xc0000000080.. It lies near to the code seg, are these the environment variables?

No, these are shlib text, or shared memory.

[Rao Uppuluri]

Hello all,

My maxdsiz_64bit is 4GB.

I don't have source multibyte.c, may be it is part of the 3rd party libraries I am using.
I am attaching the gdb and elfdump output.

Thank you