Summary:ASTERISK-13163: Asterisk can crash when database schema is changed
Reporter:Benny Amorsen (amorsen)Labels:
Date Opened:2008-12-03 10:35:42.000-0600Date Closed:2011-06-07 14:00:17
Versions:Frequency of
Description:I had a CDR database on MySQL with a column userfield, which I wanted to change to be called hangupcause. I did this in MySQL:

alter table cdr change column userfield hangupcause varchar(255) NOT NULL default '';

I got this:
[Dec  3 17:20:12] WARNING[21039] res_odbc.c: SQL Execute returned an error -1: 42S22: [MySQL][ODBC 3.51 Driver][mysqld-5.0.51a-log]Unknown column 'userfield' in 'field list' (87)
[Dec  3 17:20:12] WARNING[21039] res_odbc.c: SQL Execute error -1! Attempting a reconnect...
[Dec  3 17:20:12] WARNING[21039] res_odbc.c: Connection is down attempting to reconnect...
[Dec  3 17:20:12] DEBUG[21039] res_odbc.c: Disconnected 0 from cdr [cdr]

And then this:
Dec  3 17:20:12 lpbx02 kernel: asterisk[20978]: segfault at 430 ip 0013f9d9 sp b55e47f0 error 4 in libodbc.so.1.0.0[126000+70000]

Having it as severity "crash" is perhaps overkill, since noone sane will change database schema while keeping asterisk running, but it DID crash...

Fedora 10 with:
Comments:By: Tilghman Lesher (tilghman) 2008-12-04 15:57:15.000-0600

I'm still going to need a backtrace, as required in the bug guidelines.

By: Benny Amorsen (amorsen) 2008-12-05 01:59:07.000-0600

That is unfortunately impossible, since ulimit -c was 0.

By: Tilghman Lesher (tilghman) 2008-12-15 18:14:29.000-0600

Unfortunately, without a backtrace, there is very little I can do.  In fact, given that it crashes within libodbc, it is very likely either a UnixODBC crash or a crash of the backend driver.  While this may have taken down Asterisk, the problem lies in a body of code outside of our control.