-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
valgrind is new to me, think i ran it right:
# valgrind --show-reachable=yes --leak-check=full /usr/sbin/dovecot
found a small handful of leaks on startup, none of which look like anything directly related.. There's one more leak when the first time i load a page via squirrelmail (in the login process), but nothing after that until i kill dovecot. the full output is at the bottom if its useful at all.
I don't really see how this could be happening as the list allocation seems straightforward. I could add in some debug syslog statements in there but i doubt that would be useful. I'd like to step into the code a bit more but i'm at a loss on what to do next. I'm open to suggestions, and fairly capable too.
Thanks again for the help,
Ryan
==30557== Memcheck, a memory error detector. ==30557== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==30557== Using LibVEX rev 1471, a library for dynamic binary translation. ==30557== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==30557== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==30557== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==30557== For more details, rerun with: -v ==30557== ==30557== ==30557== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==30557== malloc/free: in use at exit: 25,668 bytes in 15 blocks. ==30557== malloc/free: 83 allocs, 68 frees, 39,234 bytes allocated. ==30557== For counts of detected errors, rerun with: -v ==30557== searching for pointers to 15 not-freed blocks. ==30557== checked 97,824 bytes. ==30557== ==30557== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 6 ==30557== at 0x4A18AFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_ memcheck.so) ==30557== by 0x4BE27EF: (within /lib64/libc-2.3.5.so) ==30557== by 0x4BE309E: __nss_database_lookup (in /lib64/libc-2.3.5.so) ==30557== by 0x4E4549F: ??? ==30557== by 0x4E463CB: ??? ==30557== by 0x4BA7BE4: getpwnam_r (in /lib64/libc-2.3.5.so) ==30557== by 0x4BA7721: getpwnam (in /lib64/libc-2.3.5.so) ==30557== by 0x40860E: settings_verify (master-settings.c:418) ==30557== by 0x409A66: master_settings_read (master-settings.c:1188) ==30557== by 0x407E82: main (main.c:767) ==30557== ==30557== ==30557== 80 bytes in 5 blocks are indirectly lost in loss record 2 of 6 ==30557== at 0x4A18AFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30557== by 0x4BE23CF: __nss_lookup_function (in /lib64/libc-2.3.5.so) ==30557== by 0x4E454BA: ??? ==30557== by 0x4E463CB: ??? ==30557== by 0x4BA7BE4: getpwnam_r (in /lib64/libc-2.3.5.so) ==30557== by 0x4BA7721: getpwnam (in /lib64/libc-2.3.5.so) ==30557== by 0x40860E: settings_verify (master-settings.c:418) ==30557== by 0x409A66: master_settings_read (master-settings.c:1188) ==30557== by 0x407E82: main (main.c:767) ==30557== ==30557== ==30557== 160 bytes in 5 blocks are indirectly lost in loss record 3 of 6 ==30557== at 0x4A18AFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30557== by 0x4BD2159: tsearch (in /lib64/libc-2.3.5.so) ==30557== by 0x4BE2389: __nss_lookup_function (in /lib64/libc-2.3.5.so) ==30557== by 0x4E454BA: ??? ==30557== by 0x4E463CB: ??? ==30557== by 0x4BA7BE4: getpwnam_r (in /lib64/libc-2.3.5.so) ==30557== by 0x4BA7721: getpwnam (in /lib64/libc-2.3.5.so) ==30557== by 0x40860E: settings_verify (master-settings.c:418) ==30557== by 0x409A66: master_settings_read (master-settings.c:1188) ==30557== by 0x407E82: main (main.c:767) ==30557== ==30557== ==30557== 776 bytes in 1 blocks are still reachable in loss record 4 of 6 ==30557== at 0x4A1A181: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30557== by 0x40B611: t_push (data-stack.c:91) ==30557== by 0x40F846: lib_init (lib.c:24) ==30557== by 0x407DD5: main (main.c:715) ==30557== ==30557== ==30557== 8,192 bytes in 2 blocks are still reachable in loss record 5 of 6 ==30557== at 0x4A1A181: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30557== by 0x40FEA7: block_alloc (mempool-alloconly.c:171) ==30557== by 0x40FFF4: pool_alloconly_create (mempool-alloconly.c:88) ==30557== by 0x40A042: master_settings_init (master-settings.c:1406) ==30557== by 0x407E6D: main (main.c:766) ==30557== ==30557== ==30557== 16,408 bytes in 1 blocks are still reachable in loss record 6 of 6 ==30557== at 0x4A18AFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30557== by 0x40B497: mem_block_alloc (data-stack.c:190) ==30557== by 0x40B4FA: data_stack_init (data-stack.c:360) ==30557== by 0x40F846: lib_init (lib.c:24) ==30557== by 0x407DD5: main (main.c:715) ==30557== ==30557== LEAK SUMMARY: ==30557== definitely lost: 52 bytes in 1 blocks. ==30557== indirectly lost: 240 bytes in 10 blocks. ==30557== possibly lost: 0 bytes in 0 blocks. ==30557== still reachable: 25,376 bytes in 4 blocks. ==30557== suppressed: 0 bytes in 0 blocks.
After logging in: ==30561== Syscall param write(buf) points to uninitialised byte(s) ==30561== at 0x4BC7D72: write (in /lib64/libc-2.3.5.so) ==30561== by 0x411CC1: o_stream_writev (ostream-file.c:131) ==30561== by 0x4124BC: _sendv (ostream-file.c:441) ==30561== by 0x411977: o_stream_sendv (ostream.c:124) ==30561== by 0x4119A9: o_stream_send (ostream.c:107) ==30561== by 0x405041: auth_master_callback (login-process.c:100) ==30561== by 0x40342C: auth_process_input (auth-process.c:120) ==30561== by 0x40F755: io_loop_handler_run (ioloop-poll.c:203) ==30561== by 0x40EBD9: io_loop_run (ioloop.c:274) ==30561== by 0x4082E5: main (main.c:816)
After killing pid 30561, there were three more leaks from settings_verify in master-settings.c which shouldn't have anything to do with this.
On Tue, April 11, 2006 7:41 pm, Johannes Berg said:
On Tue, 2006-04-11 at 17:51 -0500, Ryan Kolak wrote:
I've isolated the problem to one line of code, but I'm not really sure why its breaking, any light anyone can shed on this would be really appreciated. I still have yet to determine if 64bit could have anything to do with it (unlikely, since the code looks similar to other dovecot pool allocations) or if the plugin is somehow not compatiable with the CVS version.
You compiled it against that version, so the latter is highly unlikely. If you're compiling the plugin against a different version and trying to use the binary, there's a chance that is the problem, but other than that...
I changed the following line of code:
202 list_append(listpool, &siglist)->sig = p_strdup(listpool, signature);
to :
list_append(listpool, &siglist); siglist->sig = p_strdup(listpool, signature);#ifdef DEBUG syslog(LOG_INFO, "stored %s into siglist, value is %s ", signature, siglist->sig ); #endif
And I'm seeing the following in my syslog:
Apr 11 14:53:50 uberserver imap: stored 443b702a6341804284693 into siglist, value is <F8><E3>Z Apr 11 14:53:50 uberserver imap: working with signature <F8><E3>Z Apr 11 14:53:50 uberserver imap: in call dspam Apr 11 14:53:50 uberserver imap: /usr/bin/dspam --source=error --stdout
- --class=spam --signature=<F8><E3>Z
That's very odd. I have no idea what is causing this. Can you run in valgrind (do you have valgrind for 64 bits?)
johannes
PGP Fingerprint - E15C CC7D 5830 AB8A C2AE 5C5E 80D8 6B63 D40B 015C
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEPHCrgNhrY9QLAVwRAizdAJ40/8Bvrj3NBwuJV8G6djgE5e0I+wCfREcW pcQkqBfmPjEpyyWJHVt2YI0= =Rl/T -----END PGP SIGNATURE-----