| Summary: | ASTERISK-08130: Segfault when inserting a CDR record with primary key overflowing maximum value | ||
| Reporter: | Ove Aursand (aurs) | Labels: | |
| Date Opened: | 2006-11-14 04:39:48.000-0600 | Date Closed: | 2007-01-30 10:58:46.000-0600 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) bt-bt-full.txt | |
| Description: | Asterisk segfaults. Today this has happened at 09:45, 10:33 and 11:14. We're running asterisk 1.2.13. It doesn't crash in periods with low usage. Please advice if you need more details. | ||
| Comments: | By: Ove Aursand (aurs) 2006-11-14 04:44:38.000-0600 Additional info: unixODBC-2.2.11-1.RHEL4.1 postgresql-libs-7.4.13-2.RHEL4.1 postgresql-odbc-7.3-8.RHEL4.1 Database is on another box (postgresql 7.4) By: Ove Aursand (aurs) 2006-11-14 13:34:30.000-0600 Crashes MIGHT have been related to CDR logging. We had a ID column in our CDR table of the datatype INTEGER. This row was auto incremented. The max value for the INTEGER datatype was reached, so the cdrs was not inserted. Since asterisk inserts a unique id for each cdr, we do not need the auto incremented id column as primary key. CDR table is modified, and we will find out tomorrow, when the traffic volume increases again if this caused asterisk to crash. By: Joshua C. Colp (jcolp) 2006-11-15 16:57:32.000-0600 Please do report back and if you need to file another backtrace make sure it is unoptimized. Thanks! By: Even Andre Fiskvik (grevenx) 2006-11-16 00:35:50.000-0600 Issue is indeed related to the CDR logging, just can't figure ut exactly how. First of all, we do have about 15 - 30 SIP calls average, and the issue seemed to be related to traffic / concurrent users as well. The crashes occured frequently, about every hour, when we had much traffic on the server, but during the night, there were no crashes (and little traffic). For each CDR row asterisk tried to insert to PostgreSQL via ODBC, PostgreSQL failed and returned error(primary key had reached max value). It doesn't seem that asterisk provide any error-handling, or gives messages when the database fails to execute the SQL, is this correct? The strange thing is that the server crashed only once an hour, and not each time it tried to insert a CDR row, seems like something accumulates? (due to the noticable interval) We have several other coredumps as well (none unoptimized I am afraid), should I upload them as well? By: Ove Aursand (aurs) 2006-11-16 01:58:47.000-0600 Still no crashes after the change in the CDR table. So it is 100% certain that these crashes were related to cdr (we're using cdr_odbc with postgres), as grEvenX said. We can't provide a unoptimized backtrace. If anyone wants to reproduce this, create a table with a auto-incrementing ID row in your CDR table. Set the sequence value to 3 billion or something, that is out of the int4 range. Crashes will probably come frequently, depending on the traffic volume. By: Serge Vecher (serge-v) 2006-11-16 14:28:03.000-0600 grEvenX: can you please provide a backtrace from non-optimized build? By: Ove Aursand (aurs) 2006-11-17 05:30:39.000-0600 serge-v: grEvenX and I work in the same company. We can not recreate this on a live system, but if there is a way to simulate calls, we can give it a shot on a dev-server. Tips? By: Serge Vecher (serge-v) 2006-11-20 14:31:24.000-0600 aurs: many people like to use SIPp to generate SIP traffic. rkarlsba, who is monitoring this bug, I believe, has experience in using it ... By: Serge Vecher (serge-v) 2007-01-09 13:05:09.000-0600 aurs, grEvenX: what's happening with this issue? By: Joshua C. Colp (jcolp) 2007-01-30 10:58:46.000-0600 It has been 2 months in total now without a response, if you have reproduced this and have something please feel free to reopen. Thanks! | ||