[Home]

Summary:ASTERISK-09997: Help command in CLI dumps core under Solaris 10 X86
Reporter:Frank Tarczynski (ftarz)Labels:
Date Opened:2007-07-31 23:03:58Date Closed:2007-08-03 09:30:17
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I've been trying to get Asterisk 1.4.X running under Solaris 10 x86 with limited success.

I can build Asterisk and get it started but have run in to a problem with a segmentation fault with the "help" command in the CLI.

When I start Asterisk:

# ./asterisk -vvvgc
Asterisk 1.4.9, Copyright (C) 1999 - 2007 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
== Parsing '/var/etc/asterisk/asterisk.conf': Found
.
.
.
== Registered application 'Skel'
app_skel.so => (Skeleton (sample) Application)
Asterisk Ready.
*CLI>

If I type "help"

*CLI> help
                      !  Execute a shell command
             abort halt  Cancel a running halt
     ael debug contexts  Enable AEL contexts debug (does nothing)
.
.
.
               say load  set/show the say mode
       show parkedcalls  Lists parked calls
Segmentation Fault - core dumped
#

This problem only seems to occur with the "help" command in the CLI.

gdb shows this:

gdb ./asterisk core
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10"...
Core was generated by `./asterisk -vvvgc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcurses.so.1...done.
.
.
.
Loaded symbols for /opt/asterisk/lib/modules/app_skel.so
#0  0xfebd4d0c in strlen () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfebd4d0c in strlen () from /usr/lib/libc.so.1
#1  0xfec2a386 in _ndoprnt () from /usr/lib/libc.so.1
#2  0xfec2d4bb in vsnprintf () from /usr/lib/libc.so.1
#3  0x080e994a in ast_dynamic_str_thread_build_va (buf=0x817625b, max_len=0,
  ts=0x8149720, append=0, fmt=0x811eefd "%25.25s  %s\n",
  ap=0x8046f18 "Pb\027\b") at utils.c:969
#4  0x08089ad8 in ast_cli (fd=1, fmt=0x811eefd "%25.25s  %s\n") at cli.c:69
ASTERISK-1  0x0808d33e in help1 (fd=1, match=0x8047084, locked=1) at cli.c:1746
ASTERISK-2  0x0808d45f in handle_help (fd=1, argc=0, argv=0x8047080) at cli.c:1773
ASTERISK-3  0x0808e05c in ast_cli_command (fd=1, s=0x0) at cli.c:1979
ASTERISK-4  0x08074127 in main (argc=135688218, argv=0x80471fc) at asterisk.c:1388
(gdb) q
#

The segmentation fault is caused by the call to vsnprintf in this function in utils.c:

int ast_dynamic_str_thread_build_va(struct ast_dynamic_str **buf, size_t max_len,
      struct ast_threadstorage *ts, int append, const char *fmt, va_list ap)
{
      int res;
      int offset = (append && (*buf)->len) ? strlen((*buf)->str) : 0;
#if defined(DEBUG_THREADLOCALS)
      struct ast_dynamic_str *old_buf = *buf;
#endif /* defined(DEBUG_THREADLOCALS) */

      res = vsnprintf((*buf)->str + offset, (*buf)->len - offset, fmt, ap);

      /* Check to see if there was not enough space in the string buffer to prepare
       * the string.  Also, if a maximum length is present, make sure the current
       * length is less than the maximum before increasing the size. */
      if ((res + offset + 1) > (*buf)->len && (max_len ? ((*buf)->len < max_len) : 1)) {
              /* Set the new size of the string buffer to be the size needed
               * to hold the resulting string (res) plus one byte for the
               * terminating '\0'.  If this size is greater than the max, set
               * the new length to be the maximum allowed. */
              if (max_len)
                      (*buf)->len = ((res + offset + 1) < max_len) ? (res + offset + 1) : max_len;
              else
                      (*buf)->len = res + offset + 1;

              if (!(*buf = ast_realloc(*buf, (*buf)->len + sizeof(*(*buf)))))
                      return AST_DYNSTR_BUILD_FAILED;

              if (append)
                      (*buf)->str[offset] = '\0';

              if (ts) {
                      pthread_setspecific(ts->key, *buf);
#if defined(DEBUG_THREADLOCALS)
                      __ast_threadstorage_object_replace(old_buf, *buf, (*buf)->len + sizeof(*(*buf)));
#endif /* defined(DEBUG_THREADLOCALS) */
              }

              /* va_end() and va_start() must be done before calling
               * vsnprintf() again. */
              return AST_DYNSTR_BUILD_RETRY;
      }

      return res;
}

I think the fault is caused by a NULL pointer somewhere,but I can't figure-out what's wrong.
Comments:By: Mark Michelson (mmichelson) 2007-08-01 09:22:38

Hmm, the next help line after "show parked calls" is "show queues." Its summary is null, which might be causing the problem. The only thing that seems odd about that is that if I type help I see a command "no debug channel" which also has a null summary and which appears earlier in the command list. When you type help, do you see "no debug channel" in the list of commands and does it also have a null summary? If yes, then the problem is not with the null summary but with something else.
By: Digium Subversion (svnbot) 2007-08-01 12:51:28

Repository: asterisk
Revision: 77871

------------------------------------------------------------------------
r77871 | file | 2007-08-01 12:51:27 -0500 (Wed, 01 Aug 2007) | 4 lines

(closes issue ASTERISK-9997)
Reported by: ftarz
Some platforms don't like it when you pass NULL to vsnprintf so pass "" instead.

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-01 12:53:01

Repository: asterisk
Revision: 77872

------------------------------------------------------------------------
r77872 | file | 2007-08-01 12:53:00 -0500 (Wed, 01 Aug 2007) | 11 lines

Blocked revisions 77871 via svnmerge

........
r77871 | file | 2007-08-01 15:08:51 -0300 (Wed, 01 Aug 2007) | 4 lines

(closes issue ASTERISK-9997)
Reported by: ftarz
Some platforms don't like it when you pass NULL to vsnprintf so pass "" instead.

........

------------------------------------------------------------------------
By: Frank Tarczynski (ftarz) 2007-08-01 21:02:59

OK, so I changed all the NULLs in the ast_cli_entry definitions in apps/app_queue.c to ""s and it worked.

Can you explain why only this line: "show queues" is a problem?

Most interesting is that there is no "show queues" command.  "show queues" results in No such command "show queues".

There also is no such command as "no debug channel" but it shows-up too.
By: Brandon Kruse (bkruse) 2007-08-01 23:38:58

there is a command queue show (queue number)

-bk

that could be what the code is referring to
By: Mark Michelson (mmichelson) 2007-08-02 10:26:24

Both of those commands do exist. If you don't load the appropriate modules, then those commands will not exist, but then again, if you don't load the modules, then they won't show up on the help menu either...
By: Joshua C. Colp (jcolp) 2007-08-03 09:30:16

There are a few CLI commands that have no description... and it could just be that the vsnprintf implementation on Solaris can't handle NULL like was used.