A NOTE has been added to this issue.
======================================================================
http://www.dbmail.org/mantis/view.php?id=994
======================================================================
Reported By: LordVan
Assigned To:
======================================================================
Project: DBMail
Issue ID: 994
Category: Command-Line programs (dbmail-users, dbmail-util)
Reproducibility: have not tried
Severity: crash
Priority: normal
Status: new
target:
======================================================================
Date Submitted: 04-Dec-12 00:23 CET
Last Modified: 09-Jul-13 01:59 CEST
======================================================================
Summary: dbmail-util segfaults without proper error message
when library_directory is set incorrectly
Description:
dbmail-util segfaults without proper error message when library_directory
is set incorrectly.
While setting up dbmail 3.0.2 on a seperate machine to test update from
2.2.17 before doing it on production I forgot to fix my library_path and
then when dbmail_util started just segfaulting I was wondering for a while
what was going on.
strace revealed the problem then:
recvfrom(3, "C\0\0\0\10SET\0Z\0\0\0\5I", 16384, 0, NULL, NULL) = 15
write(1, "Opening connection to authentica"..., 40Opening connection to
authentication... ) = 40
write(1, "\n", 1
) = 1
stat("libauth_sql.so", 0x7fff3ce90300) = -1 ENOENT (No such file or
directory)
stat("libauth_sql.so.so", 0x7fff3ce90300) = -1 ENOENT (No such file or
directory)
stat("libauth_sql.so.la", 0x7fff3ce90300) = -1 ENOENT (No such file or
directory)
futex(0x7f3b755650e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/etc/ld.so.cache", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=352645, ...}) = 0
mmap(NULL, 352645, PROT_READ, MAP_PRIVATE, 8, 0) = 0x7f3b78cf7000
close(8) = 0
open("/lib64/tls/x86_64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat("/lib64/tls/x86_64", 0x7fff3ce8fa90) = -1 ENOENT (No such file or
directory)
open("/lib64/tls/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/lib64/tls", 0x7fff3ce8fa90) = -1 ENOENT (No such file or
directory)
open("/lib64/x86_64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat("/lib64/x86_64", 0x7fff3ce8fa90) = -1 ENOENT (No such file or
directory)
open("/lib64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/lib64", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
open("/usr/lib64/tls/x86_64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7fff3ce8fa90) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/tls/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat("/usr/lib64/tls", 0x7fff3ce8fa90) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/x86_64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat("/usr/lib64/x86_64", 0x7fff3ce8fa90) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=274432, ...}) = 0
munmap(0x7f3b78cf7000, 352645) = 0
stat("libauth_sql.so", 0x7fff3ce90300) = -1 ENOENT (No such file or
directory)
stat("libauth_sql.so.so", 0x7fff3ce90300) = -1 ENOENT (No such file or
directory)
stat("libauth_sql.so.la", 0x7fff3ce90300) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=352645, ...}) = 0
mmap(NULL, 352645, PROT_READ, MAP_PRIVATE, 8, 0) = 0x7f3b78cf7000
close(8) = 0
open("/lib64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/libauth_sql.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
munmap(0x7f3b78cf7000, 352645) = 0
--- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffffffff}
(Segmentation fault) ---
+++ killed by SIGSEGV +++
Speicherzugriffsfehler
While it is fine to fail it should probably just spit out some error about
not finding the libraries instead of a segfault - I recon someone who is
not used to debugging programs would not find this that quickly).
on a sidenote: the dbmail-daemons also fail with a - not very helpful
message in dbmail.err (default logging level):
Dec 03 23:23:57 Desktop64X3 dbmail-lmtpd[16023]: [0x1e58a40]
EMERGENCY:[db] check_table_exists(+803): 3.x database incompatible - single
instance header storage missing.
Dec 03 23:23:57 Desktop64X3 dbmail-imapd[16038]: [0x1c53a40]
EMERGENCY:[db] check_table_exists(+803): 3.x database incompatible - single
instance header storage missing.
Dec 03 23:23:57 Desktop64X3 dbmail-pop3d[16051]: [0xa1da40] EMERGENCY:[db]
check_table_exists(+803): 3.x database incompatible - single instance
header storage missing.
======================================================================
----------------------------------------------------------------------
(0003541) creditlink (reporter) - 09-Jul-13 01:59
http://www.dbmail.org/mantis/view.php?id=994#c3541
----------------------------------------------------------------------
dbmail.conf suggests that if left unset in the conf file, it will default
to the directory compiled in. Even if I explicitly set libdir in
configure to /usr/local/lib64, it does not seem to translate
/usr/local/lib64/dbmail as
pkglibdir = $(libdir)/dbmail in the Makefile would have us believe.
Setting the libdir in the conf file stops the segfaults.
Issue History
Date Modified Username Field Change
======================================================================
04-Dec-12 00:23 LordVan New Issue
09-Jul-13 01:59 creditlink Note Added: 0003541
======================================================================
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
