Summary: | ASTERISK-25347: Crash on res_odbc reload in SOCK_flush_output from /usr/lib64/psqlodbc.so | ||
Reporter: | Oliver Rafael Peña (oliver.pena) | Labels: | |
Date Opened: | 2015-08-26 10:20:35 | Date Closed: | 2020-01-14 11:13:45.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_odbc |
Versions: | 11.16.0 | Frequency of Occurrence | One Time |
Related Issues: | |||
Environment: | OS: SHMZ release 6.5 (Final) CPU: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz Number of Cores: 24 PostgreSQL: 9.2 postgresql-odbc: version 08.04.0200 unixODBC 2.2.14 | Attachments: | ( 0) backtrace1.txt ( 1) odbc_configs.txt |
Description: | Asterisk core crashed after a module reload via AMI
[Edit by Rusty - please don't post extensive debug into the issue description. Please attach files using More > Attach Files] | ||
Comments: | By: Asterisk Team (asteriskteam) 2015-08-26 10:20:37.237-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2015-08-28 11:33:33.153-0500 Please follow the instructions for collecting backtraces and attach the trace to the issue. https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Oliver Rafael Peña (oliver.pena) 2015-08-28 11:49:03.788-0500 Backtrace file. By: Rusty Newton (rnewton) 2015-08-31 08:40:55.145-0500 Unfortunately the trace does not appear useful as there is no debug symbols. You set the frequency field to "one time". Are you unable to reproduce this issue? If not then we'll close this out and you'll have to post a new trace when you get one with symbols. By: Oliver Rafael Peña (oliver.pena) 2015-08-31 14:16:24.145-0500 This is the backtrace with the symbols. I'm not able to reproduce the issue. as you say, this happened one time, and after a migration from Asterisk 1.8. Hope you find something here. i'll let you know if this happens again. By: Rusty Newton (rnewton) 2015-09-04 09:40:42.110-0500 Thanks! You might also attach all of your odbc and res_odbc configuration files. Being that the crash happens on reload it may be helpful to see the configuration being read. By: Oliver Rafael Peña (oliver.pena) 2015-09-04 10:49:55.175-0500 Here are the odbc configurations. if i missed anything let me know. No more occurrences of the problem by now. Thank you for you time! By: Rusty Newton (rnewton) 2015-09-05 10:37:37.862-0500 Oh! Can you install debug symbols for the third party libraries and then collect the trace again? {noformat} #0 0x00007f80621f1298 in SOCK_flush_output () from /usr/lib64/psqlodbc.so #0 0x00007f80621f1298 in SOCK_flush_output () from /usr/lib64/psqlodbc.so No symbol table info available. #1 0x00007f80621cf94a in ?? () from /usr/lib64/psqlodbc.so No symbol table info available. #2 0x00007f80621d0482 in CC_connect () from /usr/lib64/psqlodbc.so No symbol table info available. #3 0x00007f80621d08a1 in PGAPI_Connect () from /usr/lib64/psqlodbc.so No symbol table info available. #4 0x00007f8062204cf6 in SQLConnect () from /usr/lib64/psqlodbc.so No symbol table info available. #5 0x00007f80997018c2 in SQLConnect () from /usr/lib64/libodbc.so.2 No symbol table info available. {noformat} By: Asterisk Team (asteriskteam) 2015-09-19 12:00:21.670-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines |