|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-0600||Date Closed:||2011-06-07 14:00:17|
|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 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 res_odbc.c: SQL Execute error -1! Attempting a reconnect...
[Dec 3 17:20:12] WARNING res_odbc.c: Connection is down attempting to reconnect...
[Dec 3 17:20:12] DEBUG res_odbc.c: Disconnected 0 from cdr [cdr]
And then this:
Dec 3 17:20:12 lpbx02 kernel: asterisk: 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.