RE: latest spam-milter

[Ron Snyder]

> > This trace looks vaguely familiar, in that according to the 
> assembly,
> > it's crashing after the last line in the function.  Which means it's
> > crashing in a C++ destructor.  Wait a minute.  You're that 
> > same guy! :)
> 
> Yep.  I saw that you submitted changes to fix the zeroing 
> malloc thing and thought I'd give it a try.

I got a newer cvs version and compiled, but had the same results (at the
same spot in the code).  I recompiled without any optimization, and although
I'm still crashing it's crashing at a different spot. It does look to me
like your guess that it's a problem with (or using) string is still valid,
though.

Here's one common example:

# gdb /usr/local/sbin/spamass-milter /core.4               
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd2.7"...
Core was generated by `spamass-milter'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libstdc++.so.30.0...done.
Reading symbols from /usr/lib/libm.so.0.1...done.
Reading symbols from /usr/lib/libc_r.so.3.0...done.
#0  0x30e9 in mlfi_header (ctx=0x22300, headerf=0x22580 "Received", 
    headerv=0x22589 "(from address@hidden)\n\tby ulsmlbx03 (8.11.0/8.11.0)
id gAKIg7528215;\n\tWed, 20 Nov 2002 12:42:07") at spamass-milter.cpp:409
409       if ( cmp_nocase_partial(string("X-Spam-"), string(headerf)) == 0 )
(gdb) bt
#0  0x30e9 in mlfi_header (ctx=0x22300, headerf=0x22580 "Received", 
    headerv=0x22589 "(from address@hidden)\n\tby ulsmlbx03 (8.11.0/8.11.0)
id gAKIg7528215;\n\tWed, 20 Nov 2002 12:42:07") at spamass-milter.cpp:409
#1  0xcb3a in st_header ()
#2  0xc26c in mi_engine ()
#3  0xa5a5 in mi_handle_session ()
#4  0x9cf5 in mi_thread_handle_wrapper ()
#5  0x40085518 in _thread_start ()
(gdb) disassemble
Dump of assembler code for function mlfi_header__FP8smfi_strPcT1:
0x3070 <mlfi_header__FP8smfi_strPcT1>:  pushl  %ebp
0x3071 <mlfi_header__FP8smfi_strPcT1+1>:        movl   %esp,%ebp
0x3073 <mlfi_header__FP8smfi_strPcT1+3>:        subl   $0x28c,%esp
0x3079 <mlfi_header__FP8smfi_strPcT1+9>:        pushl  %edi
0x307a <mlfi_header__FP8smfi_strPcT1+10>:       pushl  %esi
0x307b <mlfi_header__FP8smfi_strPcT1+11>:       pushl  %ebx
0x307c <mlfi_header__FP8smfi_strPcT1+12>:       
    call   0xd75c <__get_eh_context>
0x3081 <mlfi_header__FP8smfi_strPcT1+17>:       movl   %eax,%eax
0x3083 <mlfi_header__FP8smfi_strPcT1+19>:       movl   %eax,%edx
0x3085 <mlfi_header__FP8smfi_strPcT1+21>:       movl   %edx,%eax
0x3087 <mlfi_header__FP8smfi_strPcT1+23>:       movl   %eax,0xfffffde0(%ebp)
0x308d <mlfi_header__FP8smfi_strPcT1+29>:       addl   $0xfffffff4,%esp
0x3090 <mlfi_header__FP8smfi_strPcT1+32>:       movl   0x8(%ebp),%eax
0x3093 <mlfi_header__FP8smfi_strPcT1+35>:       pushl  %eax
0x3094 <mlfi_header__FP8smfi_strPcT1+36>:       call   0xac28 <smfi_getpriv>
0x3099 <mlfi_header__FP8smfi_strPcT1+41>:       addl   $0x10,%esp
0x309c <mlfi_header__FP8smfi_strPcT1+44>:       movl   %eax,0xfffffffc(%ebp)
0x309f <mlfi_header__FP8smfi_strPcT1+47>:       addl   $0xfffffff8,%esp
0x30a2 <mlfi_header__FP8smfi_strPcT1+50>:       pushl  $0x302b
0x30a7 <mlfi_header__FP8smfi_strPcT1+55>:       pushl  $0x1
0x30a9 <mlfi_header__FP8smfi_strPcT1+57>:       call   0x77c4
<debug__FiPCce>
0x30ae <mlfi_header__FP8smfi_strPcT1+62>:       addl   $0x10,%esp
0x30b1 <mlfi_header__FP8smfi_strPcT1+65>:       addl   $0xfffffff8,%esp
0x30b4 <mlfi_header__FP8smfi_strPcT1+68>:       movl   0xc(%ebp),%eax
0x30b7 <mlfi_header__FP8smfi_strPcT1+71>:       pushl  %eax
0x30b8 <mlfi_header__FP8smfi_strPcT1+72>:       leal   0xfffffff8(%ebp),%eax
0x30bb <mlfi_header__FP8smfi_strPcT1+75>:       pushl  %eax
0x30bc <mlfi_header__FP8smfi_strPcT1+76>:       
    call   0x8aec
<__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b
0i0PCc>
0x30c1 <mlfi_header__FP8smfi_strPcT1+81>:       addl   $0x10,%esp
0x30c4 <mlfi_header__FP8smfi_strPcT1+84>:       movl   %eax,%eax
0x30c6 <mlfi_header__FP8smfi_strPcT1+86>:       movl   0xfffffde0(%ebp),%edx
0x30cc <mlfi_header__FP8smfi_strPcT1+92>:       addl   $0x4,%edx
0x30cf <mlfi_header__FP8smfi_strPcT1+95>:       movl   (%edx),%eax
0x30d1 <mlfi_header__FP8smfi_strPcT1+97>:       addl   $0x4,%eax
0x30d4 <mlfi_header__FP8smfi_strPcT1+100>:      movl   (%eax),%edx
0x30d6 <mlfi_header__FP8smfi_strPcT1+102>:      movl   %edx,0xffffffec(%ebp)
0x30d9 <mlfi_header__FP8smfi_strPcT1+105>:      movl
$0x8928,0xfffffff0(%ebp)
0x30e0 <mlfi_header__FP8smfi_strPcT1+112>:      leal   0xfffffff8(%ebp),%edx
0x30e3 <mlfi_header__FP8smfi_strPcT1+115>:      movl   %edx,0xfffffff4(%ebp)
0x30e6 <mlfi_header__FP8smfi_strPcT1+118>:      leal   0xffffffec(%ebp),%edx
0x30e9 <mlfi_header__FP8smfi_strPcT1+121>:      movl   %edx,(%eax)


> 
> > I wish gdb would put correct debugging information in 
> destructor code
> > so I could tell what's actually crashing.
> > 
> > You might want to try the CVS version if you're not already 
> > using it; I
> > fixed a couple of big-ish bugs this weekend relating to memory
> > corruption.
> 
> Ah. I'll sync my cvs tonight. (I have Friday's version.)
> 
> -ron
>