After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 318649 - spamassassin impossibly slow ...
spamassassin impossibly slow ...
Status: RESOLVED DUPLICATE of bug 317792
Product: evolution
Classification: Applications
Component: Mailer
2.4.x (obsolete)
Other Linux
: High normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-10-12 08:23 UTC by Michael Meeks
Modified: 2005-10-12 11:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Meeks 2005-10-12 08:23:42 UTC
So - a clean & up-to-date SL 10.0 install.
a) spamd is not started by default [ a distro / packaging bug ]
b) *having manually started it* [ and re-started evo. etc. ]
   it is not used ... instead I see lots of 'spamassassin' forkage and no spamc
   usage. This of course is unimaginably slow - it took most of yesterday to fetch
   yesterday's E-mail.

Why are we not using spamc ?
Comment 1 Michael Meeks 2005-10-12 08:27:51 UTC
A simple strace shows we never even look for spamc:

linux:~ # grep 'execve' /tmp/log 
28447 execve("/opt/gnome/bin/evolution", ["evolution"], [/* 81 vars */]) = 0
28449 execve("/bin/netstat", ["netstat", "-ni"], [/* 82 vars */]) = 0
28522 execve("/home/michael/bin/spamassassin", ["spamassassin", "--version"],
[/* 81 vars */]) = -1 ENOENT (No such file or directory)
28522 execve("/usr/local/bin/spamassassin", ["spamassassin", "--version"], [/*
81 vars */]) = -1 ENOENT (No such file or directory)
28522 execve("/usr/bin/spamassassin", ["spamassassin", "--version"], [/* 81 vars
*/]) = 0
28528 execve("/home/michael/bin/spamassassin", ["spamassassin", "--exit-code"],
[/* 81 vars */]) = -1 ENOENT (No such file or directory)
28528 execve("/usr/local/bin/spamassassin", ["spamassassin", "--exit-code"], [/*
81 vars */]) = -1 ENOENT (No such file or directory)
28528 execve("/usr/bin/spamassassin", ["spamassassin", "--exit-code"], [/* 81
vars */]) = 0

This is with a setup upgraded from evo-2.2.
Comment 2 Michael Meeks 2005-10-12 11:08:20 UTC
So - thank God for debugrpms:

From this trace:
  • #0 em_junk_sa_is_available
    at em-junk-filter.c line 457
  • #1 em_junk_sa_check_junk
    at em-junk-filter.c line 534
  • #2 e_plugin_xml_content
    from /opt/gnome/lib/evolution/2.4/libeutil.so.0
  • #3 e_plugin_invoke
    from /opt/gnome/lib/evolution/2.4/libeutil.so.0
  • #4 em_inline_filter_get_multipart
    from /opt/gnome/lib/evolution/2.4/components/libevolution-mail.so
  • #5 camel_junk_plugin_check_junk
    from /opt/gnome/lib/libcamel-1.2.so.0
  • #6 camel_filter_driver_filter_mbox
    from /opt/gnome/lib/libcamel-provider-1.2.so.6
  • #7 e_sexp_term_eval
    at e-sexp.c line 710
  • #8 e_sexp_eval
    at e-sexp.c line 1304
  • #9 camel_filter_search_match
    from /opt/gnome/lib/libcamel-provider-1.2.so.6
  • #10 camel_filter_driver_filter_message
    from /opt/gnome/lib/libcamel-provider-1.2.so.6
  • #11 camel_filter_driver_filter_folder
    from /opt/gnome/lib/libcamel-provider-1.2.so.6
  • #12 mail_call_main
    from /opt/gnome/lib/evolution/2.4/components/libevolution-mail.so
  • #13 mail_filter_junk
    from /opt/gnome/lib/evolution/2.4/components/libevolution-mail.so
  • #14 mail_enable_stop
    from /opt/gnome/lib/evolution/2.4/components/libevolution-mail.so
  • #15 thread_dispatch
    at e-msgport.c line 826
  • #16 start_thread
    from /lib/tls/libpthread.so.0
  • #17 clone
    from /lib/tls/libc.so.6
  • #18 ??


I see that the various critical flags are not set to the gconf key values:

(gdb) p em_junk_sa_use_daemon
$4 = 0

But - also, that the plugin has clearly not been initialized:

(gdb) p em_junk_sa_gconf
$8 = (GConfClient *) 0x0

Which is extremely strange - but would explain all the problems.

Why would this plugin not get inited ?
Comment 3 Michael Meeks 2005-10-12 11:21:54 UTC
Amazingly an objdump -T on the plugin shows that it is not in fact exporting the
e_plugin_lib_enable symbol - which is extremely curious:

(gdb) finish
Run till exit from #0  g_module_open (
    file_name=0x814d310
"/opt/gnome/lib/evolution/2.4/plugins/liborg-gnome-sa-junk-plugin.so", flags=0)
at gmodule.c:314
0x40152ca1 in e_plugin_xml_content ()
   from /opt/gnome/lib/evolution/2.4/libeutil.so.0
Value returned is $1 = (GModule *) 0x8dd0a40
(gdb) p g_module_symbol($1, "e_plugin_lib_enable", malloc(10))
$3 = 0
(gdb) 

objdump -T <libname>

gives the same result: UH !?
Comment 4 Michael Meeks 2005-10-12 11:23:26 UTC

*** This bug has been marked as a duplicate of 317792 ***