In case that valgrind.RU.log attachment does not come through Ok, here it is inline:
==29795== Memcheck, a memory error detector. ==29795== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==29795== Using LibVEX rev 1854, a library for dynamic binary translation. ==29795== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==29795== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework. ==29795== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==29795== ==29795== My PID = 29795, parent PID = 3871. Prog and args are: ==29795== /usr/bin/polipo-20080907 ==29795== -c ==29795== /etc/polipo/standard.conf ==29795== proxyPort=8130 ==29795== socksParentProxy=localhost:9070 ==29795== pidFile=/var/run/polipo/8130.9070.pid ==29795== logFile=/var/log/polipo/8130.9070.log ==29795== diskCacheRoot=/var/cache/polipo/RU ==29795== --29795-- --29795-- Command line --29795-- /usr/bin/polipo-20080907 --29795-- -c --29795-- /etc/polipo/standard.conf --29795-- proxyPort=8130 --29795-- socksParentProxy=localhost:9070 --29795-- pidFile=/var/run/polipo/8130.9070.pid --29795-- logFile=/var/log/polipo/8130.9070.log --29795-- diskCacheRoot=/var/cache/polipo/RU --29795-- Startup, with flags: --29795-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp --29795-- -v --29795-- --log-file=/var/log/polipo/valgrind.RU.log --29795-- Contents of /proc/version: --29795-- Linux version 2.6.27.9 ([email protected]) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Wed Dec 17 23:45:15 CET 2008 --29795-- Arch and hwcaps: AMD64, amd64-sse2 --29795-- Page sizes: currently 4096, max supported 4096 --29795-- Valgrind library directory: /usr/lib/valgrind --29795-- Reading syms from /usr/bin/polipo-20080907 (0x400000) --29795-- Reading syms from /lib/ld-2.8.90.so (0x4000000) --29795-- Reading debug info from /lib/ld-2.8.90.so... --29795-- ... CRC mismatch (computed 8b4dd8c4 wanted afbabb05) --29795-- object doesn't have a symbol table --29795-- Reading syms from /usr/lib/valgrind/amd64-linux/memcheck (0x38000000) --29795-- object doesn't have a dynamic symbol table --29795-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp --29795-- Reading suppressions file: /usr/lib/valgrind/default.supp --29795-- Reading syms from /usr/lib/valgrind/amd64-linux/vgpreload_core.so (0x4A20000) --29795-- Reading syms from /usr/lib/valgrind/amd64-linux/vgpreload_memcheck.so (0x4C22000) --29795-- Reading syms from /lib/libc-2.8.90.so (0x4E2B000) --29795-- Reading debug info from /lib/libc-2.8.90.so... --29795-- ... CRC mismatch (computed 77f11ebc wanted fff37537) --29795-- object doesn't have a symbol table --29795-- REDIR: 0x4eadc70 (rindex) redirected to 0x4c26900 (rindex) --29795-- REDIR: 0x4ea9220 (calloc) redirected to 0x4c242b0 (calloc) --29795-- REDIR: 0x4ea95c0 (malloc) redirected to 0x4c264e0 (malloc) --29795-- REDIR: 0x4ead210 (strcmp) redirected to 0x4c27000 (strcmp) --29795-- REDIR: 0x4eae450 (memchr) redirected to 0x4c27120 (memchr) --29795-- REDIR: 0x4eb00f0 (memcpy) redirected to 0x4c27170 (memcpy) --29795-- REDIR: 0x4ea7030 (free) redirected to 0x4c251e0 (free) --29795-- REDIR: 0x4eae5e0 (bcmp) redirected to 0x4c278b0 (bcmp) --29795-- REDIR: 0xffffffffff600000 (???) redirected to 0x3802d0d3 (vgPlain_amd64_linux_REDIR_FOR_vgettimeofday) --29795-- REDIR: 0x4ea9ab0 (realloc) redirected to 0x4c26600 (realloc) --29795-- REDIR: 0x4ead7a0 (strlen) redirected to 0x4c26d20 (strlen) --29795-- REDIR: 0x4ead060 (index) redirected to 0x4c26a20 (index) --29795-- REDIR: 0x4eada40 (strncmp) redirected to 0x4c26f80 (strncmp) --29798-- REDIR: 0x4eb10f0 (strchrnul) redirected to 0x4c27c70 (strchrnul) ==29795== ==29795== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1) --29795-- --29795-- supp: 8 dl-hack3-cond-1 ==29795== malloc/free: in use at exit: 283,171 bytes in 262 blocks. ==29795== malloc/free: 277 allocs, 15 frees, 286,283 bytes allocated. ==29795== ==29795== searching for pointers to 262 not-freed blocks. ==29795== checked 609,368 bytes. ==29795== ==29795== LEAK SUMMARY: ==29795== definitely lost: 0 bytes in 0 blocks. ==29795== possibly lost: 0 bytes in 0 blocks. ==29795== still reachable: 283,171 bytes in 262 blocks. ==29795== suppressed: 0 bytes in 0 blocks. ==29795== Rerun with --leak-check=full to see details of leaked memory. --29795-- memcheck: sanity checks: 0 cheap, 1 expensive --29795-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --29795-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --29795-- memcheck: auxmaps_L2: 0 searches, 0 nodes --29795-- memcheck: SMs: n_issued = 16 (256k, 0M) --29795-- memcheck: SMs: n_deissued = 0 (0k, 0M) --29795-- memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M) --29795-- memcheck: SMs: max_undefined = 0 (0k, 0M) --29795-- memcheck: SMs: max_defined = 127 (2032k, 1M) --29795-- memcheck: SMs: max_non_DSM = 16 (256k, 0M) --29795-- memcheck: max sec V bit nodes: 0 (0k, 0M) --29795-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0) --29795-- memcheck: max shadow mem size: 4400k, 4M --29795-- translate: fast SP updates identified: 3,001 ( 91.4%) --29795-- translate: generic_known SP updates identified: 212 ( 6.4%) --29795-- translate: generic_unknown SP updates identified: 69 ( 2.1%) --29795-- tt/tc: 5,931 tt lookups requiring 6,035 probes --29795-- tt/tc: 5,931 fast-cache updates, 2 flushes --29795-- transtab: new 2,950 (66,752 -> 1,124,539; ratio 168:10) [0 scs] --29795-- transtab: dumped 0 (0 -> ??) --29795-- transtab: discarded 0 (0 -> ??) --29795-- scheduler: 72,977 jumps (bb entries). --29795-- scheduler: 0/3,369 major/minor sched events. --29795-- sanity: 1 cheap, 1 expensive checks. --29795-- exectx: 769 lists, 294 contexts (avg 0 per list) --29795-- exectx: 300 searches, 54 full compares (180 per 1000) --29795-- exectx: 0 cmp2, 28 cmp4, 0 cmpAll --29795-- errormgr: 8 supplist searches, 93 comparisons during search --29795-- errormgr: 8 errlist searches, 28 comparisons during search --29798-- REDIR: 0x4eaeaf0 (memmove) redirected to 0x4c27c10 (memmove) --29798-- REDIR: 0x4eb00e0 (__memcpy_chk) redirected to 0x4c281d0 (__memcpy_chk) --29798-- REDIR: 0x4eaf7b0 (mempcpy) redirected to 0x4c27cd0 (mempcpy) --29798-- REDIR: 0x4ead250 (strcpy) redirected to 0x4c26d80 (strcpy) --29798-- REDIR: 0x4eaecb0 (memset) redirected to 0x4c27ba0 (memset) --29798-- REDIR: 0x4eafdc0 (stpcpy) redirected to 0x4c27930 (stpcpy) ==29798== Invalid read of size 8 ==29798== at 0x4177BA: httpServerDoSide (server.c:972) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== Address 0x5ea3780 is 24 bytes inside a block of size 120 free'd ==29798== at 0x4C252AF: free (vg_replace_malloc.c:323) ==29798== by 0x416AFB: httpServerFinish (server.c:1303) ==29798== by 0x417363: httpServerDirectHandlerCommon (server.c:2605) ==29798== by 0x4057DA: do_scheduled_stream (io.c:368) ==29798== by 0x404328: pokeFdEventHandler (event.c:569) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== ==29798== Invalid read of size 4 ==29798== at 0x4177BE: httpServerDoSide (server.c:975) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== Address 0x5ea37c4 is 92 bytes inside a block of size 120 free'd ==29798== at 0x4C252AF: free (vg_replace_malloc.c:323) ==29798== by 0x416AFB: httpServerFinish (server.c:1303) ==29798== by 0x417363: httpServerDirectHandlerCommon (server.c:2605) ==29798== by 0x4057DA: do_scheduled_stream (io.c:368) ==29798== by 0x404328: pokeFdEventHandler (event.c:569) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== ==29798== Invalid read of size 8 ==29798== at 0x4177C7: httpServerDoSide (server.c:974) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== Address 0x98 is not stack'd, malloc'd or (recently) free'd ==29798== ==29798== Process terminating with default action of signal 11 (SIGSEGV) ==29798== Access not within mapped region at address 0x98 ==29798== at 0x4177C7: httpServerDoSide (server.c:974) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== ==29798== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 8 from 1) ==29798== ==29798== 1 errors in context 1 of 3: ==29798== Invalid read of size 8 ==29798== at 0x4177C7: httpServerDoSide (server.c:974) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== Address 0x98 is not stack'd, malloc'd or (recently) free'd ==29798== ==29798== 1 errors in context 2 of 3: ==29798== Invalid read of size 4 ==29798== at 0x4177BE: httpServerDoSide (server.c:975) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== Address 0x5ea37c4 is 92 bytes inside a block of size 120 free'd ==29798== at 0x4C252AF: free (vg_replace_malloc.c:323) ==29798== by 0x416AFB: httpServerFinish (server.c:1303) ==29798== by 0x417363: httpServerDirectHandlerCommon (server.c:2605) ==29798== by 0x4057DA: do_scheduled_stream (io.c:368) ==29798== by 0x404328: pokeFdEventHandler (event.c:569) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== ==29798== 1 errors in context 3 of 3: ==29798== Invalid read of size 8 ==29798== at 0x4177BA: httpServerDoSide (server.c:972) ==29798== by 0x417B87: httpClientDelayedDoSideHandler (server.c:1053) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) ==29798== Address 0x5ea3780 is 24 bytes inside a block of size 120 free'd ==29798== at 0x4C252AF: free (vg_replace_malloc.c:323) ==29798== by 0x416AFB: httpServerFinish (server.c:1303) ==29798== by 0x417363: httpServerDirectHandlerCommon (server.c:2605) ==29798== by 0x4057DA: do_scheduled_stream (io.c:368) ==29798== by 0x404328: pokeFdEventHandler (event.c:569) ==29798== by 0x4038DE: runTimeEventQueue (event.c:492) ==29798== by 0x40400C: eventLoop (event.c:659) ==29798== by 0x40DA30: main (main.c:165) --29798-- --29798-- supp: 8 dl-hack3-cond-1 ==29798== ==29798== IN SUMMARY: 3 errors from 3 contexts (suppressed: 8 from 1) ==29798== ==29798== malloc/free: in use at exit: 2,918,087 bytes in 36,109 blocks. ==29798== malloc/free: 1,049,245 allocs, 1,013,136 frees, 79,548,554 bytes allocated. ==29798== ==29798== searching for pointers to 36,109 not-freed blocks. ==29798== checked 13,489,048 bytes. ==29798== ==29798== LEAK SUMMARY: ==29798== definitely lost: 30,480 bytes in 254 blocks. ==29798== possibly lost: 0 bytes in 0 blocks. ==29798== still reachable: 2,887,607 bytes in 35,855 blocks. ==29798== suppressed: 0 bytes in 0 blocks. ==29798== Rerun with --leak-check=full to see details of leaked memory. --29798-- memcheck: sanity checks: 14245 cheap, 148 expensive --29798-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --29798-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --29798-- memcheck: auxmaps_L2: 0 searches, 0 nodes --29798-- memcheck: SMs: n_issued = 544 (8704k, 8M) --29798-- memcheck: SMs: n_deissued = 0 (0k, 0M) --29798-- memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M) --29798-- memcheck: SMs: max_undefined = 0 (0k, 0M) --29798-- memcheck: SMs: max_defined = 127 (2032k, 1M) --29798-- memcheck: SMs: max_non_DSM = 544 (8704k, 8M) --29798-- memcheck: max sec V bit nodes: 0 (0k, 0M) --29798-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0) --29798-- memcheck: max shadow mem size: 12848k, 12M --29798-- translate: fast SP updates identified: 8,018 ( 91.2%) --29798-- translate: generic_known SP updates identified: 685 ( 7.7%) --29798-- translate: generic_unknown SP updates identified: 87 ( 0.9%) --29798-- tt/tc: 1,650,036 tt lookups requiring 1,760,042 probes --29798-- tt/tc: 1,650,036 fast-cache updates, 2 flushes --29798-- transtab: new 7,661 (171,720 -> 2,983,437; ratio 173:10) [0 scs] --29798-- transtab: dumped 0 (0 -> ??) --29798-- transtab: discarded 0 (0 -> ??) --29798-- scheduler: 1,424,594,412 jumps (bb entries). --29798-- scheduler: 14,245/5,231,735 major/minor sched events. --29798-- sanity: 14246 cheap, 148 expensive checks. --29798-- exectx: 3,079 lists, 1,734 contexts (avg 0 per list) --29798-- exectx: 2,062,293 searches, 2,144,782 full compares (1,039 per 1000) --29798-- exectx: 0 cmp2, 31 cmp4, 0 cmpAll --29798-- errormgr: 11 supplist searches, 363 comparisons during search --29798-- errormgr: 11 errlist searches, 55 comparisons during search . . . . . Wesley ---------- Forwarded message ---------- From: Wesley Kenzie <[email protected]> Date: Tue, May 5, 2009 at 8:31 AM Subject: Re: [Polipo-users] use memcached? To: Polipo Users Mailing List <[email protected]> Finally I have a valgrind log that someone can maybe look at and advise how we can get this issue addressed. If this log is insufficient, please advise how I can get another one done up for analysis. . . . . . Wesley On Fri, Oct 24, 2008 at 10:52 AM, Juliusz Chroboczek < [email protected]> wrote: > > Juliusz (or any other adventurous developer on this list): have you > > considered using libmemcached instead of the file system for storing your > > cache? > > No. The data structures of Polipo are finely tuned, unless you can provide > benchmarks that show that memcached is faster than the built-in code, I see > no reason to switch. > > > And I hear that it scales pretty well :) > > The in-memory cache of Polipo runs in O(log n), except in the case of > emergency allocations (being short on memory). > > > Also, I am finding that some of my polipo instances are silently > crashing, > > and I am looking for a way to track what is causing this. > > 1.0.4 has a number of known bugs. My current tree fixes some of the known > bugs, but introduces new ones. > > Right now, I've got my hands full with other stuff (such as Real Work(TM)). > Sorry for that. > > Juliusz > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Polipo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/polipo-users
