Hi,
Alexis Berlemont wrote:
> Hi,
>
> On Wed, Jun 16, 2010 at 7:01 PM, Daniele Nicolodi wrote:
> > On 11/03/10 18:12, Daniele Nicolodi wrote:
> >> Hello.
> >>
> >> I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained
> >> for an unattached device, the memory allocated for the
Hi,
On Wed, Jun 16, 2010 at 7:01 PM, Daniele Nicolodi wrote:
> On 11/03/10 18:12, Daniele Nicolodi wrote:
>> Hello.
>>
>> I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained
>> for an unattached device, the memory allocated for the sbdata descriptor
>> field is corrupted in a
On 11/03/10 18:12, Daniele Nicolodi wrote:
> Hello.
>
> I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained
> for an unattached device, the memory allocated for the sbdata descriptor
> field is corrupted in a bad way. When, after the failing a4l_fill_desc()
> call, I free() it,
On Thu, Mar 11, 2010 at 6:12 PM, Daniele Nicolodi wrote:
> Hello.
Hello.
> I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained
> for an unattached device, the memory allocated for the sbdata descriptor
> field is corrupted in a bad way. When, after the failing a4l_fill_desc()
Hello.
I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained
for an unattached device, the memory allocated for the sbdata descriptor
field is corrupted in a bad way. When, after the failing a4l_fill_desc()
call, I free() it, glibc complains about an "invalid next size" for the
m
