[Home]

Summary:ASTERISK-08440: GetConfig + #include causes segfault
Reporter:Steven Sokol (ssokol)Labels:
Date Opened:2006-12-27 09:49:54.000-0600Date Closed:2007-01-04 16:34:58.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) test.conf
Description:The GetConfig manager command used by the GUI appears to always cause a memory exception if the configuration file being loaded includes another file using the #include directive.

Ironically I was looking into ways of disabling the reading of #included files when I came across this.  When I remove the #include, the GetConfig worked fine.  I've included a back trace below.

****** ADDITIONAL INFORMATION ******

/usr/src/asterisk-1.4/4207: No such file or directory.
Attaching to process 4207.
Reading symbols for shared libraries . done
Reading symbols for shared libraries .............................................................................................................................. done
0x90019d3c in select ()
(gdb) continue
Continuing.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
[Switching to process 4207 thread 0x460b]
0x00036109 in CB_ADD (str=0x0) at config.c:100
100             int siz = strlen(str);
(gdb) bt
#0  0x00036109 in CB_ADD (str=0x0) at config.c:100
#1  0x00037f8a in config_text_file_load (database=0xb062a3c0 "\001\200", table=0xb062a2c0 "", filename=0xb062ab46 "extensions.conf", cfg=0x625c60, withcomments=1) at config.c:851
#2  0x000367a8 in ast_config_internal_load (filename=0xb062ab46 "extensions.conf", cfg=0x625c60, withcomments=1) at config.c:1270
#3  0x000391fb in ast_config_load_with_comments (filename=0xb062ab46 "extensions.conf") at config.c:1303
#4  0x0005a690 in action_getconfig (s=0x626640, m=0xb062aa38) at manager.c:1017
ASTERISK-1  0x000619f7 in process_message (s=0x626640, m=0xb062aa38) at manager.c:2004
ASTERISK-2  0x00062325 in generic_http_callback (format=0, requestor=0x627558, uri=0xffffffff <Address 0xffffffff out of bounds>, params=0x625b50, status=0xb0631ec8, title=0xb0631ecc, contentlength=0xb0631ec4) at manager.c:2491
ASTERISK-3  0x0004c8d3 in ast_httpd_helper_thread (data=0x627550) at http.c:354
ASTERISK-4  0x000a2c0c in dummy_start (data=0x627570) at utils.c:545
ASTERISK-5  0x90023d87 in _pthread_body ()
(gdb)
Comments:By: Jason Parker (jparker) 2006-12-27 12:12:57.000-0600

Just to be clear, you're saying you have file1.conf which #includes file2.conf which in turn #includes file3.conf?
By: Steven Sokol (ssokol) 2006-12-27 12:21:10.000-0600

Quell - Sorry to be unclear.  I actually intended only a single level of include (i.e. file1.conf #includes file2.conf).
By: Jason Parker (jparker) 2006-12-27 12:24:07.000-0600

strange..  I believe what "should" happen, is when you read the #included file, if you modify any of it, it will save it back into the main file.  I know I've seen this work before..  did something maybe change between an early 1.4 beta and 1.4.0?
By: Steven Sokol (ssokol) 2006-12-27 13:50:35.000-0600

I just uploaded the very simple configuration file which is the "file2.conf" in the example.  File 1 is my extensions.conf.
By: Jason Parker (jparker) 2006-12-27 14:40:01.000-0600

asked on IRC too, but...you might not see it.

Could you try removing that ; from file2.conf?
By: Tilghman Lesher (tilghman) 2006-12-28 10:31:10.000-0600

Closing this one, since you uploaded a patch to ASTERISK-8446.  In the future, please upload patches to the original bug, instead of creating a duplicate report.
By: Anthony LaMantia (alamantia) 2006-12-28 17:48:38.000-0600

Hi ssokol,

I have discovered the source of the problem with the processing of a text based configuration file while using the comment buffer and have uploaded a fix to a branch i have made for this issue (as well as for working on solutions to the other issue you have reported)

if you can test out my branch and let me know what your results are , it would be great.

the branch is located here:
http://svn.digium.com/svn/asterisk/team/anthonyl/8678-commentbuffer/
By: Steven Sokol (ssokol) 2006-12-29 11:08:27.000-0600

anthonyl - I tested your fix an it did not blow up on my test, so I think you may have the issue with blank comments in includes fixed.  

I did notice, however, that the web server itself (the integrated HTTP server) is completely hosed.  If your versions is built against trunk (or 1.4 head vs. 1.4 stable) then this is the same issue I was having a few days ago.

Is this a known issue?

Thanks,

Steve
By: Anthony LaMantia (alamantia) 2007-01-02 08:38:28.000-0600

"I did notice, however, that the web server itself (the integrated HTTP server) is completely hosed."

how do you mean hosed, i think you may mean the issue of writing information from "included" files to the main file that you are processing? if you that is known( on the asterisk-gui mailing list as well as from your bug report)..

if it's in another way can you please describe the situation

also, my branch was made off 1.4svn
By: Steven Sokol (ssokol) 2007-01-02 09:26:07.000-0600

alamantia - Sorry for the vague description.  The issue seems to have been resolved in any case, as the version of 1.4 head I pulled yesterday is working fine.  What appeared to happen was a deadlock in the http server or elsewhere in the manager which occurred as soon as the login was complete.  Once you logged in the http server stopped responding.

Thanks -ssokol
By: Anthony LaMantia (alamantia) 2007-01-02 09:42:01.000-0600

ah, sounds good
also just to comment the issue was really not with blank-comments at all.. it was with the entire processing flow when using the comment buffer.

the comment buffer was being destroyed when the processing of the included file was finished. then it would be used again by the original function(thinking it still existed).
By: Anthony LaMantia (alamantia) 2007-01-04 15:49:48.000-0600

assigned to file to look at for a possible commit.
By: Joshua C. Colp (jcolp) 2007-01-04 16:34:57.000-0600

Fixed in 1.4 as of revision 49551 and trunk as of revision 49552. Peace!