Hi Helmut, On Tue, Feb 19, 2013 at 8:23 PM, Helmut Grohne <h.gro...@cygnusnetworks.de> wrote: > I cannot send you a capture, because that could compromise the > confidentiality of the data send by users. I am currently trying to > reproduce the issue in a more controlled manner.
I understand. > Please keep in mind that I am feeding 50MB/s at 50kpps to ntop. Even > tcpdump is unable to keep up with this rate (even in SCHED_FIFO) and > drops about 0.1% of the packets when being asked to write them to > /dev/shm. Running ntop on this system consumes a full cpu. It will > likely drop more packets. When adding valgrind it will likely drop > most of the packets. So this might be a reason for why I am unable > to observe the issue using valgrind. Ok, makes sense. > I will try the following: > * Determine a small set of packets that reliably trigger some kind > of crash. > * Trying to reproduce the issue with fresh gdbm databases. This would be great. Having set of packets that can trigger the crash would be very useful. It looks like the code handling IP fragments is the culprit (or maybe the mostly affected one by the bug). Maybe running a tcpdump capturing only fragmented packets could help. > ==11364== Thread 3: > ==11364== Invalid read of size 8 > ==11364== at 0x50CBB60: purgeOldFragmentEntries (ip.c:256) > ==11364== by 0x50C9B96: purgeIdleHosts (hash.c:401) > ==11364== by 0x50D7ABE: scanIdleLoop (ntop.c:683) > ==11364== by 0x67A6B4F: start_thread (pthread_create.c:304) > ==11364== by 0x5853A7C: clone (clone.S:112) > ==11364== Address 0x149cdc10 is 48 bytes inside a block of size 72 free'd > ==11364== at 0x4C27D4E: free (vg_replace_malloc.c:427) > ==11364== by 0x50D6115: ntop_safefree (leaks.c:182) > ==11364== by 0x50CB7E7: deleteFragment (ip.c:113) > ==11364== by 0x50CBB94: purgeOldFragmentEntries (ip.c:265) > ==11364== by 0x50C9B96: purgeIdleHosts (hash.c:401) > ==11364== by 0x50D7ABE: scanIdleLoop (ntop.c:683) > ==11364== by 0x67A6B4F: start_thread (pthread_create.c:304) > ==11364== by 0x5853A7C: clone (clone.S:112) This is very interesting indeed. Even if it does not cause a crash, this code is apparently operating on a segment that has already been freed. I will look a bit more into in the following days. Thanks for your help, Ludovico -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
