Unix Systems Programming Newbie - exec format error

[Gabriel]

I'm writting a C/sockets client interface on Solaris. I've based the
design in already existent code and I've reused most of it, learning
how it works on the fly.

Basically, I have a parent process that creates a client socket and
connects to a server, then using fork() for creating two child
processes, one for receiving and another one for sending info on that
socket client connection.

After fork(), I use execl in the parent code to invoke the child
processes. These three processes communicate with each other using
signaling.

The thing is that from inside the receaving process I'm (randomly)
catching a signal (almost sure is SIGVTALRM - I'm reusing a common
library function to catch and log errors, which I didn't have time to
fully trace yet) with the following error "errno 8: Exec format
error".

How's it possible I'm getting this error from inside a process that
doesn't call to exec or execl at all?

Any help would be very much appreciated.

Cheers and thanks in advance,

Gabriel.

[Barry Margolin]

In article <c9b7e912.0307071029.4e8486ed@posting.google.com >,
Gabriel <gabielex@hotmail.com> wrote:

>I'm writting a C/sockets client interface on Solaris. I've based the
>design in already existent code and I've reused most of it, learning
>how it works on the fly.
>
>Basically, I have a parent process that creates a client socket and
>connects to a server, then using fork() for creating two child
>processes, one for receiving and another one for sending info on that
>socket client connection.
>
>After fork(), I use execl in the parent code to invoke the child
>processes. These three processes communicate with each other using
>signaling.
>
>The thing is that from inside the receaving process I'm (randomly)
>catching a signal (almost sure is SIGVTALRM - I'm reusing a common
>library function to catch and log errors, which I didn't have time to
>fully trace yet) with the following error "errno 8: Exec format
>error".
>
>How's it possible I'm getting this error from inside a process that
>doesn't call to exec or execl at all?

What function are you calling that's reporting this error? Can you show us
some of the code that has this problem?

My guess is that you're looking at errno when you shouldn't be, i.e. when a
function hasn't indicated an error.

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[Marc Rochkind]

On 7 Jul 2003 11:29:26 -0700, Gabriel <gabielex@hotmail.com> wrote:

[snip]

>
> The thing is that from inside the receaving process I'm (randomly)
> catching a signal (almost sure is SIGVTALRM - I'm reusing a common
> library function to catch and log errors, which I didn't have time to
> fully trace yet) with the following error "errno 8: Exec format
> error".
>

[snip]

I don't understand this part. What do you mean "catching a signal ... with
the following error?"

errno is not set when a signal is caught. Are you trying to access errno
from within the signal handler? If so, you are probably picking up some
meaningless random value.

Can you be more precise about exactly what is going on?

--Marc

[Marc Rochkind]

On 8 Jul 2003 06:35:29 -0700, Gabriel <gabielex@hotmail.com> wrote:


[snip]

>
> This function accepts an int as its only argument. It sets a variable
> called "errno" to the received value and then calls another funcion
> that uses strerr(errno) to retrieve its desc and log the error number
> and desc into a file. Because it uses the system call strerr(), I
> assumed (wrongly probably?) that the int passed as argument to the
> signals handler, FV_CO_CAPTURAR_ERROR_SISTEMA() was the value, errno
> is set to, when a System error occurs.
>

Some comments:

1. There are two function forms. The traditional one takes only one
argument, which is the signal number that caused the handler to be called,
not an errno value. The second form has three arguments, but it sounds like
your code is using the first form.

2. Don't use signal. It's obsolete and has several defects that sigaction
fixes.

3. For some signals, you can indeed get the errno that caused the signal,
with the three-argument function call. Look at the documentation for
sigaction and you'll see that you can set sa_sigaction instead of
sa_handler, with the use of the SA_SIGACTION flag.

--Marc

[Gabriel]

Barry Margolin <barry.margolin@level3.com> wrote in message news:<aqjOa.13$Vb2.5@news.level3.com>...

> In article <c9b7e912.0307071029.4e8486ed@posting.google.com >,
> Gabriel <gabielex@hotmail.com> wrote:

> >I'm writting a C/sockets client interface on Solaris. I've based the
> >design in already existent code and I've reused most of it, learning
> >how it works on the fly.
> >
> >Basically, I have a parent process that creates a client socket and
> >connects to a server, then using fork() for creating two child
> >processes, one for receiving and another one for sending info on that
> >socket client connection.
> >
> >After fork(), I use execl in the parent code to invoke the child
> >processes. These three processes communicate with each other using
> >signaling.
> >
> >The thing is that from inside the receaving process I'm (randomly)
> >catching a signal (almost sure is SIGVTALRM - I'm reusing a common
> >library function to catch and log errors, which I didn't have time to
> >fully trace yet) with the following error "errno 8: Exec format
> >error".
> >
> >How's it possible I'm getting this error from inside a process that
> >doesn't call to exec or execl at all?

>
> What function are you calling that's reporting this error? Can you show us
> some of the code that has this problem?
>
> My guess is that you're looking at errno when you shouldn't be, i.e. when a
> function hasn't indicated an error.

Sorry, it took me a while to reply.

Yes Barry, you're right, errno has nothing to do with this.

Got a chance to introduce some trace messages and confirmed what Marc
said above. The library function I'm using was totally confusing me as
they use the function signal() and then the handler on the form
signal_handler(int), which takes the signal number as only argument,
as Marc said. Kind of this:

singal_handler(int value) {
errno = value;
logError(value, ....);
}

Then, logError() uses strerror(errno) to retrieve the "error" desc,
which is actually the signal number, so the message traced into the
log has nothing to do with the actual error. As I'm starting with all
these things such as signals, sockets, etc, this was driving me crazy.

I should just forget about using this library for error management,
but just have not time to do it now. Also, I don't want to mess with
it changing the signal handling from signal() sigaction() (which I
agree with you Marc should be done), because too much code all over
the place is alreday using it.

Now, found the actual cause of my crashing, which WASN'T "ERRNO 26
Text File Busy" as that crappy code I'm using said, BUT "SIGTTIN 26
Stop Stopped(tty input)", which is also a really funny crashing.
Having a look at the post messages, found out that this only happens
when I launch the script that initializes my sistem on the background.
I'll have a further look at the group messages to find out why, before
bothering anyone again.


Thanks very much to both for your help.

Cheers,

Gabriel.

[Gabriel]

Btw,

The error message I just made reference above, wasn't the one I
mentioned in the first messages, but another that occured later.

That "exec format error: 8" I mentioned was actuallly SIGFPE
"Arithmetic Exception". I was dividing by 0 - I'm a rookie...

[Paul Pluzhnikov]

[email]gabielex@hotmail.com[/email] (Gabriel) wrote in message news:<c9b7e912.0307110545.6d0b79f5@posting.google. com>...

> singal_handler(int value) {
> errno = value;
> logError(value, ....);
> }
>
> Then, logError() uses strerror(errno) to retrieve the "error" desc,

Note that strerror() is not async-signal-safe and its use in an (async) signal
handler invokes undefined behaviour. Your program may crash or self-deadlock
at the most inopportune moment ;-(

Cheers,

[Gabriel]

[email]ppluzhnikov@earthlink.net[/email] (Paul Pluzhnikov) wrote in message news:<e5693d93.0307150855.4686ab2e@posting.google. com>...

> [email]gabielex@hotmail.com[/email] (Gabriel) wrote in message news:<c9b7e912.0307110545.6d0b79f5@posting.google. com>...
>

> > singal_handler(int value) {
> > errno = value;
> > logError(value, ....);
> > }
> >
> > Then, logError() uses strerror(errno) to retrieve the "error" desc,

>
> Note that strerror() is not async-signal-safe and its use in an (async) signal
> handler invokes undefined behaviour. Your program may crash or self-deadlock
> at the most inopportune moment ;-(
>
> Cheers,

Good to know. This just reafirms my theory tha the common library code
I'm using for errors and sytem signals handling is crap. Anyway, this
strerror() call shouldn't present any problem in this case, as it is
only used in signal handlers that cause the program to exit (by the
way, without cleaning-up resources).

As I said, crappy code. I should take some time in rewritting it. Will
do.... in a near future.

Thanks very much.

[Paul Pluzhnikov]

[email]gabielex@hotmail.com[/email] (Gabriel) writes:

> Anyway, this
> strerror() call shouldn't present any problem in this case, as it is
> only used in signal handlers that cause the program to exit (by the
> way, without cleaning-up resources).

If "hanging forever while trying to exit" or "crashing in error-log
code while trying to log the reason for exiting" are acceptable,
then indeed this "doesn't present any problem" ;-)

Cheers,
--
In order to understand recursion you must first understand recursion.