Summary:ASTERISK-11160: When I start my sipp simulator, it crashes in a minute
Reporter:Private Name (falves11)Labels:
Date Opened:2008-01-05 13:19:24.000-0600Date Closed:2008-01-10 13:07:32.000-0600
Versions:Frequency of
Environment:Attachments:( 0) blowup3.txt
( 1) valgrind.txt
Description:My applicaton makes use of ODBC heavily, and it makes asterisk crash always, when tested with a simulator. I makes no difference if I use the Easysoft driver or freetds. The machine is RHEL 5. Also, I always need to change /main/autoservice.c and eaise the max number of events to monitor, otherwise it complains about it. I think that the trunk version should have a higher number of events monitored in autoservice.c
Comments:By: Caio Begotti (caio1982) 2008-01-05 13:21:40.000-0600

The autoservice.c change is one thing, what about your sipp thing supposed to crash Asterisk? How could someone test it and reproduce the bug? Give more details if that's really another issue to check.

By: Private Name (falves11) 2008-01-05 13:31:37.000-0600

if you want full access to the box please write to me at falves1@hotmail.com. I can show you how I set it up, also you may copy my /sipp directory. But it will be difficult to reproduce it unless you have my exact system, which is a SQL database that controls routing using func_odbc and also when the calls drops I a use another odbc call to signal that event to the database. In this test, all calls go to another asterisk which answers and waits 5 seconds and hangs up the call. The test-bed is designed to mimic a high volume wholesale switch.

By: Caio Begotti (caio1982) 2008-01-05 13:36:14.000-0600

No problem, I wanted to reproduce it locally.

Maybe some bug marshall will ask to log in anyway as you didn't investigate it deeply to post information like .conf files, detailed call flow or the ODBC functions involved. It could be a SQL bug, not func_odbc's fault.

By: Tilghman Lesher (tilghman) 2008-01-07 11:42:35.000-0600

Please upload the contents of your res_odbc.conf.

By: Tilghman Lesher (tilghman) 2008-01-09 13:37:27.000-0600

I believe this should be fixed now with the commit from ASTERISK-10897, revision 97077.  Can you verify?