[uClinux-dev] Re: Apparent memory corruption using ColdFire 5272 (Stuart MacDonald)

Stuart MacDonald stuartm at connecttech.com
Tue Mar 25 12:59:42 EST 2003


From: "Ed Orchard" <edorchard at yahoo.com>
> From: "Ed Orchard" <edorchard at yahoo.com>
> >> I've got some code that runs several tasks by means of vfork(). If I
add
> >> some trivial code it now crashes or behaves strangely. Elsewhere in
> another
> >> task with a few lines of code added that task stops responding - even
> though
> >> those lines of code are not used. It looks like a memory corruption
> problem
> >> so I have doubled the stack size to no avail. Can anyone tell me how to
> find

I agree on the assessment of memory corruption.

> Hardware: Arcturus 5272 Colfire uCdimm (I believe).

I have no knowledge of that specific board, we have the Motorola 5272 eval
board
here.

> The code that spawns a task is:-
> {
>     char    strParam1[10];
>     char    strParam2[10];
>
>     if(0 == (pid = vfork()))
>     {
>         sprintf(strParam1, "%X", param1);
>         sprintf(strParam2, "%X", param2);

Bad programming practice. Use snprintf instead. sprintf can cause buffer
overflows. That might be the problem, but probably not.

>         (void)execl
>             (
>                 "/bin/newtask",
>                 "newtask",
>                 strParam1,
>                 strParam2,
>                 NULL
>             );
>         _exit(0);
>     }
> }
>
> The child has the form:-
> static void   newtask(int param1, int param2);
>
> int main(
>     int     argc,   /* number of parameters */
>     char    **argv) /* command line parameters */
> {
>     int param1;
>     int param2;
>
>     /* This is done in hex as there is/was a fault in sprintf omitting the
> last digit of a negative number */
>     sscanf(argv[1], "%X", &param1);
>     sscanf(argv[2], "%X", &param2);
>
>     newtask(param1, param2);
>     _exit(0);
> }
>
> static void newtask(int param1, int param2)
> {
>     /* main body of child task */
> }
>
> One of the parameters contains an open file descriptor from which I read.

File descriptors are inherited. You don't need to pass them explicitly,
unless
you need to specify because it could be a random one. Here's what I'm doing
in
my app:

launch_child(int fd) {
  pid = vfork()
  if (!pid) {
    dup2(fd, 0);
    close(fd);
    execl();
    _exit();
  } else {
    close(fd);
  }
}

This ensures that the new program's fd 0 is the descriptor, no matter what
the
original one was.

> There is also some error handling which is not shown.
> I also have my own implementation of shared memory which exploits the lack
> of a MMU and has checks to ensure that it writes to the right place.

Have you double checked your shared memory code?

> The remainder of the code (which is probably too lengthy to put here)
parses
> text from either the file descriptor or another fifo and acts on the
> commands via a switch statement. It makes calls to the bootloader to read
> and write parameters from/to the environment.
> Without certain switch statements all is well. Include the extra
statements
> and the following function is entered but never exits:
>
> static void controlAccessNode(int command, int msgSequence, char *token)
>  {
>     switch(command)
>     {
>         case AN_SET_SERVER_ADDRESS:
>             strncpy(shared->config.serverAddress, token, sizeof
> shared->config.serverAddress);
>             updateConfigStr("SERVER_ADDRESS",
shared->config.serverAddress);
>             break;
>
> /* other caes statements here */
>
>         default:
>             ERROR("Unknown command %d", command);
>             break;
>     }
> }

Have you tried compiling to assembler and checking it? It might be useful to
know what does happen instead of exiting.

Have you double checked your ram.ld? It sort of sounds like the extra code
is
pushing exececutable code into another section which is overwritten, like
pushing it into the bss, which is later zeroed out.

Is it any added code that caues this behaviour? ie If you added some useless
non-switch-statements are the beginning of the funciton does it still occur?

> Is this enough to indicate where to look for a problem?

It's better. :-)

What tool chain are you using?

..Stu





More information about the uClinux-dev mailing list