v1.002 Segmentation Fault

I'm having problems getting everything setup and running well. I swapped lines 101 and 102 in src/dbdefs.cpp as mentioned in a previous post. When running gps, I get segementation faults repeatedly. I'm not familiar enough with C++ to be much help so I'm hoping someone can help me out.

OS: Red Hat Enterprise Linux 3
MySQL: 4.1.7
postfix: 2.1.5
libdbi: 0.7.2
libdbi-drivers: 0.7.1
gps: 1.002

[b]RUN #1[/b]

mode=init
#mode=reverse
dbtype=mysql
db_host=127.0.0.1
db_username=pfpolicy
db_password=******
db_dbname=greylist
timeout=60
wl_pattern=dbcached
wl_network=dbcached
wl_recipient=db
wl_sender=db

shelms@rescue38:~/src/mail/gps-1.002$ src/gps -v /etc/postfix/configs/gps.conf show tables;
+--------------------+
| Tables_in_greylist |
+--------------------+
| network |
| pattern |
| recipient |
| sender |
| triplet |
+--------------------+
5 rows in set (0.01 sec)

mysql>
[/pre]

/var/log/maillog
Feb 7 11:33:06 rescue38 gps[1243]: started (ver.: 1.002 built: Feb 7 2005 11:11:18)
Feb 7 11:33:06 rescue38 gps[1243]: reading config: /etc/postfix/configs/gps.conf
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: key: mode value=init
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: key: dbtype value=mysql
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: db key: host value=127.0.0.1Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: db key: username value=pfpolicy
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: db key: password value=(hidden)
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: db key: dbname value=greylist
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: key: timeout value=60
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: wl key: pattern value=dbcached
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: wl key: network value=dbcached
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: wl key: recipient value=db
Feb 7 11:33:06 rescue38 gps[1243]: config: prefix: wl key: sender value=db
Feb 7 11:33:06 rescue38 gps[1243]: connecting to DB, using driver mysql
Feb 7 11:33:06 rescue38 gps[1243]: setting DB option: dbname to: greylist
Feb 7 11:33:06 rescue38 gps[1243]: setting DB option: host to: 127.0.0.1
Feb 7 11:33:06 rescue38 gps[1243]: setting DB option: password to: (hidden)
Feb 7 11:33:06 rescue38 gps[1243]: setting DB option: username to: pfpolicy
Feb 7 11:33:06 rescue38 gps[1243]: connected to DB
Feb 7 11:33:06 rescue38 gps[1243]: SELECT * FROM network WHERE 1=0
Feb 7 11:33:06 rescue38 gps[1243]: testing table failed: network : DB: : 1146: Table 'greylist.network' doesn't exist , creating table
Feb 7 11:33:06 rescue38 gps[1243]: CREATE TABLE network ( address VARCHAR(16) not null default '',comment VARCHAR(30) DEFAULT '', PRIMARY KEY (address ))
Feb 7 11:33:06 rescue38 gps[1243]: table network created
Feb 7 11:33:07 rescue38 gps[1243]: created wl module: network, type: dbcached
Feb 7 11:33:07 rescue38 gps[1243]: SELECT * FROM pattern WHERE 1=0
Feb 7 11:33:07 rescue38 gps[1243]: testing table failed: pattern : DB: : 1146: Table 'greylist.pattern' doesn't exist , creating table
Feb 7 11:33:07 rescue38 gps[1243]: CREATE TABLE pattern ( expression VARCHAR(200) NOT NULL DEFAULT '',comment VARCHAR(30) DEFAULT '', PRIMARY KEY (expression ))
Feb 7 11:33:07 rescue38 gps[1243]: table pattern created
Feb 7 11:33:07 rescue38 gps[1243]: created wl module: pattern, type: dbcached
Feb 7 11:33:07 rescue38 gps[1243]: SELECT * FROM recipient WHERE 1=0
Feb 7 11:33:07 rescue38 gps[1243]: testing table failed: recipient : DB: : 1146: Table 'greylist.recipient' doesn't exist , creating table
Feb 7 11:33:07 rescue38 gps[1243]: CREATE TABLE recipient ( address VARCHAR(200) NOT NULL DEFAULT '',comment VARCHAR(30) DEFAULT '', PRIMARY KEY (address ))
Feb 7 11:33:07 rescue38 gps[1243]: table recipient created
Feb 7 11:33:07 rescue38 gps[1243]: created wl module: recipient, type: db
Feb 7 11:33:07 rescue38 gps[1243]: SELECT * FROM sender WHERE 1=0
Feb 7 11:33:07 rescue38 gps[1243]: testing table failed: sender : DB: : 1146: Table 'greylist.sender' doesn't exist , creating table
Feb 7 11:33:07 rescue38 gps[1243]: CREATE TABLE sender ( address VARCHAR(200) NOT NULL DEFAULT '',comment VARCHAR(30) DEFAULT '', PRIMARY KEY (address ))
Feb 7 11:33:07 rescue38 gps[1243]: table sender created
Feb 7 11:33:07 rescue38 gps[1243]: created wl module: sender, type: db
Feb 7 11:33:07 rescue38 gps[1243]: SELECT * FROM triplet WHERE 1=0
Feb 7 11:33:07 rescue38 gps[1243]: testing table failed: triplet : DB: : 1146: Table 'greylist.triplet' doesn't exist , creating table
Feb 7 11:33:07 rescue38 gps[1243]: CREATE TABLE triplet (client_address VARCHAR(40),sender VARCHAR(160) NOT NULL,recipient VARCHAR(160) NOT NULL,ip64 NUMERIC(4,0) DEFAULT 0 NOT NULL,ip32 NUMERIC(4,0) DEFAULT 0 NOT NULL,ip16 NUMERIC(4,0) DEFAULT 0 NOT NULL,ip8 NUMERIC(4,0) DEFAULT 0 NOT NULL,count INT NOT NULL DEFAULT '0',uts INT NOT NULL,PRIMARY KEY (recipient,sender,ip64,ip32,ip16,ip8))
Feb 7 11:33:07 rescue38 gps[1243]: CREATE INDEX sender_recipient_index ON triplet(sender(15),recipient(15))
Feb 7 11:33:07 rescue38 gps[1243]: table triplet created
Feb 7 11:33:07 rescue38 gps[1243]: input: helo_name=someorg.org queue_id=8045F2AB23 sender=dailyreckoning@electricmessage.co.uk recipient=user@mydomain.org client_address=192.168.0.254 client_name=another.domain.tld message_origin=another.domain.tld[1.2.3.4]
Feb 7 11:33:07 rescue38 gps[1243]: SELECT comment FROM recipient WHERE address='user@mydomain.org' LIMIT 1
Feb 7 11:33:07 rescue38 gps[1243]: SELECT comment FROM sender WHERE address='dailyreckoning@electricmessage.co.uk' LIMIT 1
Feb 7 11:33:07 rescue38 gps[1243]: SELECT count,uts FROM triplet WHERE ( sender='dailyreckoning@electricmessage.co.uk' AND recipient='user@mydomain.org' AND ip64=192 AND ip32=168 AND ip16=0 AND ip8=254 )
Feb 7 11:33:07 rescue38 gps[1243]: new: 'dailyreckoning@electricmessage.co.uk' -> 'user@mydomain.org', '192.168.0.254'
Feb 7 11:33:07 rescue38 gps[1243]: INSERT INTO triplet VALUES ('192.168.0.254','dailyreckoning@electricmessage.co.uk','user@mydomain.org',192,168,0,254,0,1107797587)
Feb 7 11:33:07 rescue38 gps[1243]: action=dunno
Feb 7 11:33:07 rescue38 gps[1243]: input: helo_name=smtp.yahoo.com queue_id=8045F2AB24 sender=someuser@yahoo.com recipient=someuser@mydomain.org client_address=216.145.54.171 client_name=smtp.yahoo.com
Feb 7 11:33:07 rescue38 gps[1243]: SELECT comment FROM recipient WHERE address='someuser@mydomain.org' LIMIT 1
Feb 7 11:33:07 rescue38 gps[1243]: SELECT comment FROM sender WHERE address='someuser@yahoo.com' LIMIT 1
Feb 7 11:33:07 rescue38 gps[1243]: SELECT count,uts FROM triplet WHERE ( sender='someuser@yahoo.com' AND recipient='someuser@mydomain.org' AND ip64=216 AND ip32=145 AND ip16=54 AND ip8=171 )
Feb 7 11:33:07 rescue38 gps[1243]: new: 'someuser@yahoo.com' -> 'someuser@mydomain.org', '216.145.54.171'
Feb 7 11:33:07 rescue38 gps[1243]: INSERT INTO triplet VALUES ('216.145.54.171','someuser@yahoo.com','someuser@mydomain.org',216,145,54,171,0,1107797587)
Feb 7 11:33:07 rescue38 gps[1243]: action=dunno
Feb 7 11:33:07 rescue38 gps[1243]: ignoring garbage:
Feb 7 11:33:07 rescue38 gps[1243]: disconnecting from DB

[b]RUN #2[/b]

gps.conf was left identical to previous run.

root@rescue38:~/src/mail/gps-1.002$ src/gps -v /etc/postfix/configs/gps.conf

Re: v1.002 Segmentation Fault

Here may be some additional information to help.

shelms@rescue38:~/src/mail/gps-1.002$ strace -f src/gps -v /etc/postfix/configs/gps.conf , std::allocator > ()
#7 0x08056dcb in std::out_of_range::~out_of_range ()
#8 0x00dd079d in __libc_start_main () from /lib/tls/libc.so.6
#9 0x0804b12d in ?? ()
(gdb)

Perhaps libdbi choked?

I added the following to src/db.cpp and the code was never reached.

247a248,250
> if(verbose)
> syslog(LOG_DEBUG,"DBI_CON_QUERYF returned");
>

Based on the core and the code, DBI_CON_QUERYF is failing. It doesn't appear any of the code after this query is executed. Are there known good versions of libdbi that may work better than the latest code they released?

Thanks again.
Steve

Re: v1.002 Segmentation Fault

I cannot reproduce the segfault here. Actually, we are running the 1.002 quite happily for 2 weeks now.
I note that you have different versions of libdbi and libdbi-drivers. Between version 7.1 and 7.2 someone fixed the problem with dbi_quote function (escape a MySQL string). You should upgrade your libdbi-drivers (or downgrade libdbi).

To test you can try adding

#define OLD_DBI_VERSION
before
#ifdef OLD_DBI_VERSION

in triplet.h or just remove the whole #else / #endif part of the clause.

Let me (and probably others know) whether my guess is right and many thanks for the helpful debugging info.