1748287 Members
2982 Online
108761 Solutions
New Discussion юеВ

Re: execve failure

 
Dennis Handly
Acclaimed Contributor

Re: execve failure

>[5509] exit(9) [implicit (execve failure)] . WIFEXITED(9)

I don't get this for a bad executable, I get errno 2.
What HP-UX version do you have? What tusc version?
Are you in a 32 bit process? Are you using Aries?

>The error displayed by tusc on terminal refers to the arguments of execve.
tusc: ttrace(TT_PROC_RDDATA, 5509, 0, 600000000001cfb0, 4, 9fffffffffffecb0): Bad address

Hmm, they didn't match the first time. But it appears tusc can display the parms.
Chris Bertin
Occasional Advisor

Re: execve failure

Tusc reports an "implicit" exit when it gets an EXIT event but the syscall that resulted in the exit is not an exit syscall. If the TTS_INSYSCALL bit is set in the event flags, tusc reports which syscall caused the exit.

Another example is doing a 'tusc sleep 100' and killing the sleep command with a SIGHUP. Tusc will report:

exit(1) [implicit (sigtimedwait failure)]................ WIFSIGNALED(SIGHUP)

--
Regards, Chris (Chris Bertin, chris.bertin@hp.com)
Chris Bertin
Occasional Advisor

Re: execve failure

Looking back at this and reading more of the thread, I should have also said, to follow up on the "bogus and why not show ..." comment, that errno not necessarily == exit value. If the process exits with an unexpected EXIT event, it's not a syscall event, i.e. there are no arguments to report, no errno. Just an exit value (which is interpreted using the encoding described in wait.h. Hence, exit(9), which doesn't necessarily have anything to do with errno 9.

Also, wrt the fact that tusc reports a ttrace error when reading some syscall arguments, it would indicate to me that the arguments are invalid. Which would somehow correlate to an exec failure in this case, IMHO.

So, either the program is passing bogus pointers to exec or the memory these pointers point to is being stepped on before the syscall.
Dennis Handly
Acclaimed Contributor

Re: execve failure

>What does this indicate?

From what Chris said and the source, the problem is that execvp(2) has problems with the executable or getting memory for the process so it calls exit(SIGKILL).

Can you do this from the shell: /crsvol/bin/ohasd reboot

If you hadn't redirected stderr, you may have seen these message:
exec(2): insufficient swap or memory available.
exec(2): could not load a.out
exec(2): Could not load a.out due to swap reservation failure or due to insufficient user stack size
Chris Bertin
Occasional Advisor

Re: execve failure

The message is a 'uprintf' and will go to the terminal, if there is one, regardless of stdout/err. 'uprintf' messages from the kernel cannot be redirected. The characters get pushed directly onto the tty queue.

The kernel message is also misleading. It will happen any time a 'copyout' fails (copyout copies data from kernel space to user space). Considering the fact that tusc can't read the exec arguments, I'd say that the issue is corruption of the binary, not lack of space.