Languages and Scripting
Showing results for 
Search instead for 
Did you mean: 

PA Risk Executable on Itanium Server

Go to solution
Valued Contributor

Re: PA Risk Executable on Itanium Server

>>In any case, looks like no one really surprised by the fact that the exec runs fine through debugger but crashes when run by itself!

Dennis has already provided a couple of possible reasons:

"I've had a few cases where it runs in the debugger. The obvious cases are uninitialized variables.
I've seen other cases where the debugger's private mapping of shlibs causes readonly strings to be writable and then it won't abort. But that should fail on PA too. "
abandon all hope, ye who enter here..
Rao Uppuluri

Re: PA Risk Executable on Itanium Server

OK, I got it( abou why it runs in debugger..Though, exec doesn't fail on PA at all) Also, I have compiled following vendor directions. (At this point I can't ask for help from the vendor)

Also, going back to checking the other Itanium server (where this exec runs without failing), I found that linker, libc and Aries are at a later(higher) patch level on my system.
I have increased the maxdsiz_64bit to 6GB, still got the error.
Are there any other kernel parameters I should check?

Dennis Handly
Acclaimed Contributor

Re: PA-RISC Executable on Integrity server

>I don't have source multibyte.c, may be it is part of the 3rd party libraries I am using.

You can use "info module $pc" to find out which shlib.

>I am attaching the gdb and elfdump output.

Thanks, that says your problem isn't in fnc_mbStrChr at all! You may need a newer PA64 gdb to tell you that.

You are aborting here: pcoqh: c000000008054c98

This shows you are on the first ldd of an import stub. R27/DP is bad:
0xc000000008054c98 <.stub>: ldd -0x2068(%dp),%r1
0xc000000008054c9c <.stub+4>: bve (%r1)
0xc000000008054ca0 <.stub+8>: ldd -0x2060(%dp),%dp

dp: 9fffffffdfeffa10
Does this value show up in the "info shared" list under the dlt column?
You should also try "info module $dp".

This seems to be in this shlib:
CoreMMF 0000000000071ad8 9fffffffdfedf000 0000000000021000 0000000000021000

dp - 0x2068 == 9fffffffdfefd9a8, is still in that shlib.

>Srikrishan: as a call to fnc_mbStrLen("") from fnc_StrLen("\n") seems fishy to me

It's not, gdb is lying to you.

>Aries are at a later (higher) patch level on my system.

Do you have the latest? If not try that. Otherwise try removing the Aries patch you have and install the other one that works.

>I have increased the maxdsiz_64bit to 6GB, still got the error.
>Are there any other kernel parameters I should check?

There is nothing wrong with maxdsiz_64bit. You are using a trivial amount of data:
CoreLoad 0000000000000ad8 8000000100000000 0000000000009000 0000000000009000
CoreStck 0000000000009ad8 9fffffffe0000000 0000000000020000 0000000000020000

Plus the shlibs in CoreMMF.