https://bugs.kde.org/show_bug.cgi?id=366035
--- Comment #9 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
> I hope it helps too! What do you want me to do now? Is there some
> other tracing facility which I should run to help you identify the
> problematic ioctl? Do you want me to make the example program more
> minimal? Perhaps I could do the latter, otherwise I don't really have
> much time - I just wanted to report this bug as a kind of housekeeping
> task, so that upstream knows about the problem. We can maybe rename it
> to something like "valgrind doesn't correctly track buffer overflows
> from certain ALSA ioctls". Thank you,
Yes, it would be nice to continue the investigation, as the ioctl hypothesis is
not yet
confirmed.
So, the following would be useful:
Discover which ioctl are done by snd_pcm_readi
One way is to put a breakpoint on the line calling this function, and the
next line.
When the first breapoint is encountered, add a breakpoint on the ioctl
syscall.
Each time the ioctl breapoint triggers, write down the (symbolic) ioctl
request
(I guess the symbolic request will be seen in the source e.g. when doing GDB
up)
It is assumed that the ioctl done (or one of the ioctl done by this function)
is using
the buffer address as parameter. Would be nice to confirm that.
The remaining mystery is : if really an ioctrl is 'badly' described in
syswrap-linux.c,
then that should create a lot of errors in memcheck (use of undefined memory).
So, the ioctrl badly described hypothesis is still not (fully) understandable.
The alternative to find which ioctl is done is to read the library source file.
Thanks
--
You are receiving this mail because:
You are watching all bug changes.
