PA Risk Executable on Itanium Server

[Srimalik]

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


Did you try this thing ?

[Rao Uppuluri]

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

I can't debug at that level (I don't know how, I am calling a 3rd party library and program crashes)

[Srimalik]

I thought its your code as the stack shows many fnc_**** names.

Just to confirm, is fnc_InitDgn your code or its also in some third party library? which third party library?

May be I am confused by the naming convention used.

From where did you get the third party libraries with debugging symbols?

PS: Every answer does not deserve 10 points

http://forums11.itrc.hp.com/service/forums/helptips.do?#28

[Rao Uppuluri]

No, fnc_InitDgn is not in my code. I am guessing it is coming from 3rd party(An accounting software function calls) or from HP library.

I compiled the code on PA with -g option and debugged it on Itanium using wdb and from that session I am getting all the info you see here.

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! ( I have seen similar behaviour with some VB code but never understood why)

Tks
Rao

[Srimalik]

Hi, Rao
Its very strange that the 3rd party is giving you libs with full debugging symbols. Not many vendors do this(never seen this for any HP library). Are you intentionally using debug version of the third party libs?


anyway, If you know who own this lib and have a support contract; you can involve them to look into this. You can show them the stack and provide them the core file.

as a call to fnc_mbStrLen("") from fnc_StrLen("\n") seems fishy to me \, I am wondering why would somebody do that?

-Sri

[Srimalik]

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

[Rao Uppuluri]

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?

-Tks
Rao

[Dennis Handly]

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