information about resources of actual application

Fernando RUIZ CASAS correo at
Thu Sep 27 20:24:47 UTC 2001


> -----Mensaje original-----
> De: Jan.Suchotzki at [mailto:Jan.Suchotzki at]
> Enviado el: jueves, 27 de septiembre de 2001 15:08
> Para: fernando.ruiz at; rtems-users at
> Asunto: RE: information about resources of actual application
> Hi,
> >With CPU_usage_dump() you can see this.
> >With malloc_dump() you can see the memory usage.
> The function CPU_usage_dump() works fine and helps a lot.
> But I run in trouble with malloc_dump(). When I call this
> function nothing happens. I saw that I went into a version of
> malloc_dump()
> with an empty body (only return) while debugging my application.
> I recognised, that the right version (which makes some output) of
> malloc_dump()
> will be called only if RTEMS_DEBUG is defined.
> I have compiled and installed my Snapshot with VARIANT=DEBUG and
> compile my
> appilcation with make debug. I´ve included rtems/libcsupport.h for
> malloc_dump().

This was my way to locate any errors. Patch the sources.

> Can somebody tell me why it didn´t work? I try to execute it with the
> m68k-efi332 bsp.
> >In my shell.c I can exec interactively these functions and tasks and more
> >to examinate the cpu load, task list, memory usage, number of resources
> >used...
> I´ve tried it out, but also here are some problems. I´ve found an example
> application you posted to the list on 7.9.2001. It´s for a pc386 BSP but I
> think
> with some modification it should work on a m68k BSP too.

Of course.

> The first problem was the configure_memory_overhead 16386. I´ve deleted
> this line
> because my application crashed. When I run the example I see one line on
> the console
> with some hieroglyphic characters. But I didn´t see a prompt and
> I can´t do
> some
> inputs.
> Do you have an idea what happens?
Is you console ready to show characters before call the shell_init()?
The hieroglyphic are usually a problem of baudrate, parity, etc...
Printf a "hello world" and flush the stdout before call shell init() and
test this problem.

Execute a termios test in the tests subdirectory and try that your driver
is a real termios driver.

A little patch has been sended to Joel in order to avoid a
test in NULL file pointer when the password is read.

--------------- EMAIL -----------------------------


In file c/src/libmisc/shell/shell.c near line 292 I think there should be a
check to make sure that FILE* out is not NULL before calling
tcdrain(fileno(out)) (out is NULL when entering a password).

Unless I'm mistaken (again!) this is still a problem in snapshot


/* ----------------------------------------------- *
 * TODO: Add improvements. History, edit vi or emacs, ...
 * ----------------------------------------------- */
int shell_scanline(char * line,int size,FILE * in,FILE * out) {
  int c,col;
  if (*line) {
   if (out) fprintf(out,"%s",line);
  tcdrain(fileno(in ));
  if( out )

Surrey Satellite Technology Limited
The views expressed in this email are my own(isn't that reassuring?)

---------------- EMAIL ----------------------------

* shell_scanline(FILE * in,FILE * out) doesn't test the NULL case for the
password read.

In tasks.c in rtems core a little bug produces a crash when the shell task
is finished.

Pass the 'forever' parameter always TRUE to avoid this.

Have you build the pc386-rtems?. Cheap, easy and wonderful to try the
A Grub image diskette (MS-FORMAT). you put the init.exe file and reboot the
You can test the software in other environment before searching the bugs in
your sources.

My first developement was for the sh-rtems. There the shell was developped
and once developped
it was moved to rtems generic tree.

home: correo at
work: fernando.ruiz at

More information about the users mailing list