https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #7 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Frederick Eaton from comment #6)
> Hi Philippe,
>
> Thanks for responding.
>
> I'm using Arch Linux, it's weird that the default Arch package is not
> to your liking.
The assumption is that valgrind is (basically) build using
configure/make/make install
and that the resulting executables are not stripped (to ensure a.o. that the
crash stack traces contains symbolic information).
But everybody is free to compile valgrind as they want, this is free software
:).
And of course, then to get some help from Valgrind developers, very likely,
we will prefer to have non stripped executables :).
> Well I compiled from ABS adding (!strip debug) to
> OPTIONS in /etc/makepkg.conf, the new version gives line numbers for
> the backtrace. I attached the new output and also the output with the
> verbose options you recommended.
Thanks. This line/source nr allows to confirm that the valgrind malloc
structure has been
heavily corrupted.
> In the original version I just called `snd_pcm_hw_params_set_channels`
> and assumed the setting had been honored by ALSA. I requested 1
> channel, ALSA created 2 channels per device constraints, I allocated
> space for 32768 1-channel "frames", ALSA return 32768 2-channel
> frames. I got a buffer overflow. I hope this answers your question. I
> imagine that my original submission was a bit confusing.
Forcing the channel to 1 at that 'BUG' place has other consequences than just
allocating a 'too small' buffer.
As I understand, after this 'forcing to 1', we will also have sfinfo.channels
that will
be 1 instead of 2. No idea if that participates (or not) to the problem.
But what you might do instead of changing channels to 1 is to just allocate a
buffer
with a size equal to frames * 2.
Then we know that the only thing which is 'wrong' is the buffer size.
That being said, assuming the too small buffer is the only cause of this
corruption,
the only 'modify' use of this buffer is likely in the source line:
res = snd_pcm_readi(handle, buffer, frames);
In the detailed trace, we see no matching read system call.
So, I will assume that this snd_pcm_readi is not doing a read syscall but is
rather
an ioctl, probably corresponding to this trace:
SYSCALL[14734,1](16) sys_ioctl ( 4, 0x80184151, 0xffefff170 ) --> [async] ...
SYSCALL[14734,1](16) ... [async] --> Success(0x0)
I am not sure how to translate this 0x80184151 into one of the 'symbolic' ioctl
SND/PCM things handled in syswrap-linux.c.
I suspect that some SND/PCM ioctl are not properly described as
reading/writing the memory
pointed to by the ARG3 of the ioctl. Then of course, that might do a buffer
overrun
which is undetected by Valgrind, which then corrupts the end of the buffer
block
and the malloc data structure/memory/blocks following this (too small) buffer.
So, at this point, what we need to confirm is:
is snd_pcm_readi really doing an ioctl ?
if yes, which one ? (i.e. which 'symbolic' ioctl is it doing ?)
e.g. maybe it is case VKI_SOUND_PCM_READ_CHANNELS:
and if this is the case, then syswrap-linux.c describes that this ioctl is
writing the
size of an int, while it clearly reads more than an int, if the ioctl is
reading real data.
If now that is the bug, and syswrap-linux.c really should describe that it
reads a bunch
of bytes depending on previously set parameters, then I think that is a lot of
work to do,
as basically syswrap-linux.c will need to record the previous SND/PCM ioctl to
know what
is the expected size of such an ioctl ARG3.
Now, maybe this ioctl is rather something like VKI_SNDRV_CTL_IOCTL_TLV_READ
but I do not see how that matches this buffer logic and the snd_pcm_readi,
which only
has a buffer argument.
So, to understand where the undetected buffer overflow comes from, I guess some
alsa/snd lib source code reading might be needed, to see how snd_pcm_readi is
implemented
in terms of ioctl.
We can then check if syswrap-linux.c properly describes what this ioctl is
accessing
in read and/or write mode.
Hoping this helps ....
--
You are receiving this mail because:
You are watching all bug changes.
