[Linrad] Re: Linrad-02.53

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Hello Sam,

> It's worse than that, I spent a few hours this afternoon with the
> debugger trying to pin down a buffer overflow with Ubuntu 8.10 and gcc
> 4.3.2. Firstly i updated the Makefile to remove the -Werror from the
> gcc options, which allowed xlinrad to compile, after that I got
> persistent buffer overflow errors when xlinrad tried to enumerate the
> alsa configuration. linrad crashes consistently in lsetad.c:148 (the
> 1st sprintf() call). Exactly why this is the case eludes me, the
> debugger showed me the state of alsa_dev_hw_pcm_name  as "
> \000\000\000\000\000\000\000\000" immediately prior to the call, and
> the values of dev and idx as 0, which suggests that the sprintf()
> should only be storing 7 bytes into this array (including the null
> terminator).
alsa_dev_hw_pcm_name should be a blank followed by a zero.
The string is defined to be 10 characters and presumably
the debugger does not show the last "end of string" zero
so what you se is a blank followed by 8 zeroes.
The blank and the first zeor are then OK and what comes 
afterwards does not matter.

> After installing the gcc-3.4 package and rebuilding (with LCC =
> gcc-3.4 in the Makefile), alsa is enumerated correctly. I still get
> fairly common "[1116] thread rx_adinput: short readi" errors. 
What???! "fairly common"?

Nobody has reported that.
The devices are opened in blocking mode and they should never return
any error. They should just stay blocking until the desired 
number of bytes have arrived.

Surely I can get [1116] errors when running Linrad under a debugger,
but I do not see any other reasonable action than just making an
error exit. Should however the [1116] error occur under other
circumstances, it might be a good idea to handle the error one
way or another. There are two alternatives:

1) Fill the remainder of the buffer with zeroes and continue
   as if nothing wrong has happened.
2) Move the buffer pointer and call read again to read the 
   remaining bytes into the buffer.

In case the error is caused by CPU overload (due to another program)
the second strategy would probably be no good at all. In case it is
caused by a response to some signal sent by another program
(to give Linrad a chance to exit) the second strategy should be
the correct solution.

Until I know a little more what is causing the 1116 error Linrad
will just terminate with error message in the hope that some of
you who see it would report it on this mailing list.

I have uploaded lir02-53u.tbz here:
http://www.sm5bsz.com/linuxdsp/linroot.htm
at the bottom of the page.

This version has two global variables:
int zrw;
char *zs;

They are used as the return value for read, fread, write, fwrite 
and fgets to satisfy Ubuntu. The return values are not used for 
anything so the resulting code should not run differently from
the original code. A couple of hundred useless memory operations
every second will not increase the CPU load to the extent that
it could be noticed.

The problem with error 1116 does not occur under oss because 
there is no error checking. The problem exists under native alsa
just because the return code of read statements are checked.
I could change it to do just as I did with the oss interface 
and ignore the return code from reads into the native alsa 
interface. Feedback needed....

73

Leif / SM5BSZ


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL