It seems I have fixed the issue. I did a backtrace with gdb and saw that the crash was when sqlite3ExprListDup called strdup passing a NULL pointer. I asked on the SQLIte mailing list and they told me that SQLite doesn't use strdup. So, I downloaded the original 3.3.13 SQLite release and compared it to the Freeswitch code. I found out that calls to sqlite3StrDup had been replaced with calls to strdup (see sqliteInt.h). Problem is sqlite3StrDup checks for NULL input, whereas strdup does not. I put the following instead: #define sqliteStrDup(x) (x?strdup(x):NULL)//sqlite3StrDup(x) And now I can create triggers without crashes. Seems to me that as nobody uses triggers inside Freeswitch, this issue has gone unnoticed so far. I will continue testing to discard any side effects. Neven Boric escribió:
Hi,
By looking at the code, I believe there is no limit on the number of rows mod_cdr_sqlite will add to the cdr table. This could lead to (eventually) eating all RAM if you DB is in tmpfs or eating all disk space if it is stored on disk. Is this correct or am I missing something?
To correct this I tried to add a trigger to the table along the lines of:
CREATE TRIGGER IF NOT EXISTS CDR_LIMIT AFTER INSERT ON cdr BEGIN DELETE FROM crd WHERE rowid <= (SELECT MAX(rowid) from cdr) - 100000; END
and no matter how I try to add the trigger, I get a segmentation fault when the code calls sqlite3_exec in switch_core_db_exec.
Currently I'm blaiming SQLite, as there is a somewhat similar issue involving triggers reported for versions older than 3.5.4 (FS is using 3.3.13)
http://sqlite.org/cvstrac/wiki?p=DatabaseCorruption
Of course I could just execute the delete statement manually after every insert, but it is uglier (more costly, non atomic).
Has anyone any experience using triggers with the sqlite version included in FS? Or has anyone tried other solution to limit the number on entries on the cdr table?
Thanks in advance Neven Boric