[lkml]   [2004]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Memory leak in visor.c and ftdi_sio.c
    Ian Abbott wrote:
    > On 04/06/2004 15:59, nardelli wrote:
    >> Note that I have not verified any of the below on
    >> hardware associated with drivers/usb/serial/ftdi_sio.c,
    >> only with drivers/usb/serial/visor.c. If anyone has
    >> hardware for this device, I would appreciate your comments.
    >> A memory leak occurs in both drivers/usb/serial/ftdi_sio.c
    >> and drivers/usb/serial/visor.c when the usb device is
    >> unplugged while data is being written to the device. This
    >> patch should clear that up.
    > The change to ftdi_sio.c looks correct to me.
    > I made the original change to ftdi_sio.c to allocate the write urbs and
    > their transfer buffers dynamically (instead of using a preallocated
    > pool) and I copied that technique from visor.c!
    > A related problem with the current implementation is that is easy to run
    > out of memory by running something similar to this:
    > # cat /dev/zero > /dev/ttyUSB0
    > That affects both the ftdi_sio and visor drivers.

    I believe that I have seen something similiar, but possibly not identical.
    When writing alot (I used /dev/urandom instead of /dev/zero), it looks
    like a very large percentage of buffers that are being allocated during
    writes are not being freed. One test I did indicated that 95% of buffers
    were not being freed! I briefly mention some info in, but I wasn't going to go into detail
    until I'd found out more info, and verified that my test procedure was

    My test is pretty simple, print out the address every time a buffer is
    allocated, and print out the address every time a buffer is freed. In
    this case there is only one location where it is being allocated, but 3
    (4 with patch I submitted) where it is being freed. It's simply a matter
    of running a command like the one below, and looking to see which addresses
    are in there an odd number of times (i.e. allocated, but not freed). Not a
    perfect test, but hopefully not embarrassingly bad either.

    cat /var/log/messages | egrep 'Allocated|Freed' | tr -s ' ' | cut -d ' ' -f 7 | sort | uniq -c | sort -n

    I'm not sure why such a high percentage would not be freed, but hopefully I'll
    figure it out in the next week or two, time permitting.

    Joe Nardelli
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.026 / U:5.412 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site