[Dovecot] dspam plugin
Ryan Kolak
ryank at rkware.com
Wed Apr 12 06:14:52 EEST 2006
-----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-----
More information about the dovecot
mailing list