application dumping core during system reboot

[Srimalik]

I was not able to post any message to this forum during the whole day. It always failed saying " some error(which i dun remember - please try again"

The root cause of problem is:
We were using basename with argv[0] of original program and passing the same argv[0] to execvp.

The fact that man page of basename warns about this situation was ignored.

basename was changing ./vxsvc to "vxsvc" and /opt/VRTSob/bin/vxsvc "vxsvc"

passing the dup of string to basename and preserving original argv[0]. solves the problem

I am yet to find out that whether argv[0] is changed or kept unchanged by basename on the system on which this problem is not reproducible.

the problem with basename is across all the platforms, Is it smthing which is difficult to fix(I do not think so..and may be wrong)?

The man page of basename say smthing like
basename may change the argument passed.

Why is this behaviour inconsistent in case of single threaded programes ?

Dennis, I have raised the suggestion given by you in previous post to HP.

I will request them to preserve the setup on the machine on which this is reproducible, In case if u or somebdy from HP want to have a look at it.

Thanks
Sri

[Dennis Handly]

>The root cause of problem is:
We were using basename with argv[0] of original program and passing the same argv[0] to execvp.

Ah, you weren't doing it on purpose.

>I am yet to find out that whether argv[0] is changed or kept unchanged by basename on the system on which this problem is not reproducible.

It should be simple to test. Use tusc -pa ...

>the problem with basename is across all the platforms, Is it something which is difficult to fix?

It won't be changed because the Standard says it can do that. Though I would only expect dirname(3) to modify the string.

>Why is this behaviour inconsistent in case of single threaded programs?

It shouldn't. Single threaded apps use a separate buffer but threaded uses the input buffer.

>I have raised the suggestion given by you in previous post to HP.

Thanks.

>I will request them to preserve the setup on the machine on which this is reproducible, In case

No need, we know the problem now.

[Srimalik]

The points :)

[Srimalik]

Dennis, any idea why it didn't fail on all the installations?

I am trying a sample program which can repro this issue.

[Dennis Handly]

>any idea why it didn't fail on all the installations?

Perhaps it had "." in PATH?

[Srimalik]

No "." is not in path.

[Dennis Handly]

>No "." is not in path.

Then you'll need to use tusc -a to see why it works.

[Srimalik]

Attached the program - It workes on the machine on which the original problem can not be duplicated.

It does not work on the machine on which vxsvc dumps core.

steps to repro:

1. extract the file in /
2. goto /exec_test
3. rm test_file ( this decides the calling of execv function)
4. ./exec_test ( will dump on some machines)

[Dennis Handly · Accepted solution]

>It works on the machine on which the original problem can not be duplicated.

It will "work" and not abort if you don't have the fix for JAGag39684 in PHSS_35383, PHSS_36342 or PHSS_36349.

>1. extract the file in /
>2. goto /exec_test

I copied it elsewhere and edited the source and it worked because I don't have the patch.
You can't do 2, you must execute from some other location, otherwise you won't be exercising the "fix". Otherwise the old code tried PWD and that would work if you hadn't moved from the initial build location.

Anyway, when you contact the Response Center you can mention my name as having the details.

[Srimalik]

yes, After Installation of PHSS_37202 the program started dumping on the other machine also.

I have told my POCs to tell their POC in HP that "Dennis Handly has got a good hold on this problem".

Somebdy may contact you very soon.

Thanks
Sri

[Dennis Handly]

>Somebody may contact you very soon.

Ok, I'll explain it to them.
And as I said initially, you'll need to make sure that argv[0] is the absolute path.

I found at the place where the signal occurs is an assert which doesn't go to customers.

[Srimalik]

Hi, Dennis

Did you get the request? Or sombdy else fixed it?


Thanks
Sri

[Dennis Handly]

>Did you get the request? Or somebody else fixed it?

It isn't fixed yet. I assume they are waiting for a but report from the Response Center. Did you contact them?

[Srimalik]

I did ask my POC to contact HP regarding this. I also provided the sample program.

But I do not think the request will come through response center...It will take some other channel(We didn't file it as customers but HP partners).

Presently she is on leave I will ask her about it when she is back.


Thanks
Sri

[Srimalik]

BTW, cann't you guys fix it just because you know the problem and the solution.

OR

there should be a customer request corresponding to each fix.

[Dennis Handly]

>can't you guys fix it just because you know the problem and the solution.

I sent them a pointer to this thread.

>there should be a customer request corresponding to each fix.

Yes, this is always helpful.
But in any case, you need to fix your application, the "fix" is just to have a better error message, instead of the abort.

[Srimalik]

I have already fixed the application ...and it runs happily.

[Srimalik]

Closing this.