On Thu, Aug 01, 2002 at 09:59:23PM +0200, Christoph Reichenbach wrote:
> With n being somewhat different from what purify reported, there's hardly
> any alternative to heap corruption happening here. I know little about how
> the underlying SDL mechanism works; maybe pizza has some idea of what's
> going on?
Well, let me first say "It works for me". <ducking>
Now that's out of thw way... I agree with the diagnosis that there's
some insidious heap corruption going on.
SDL works via a callback interface. You set up the PCM channel options
and point it towards a function that it can call to replentish SDL's
buffers.
So if fill_audio is getting called with a very large n, the fault lies
on SDL for passing in that large n. And note that n in this case
referes to the number of bytes in the buffer, not the number of samples.
Elsewhere in the pcm system, 'n' refers to the number of samples.
n should wlaways be less than or equal to BUFFER_COUNT, and the buffer
should be at least 4*n bytes. I believe that's the case.
There is one potential overflow I see in fill_audio; it's entirely
possible that 'len' passed in is less than the number of samples we have
remaining in our buffer, and we blindly memcpy() over the end. But if
that's happening, it's SDL's fault..
So did this crash just start happening, or has it been there a while?
the SDL pcmout code hasn't changed in a long time.
- Pizza
--
Solomon Peachy pizza@f*cktheusers.org
I'm not broke, but I'm badly bent. ICQ #1318344
Patience comes to those who wait. Melbourne, FL
Quidquid latine dictum sit, altum viditur
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9SuaXPuLgii2759ARAhsLAJ9kheOaG5ybe8hok6gFIysrXO5txQCeO+M3
QGPT2243snNOzyD6eBAXY0I=
=Xp/P
-----END PGP SIGNATURE-----
