[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Linrad] Re: Linrad-02.53
- Subject: [Linrad] Re: Linrad-02.53
- From: Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>
- Date: Mon, 10 Nov 2008 12:32:04 +0100
> 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
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 " 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  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  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:
at the bottom of the page.
This version has two global variables:
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....
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