Messages in this thread | | | Date | Fri, 04 Jun 2004 13:25:22 -0400 | From | nardelli <> | Subject | Re: [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 http://lkml.org/lkml/2004/5/25/72, but I wasn't going to go into detail until I'd found out more info, and verified that my test procedure was adequate.
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 jnardelli@infosciences.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |