[svn-commits] pabelanger: branch pabelanger/issue17165 r257512 - in /team/pabelanger/issue1...
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Thu Apr 15 15:37:58 CDT 2010
Author: pabelanger
Date: Thu Apr 15 15:37:54 2010
New Revision: 257512
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=257512
Log:
Merged revisions 257262,257267,257343,257427,257493 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r257262 | tilghman | 2010-04-14 18:57:35 -0400 (Wed, 14 Apr 2010) | 15 lines
Yet another issue where the conversion of the application delimiter to comma caused an issue.
Application arguments within the feature map could possibly contain a comma,
which conflicts with the syntax of the features.conf configuration file. This
patch allows the argument to be wrapped in parentheses or quoted, to allow the
application arguments to be interpreted as a single configuration parameter.
(closes issue #16646)
Reported by: pinga-fogo
Patches:
20100414__issue16646.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
Review: https://reviewboard.asterisk.org/r/547/
................
r257267 | tilghman | 2010-04-14 19:08:52 -0400 (Wed, 14 Apr 2010) | 16 lines
Blocked revisions 257266 via svnmerge
........
r257266 | tilghman | 2010-04-14 18:08:11 -0500 (Wed, 14 Apr 2010) | 10 lines
When forwarding a message, ensure that prepending works correctly.
This is a regression in 1.4, only.
(closes issue #17103)
Reported by: mglazer
Patches:
20100408__issue17103.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
................
r257343 | lmadsen | 2010-04-15 09:44:38 -0400 (Thu, 15 Apr 2010) | 9 lines
Merged revisions 257342 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257342 | lmadsen | 2010-04-15 08:41:45 -0500 (Thu, 15 Apr 2010) | 1 line
Update address of the bug tracker.
........
................
r257427 | lmadsen | 2010-04-15 15:41:05 -0400 (Thu, 15 Apr 2010) | 21 lines
Merged revisions 257426 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257426 | lmadsen | 2010-04-15 14:40:33 -0500 (Thu, 15 Apr 2010) | 13 lines
Update backtrace.txt documentation.
Update the backtrace.txt documentation so it conforms to the same layout as
other documents we've been working on recently. Additionally, add a bunch of
new information about gathering backtraces for crashes and deadlocks, along
with ways of verifying your file before uploading it. Create a couple of one
line commands for people to generate the files we need.
(closes issue #17190)
Reported by: lmadsen
Patches:
backtrace.txt.patch-2 uploaded by lmadsen (license 10)
Tested by: lmadsen, pabelanger
........
................
r257493 | tilghman | 2010-04-15 16:30:15 -0400 (Thu, 15 Apr 2010) | 20 lines
Merged revisions 257467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257467 | tilghman | 2010-04-15 15:24:50 -0500 (Thu, 15 Apr 2010) | 13 lines
Don't recreate peer, when responding to a repeated deregistration attempt.
When a reply to a deregistration is lost in transmit, the client retries the
deregistration. Previously, this would cause a realtime/autocreate peer to be
loaded back into memory, after it had already been correctly purged. Instead,
we just want to resend the reply without loading the peer.
(closes issue #16908)
Reported by: kkm
Patches:
20100412__issue16908.diff.txt uploaded by tilghman (license 14)
Tested by: kkm
........
................
Modified:
team/pabelanger/issue17165/ (props changed)
team/pabelanger/issue17165/channels/chan_sip.c
team/pabelanger/issue17165/configs/features.conf.sample
team/pabelanger/issue17165/doc/backtrace.txt
team/pabelanger/issue17165/main/features.c
Propchange: team/pabelanger/issue17165/
------------------------------------------------------------------------------
Binary property 'branch-1.4-blocked' - no diff available.
Propchange: team/pabelanger/issue17165/
------------------------------------------------------------------------------
Binary property 'branch-1.4-merged' - no diff available.
Propchange: team/pabelanger/issue17165/
------------------------------------------------------------------------------
--- svnmerge-integrated (original)
+++ svnmerge-integrated Thu Apr 15 15:37:54 2010
@@ -1,1 +1,1 @@
-/trunk:1-257257
+/trunk:1-257511
Modified: team/pabelanger/issue17165/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/team/pabelanger/issue17165/channels/chan_sip.c?view=diff&rev=257512&r1=257511&r2=257512
==============================================================================
--- team/pabelanger/issue17165/channels/chan_sip.c (original)
+++ team/pabelanger/issue17165/channels/chan_sip.c Thu Apr 15 15:37:54 2010
@@ -12947,6 +12947,21 @@
ast_string_field_set(p, exten, name);
build_contact(p);
+ if (req->ignore) {
+ /* Expires is a special case, where we only want to load the peer if this isn't a deregistration attempt */
+ const char *expires = get_header(req, "Expires");
+ int expire = atoi(expires);
+
+ if (ast_strlen_zero(expires)) { /* No expires header; look in Contact */
+ if ((expires = strcasestr(get_header(req, "Contact"), ";expires="))) {
+ expire = atoi(expires + 9);
+ }
+ }
+ if (!ast_strlen_zero(expires) && expire == 0) {
+ transmit_response_with_date(p, "200 OK", req);
+ return 0;
+ }
+ }
peer = find_peer(name, NULL, TRUE, FINDPEERS, FALSE, 0);
if (!(peer && ast_apply_ha(peer->ha, sin))) {
/* Peer fails ACL check */
Modified: team/pabelanger/issue17165/configs/features.conf.sample
URL: http://svnview.digium.com/svn/asterisk/team/pabelanger/issue17165/configs/features.conf.sample?view=diff&rev=257512&r1=257511&r2=257512
==============================================================================
--- team/pabelanger/issue17165/configs/features.conf.sample (original)
+++ team/pabelanger/issue17165/configs/features.conf.sample Thu Apr 15 15:37:54 2010
@@ -77,9 +77,11 @@
; on the outbound channels, as well. Otherwise, only the original channel
; will have access to these features.)
;
-; The syntax for declaring a dynamic feature is the following:
+; The syntax for declaring a dynamic feature is any of the following:
;
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,<AppArguments>[,MOH_Class]]
+;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,"<AppArguments>"[,MOH_Class]]
+;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>([<AppArguments>])[,MOH_Class]
;
; FeatureName -> This is the name of the feature used in when setting the
; DYNAMIC_FEATURES variable to enable usage of this feature.
@@ -94,7 +96,9 @@
; The "caller" is the channel that executed the Dial application, while
; the "callee" is the channel called by the Dial application.
; Application -> This is the application to execute.
-; AppArguments -> These are the arguments to be passed into the application.
+; AppArguments -> These are the arguments to be passed into the application. If you need
+; commas in your arguments, you should use either the second or third
+; syntax, above.
; MOH_Class -> This is the music on hold class to play while the idle
; channel waits for the feature to complete. If left blank,
; no music will be played.
@@ -115,6 +119,10 @@
;
;testfeature => #9,peer,Playback,tt-monkeys ;Allow both the caller and callee to play
; ;tt-monkeys to the opposite channel
+;
+; Set arbitrary channel variables, based upon CALLERID number (Note that the application
+; argument contains commas)
+;retrieveinfo => #8,peer,Set(ARRAY(CDR(mark),CDR(name))=${ODBC_FOO(${CALLERID(num)})})
;
;pauseMonitor => #1,self/callee,Pausemonitor ;Allow the callee to pause monitoring
; ;on their channel
Modified: team/pabelanger/issue17165/doc/backtrace.txt
URL: http://svnview.digium.com/svn/asterisk/team/pabelanger/issue17165/doc/backtrace.txt?view=diff&rev=257512&r1=257511&r2=257512
==============================================================================
--- team/pabelanger/issue17165/doc/backtrace.txt (original)
+++ team/pabelanger/issue17165/doc/backtrace.txt Thu Apr 15 15:37:54 2010
@@ -1,10 +1,25 @@
+===============================================================================
+===
+=== Collecting Backtrace Information
+===
+=== Last updated: 2010-04-12
+===============================================================================
+
This document is intended to provide information on how to obtain the
backtraces required on the asterisk bug tracker, available at
-https://issues.asterisk.org. The information is required by developers to
-help fix problem with bugs of any kind. Backtraces provide information
-about what was wrong when a program crashed; in our case,
-Asterisk. There are two kind of backtraces (aka 'bt') which are
-useful: bt and bt full.
+https://issues.asterisk.org.
+
+-------------------------------------------------------------------------------
+--- Overview
+-------------------------------------------------------------------------------
+
+The backtrace information is required by developers to help fix problem with
+bugs of any kind. Backtraces provide information about what was wrong when a
+program crashed; in our case, Asterisk.
+
+-------------------------------------------------------------------------------
+--- Preparing Asterisk To Produce Core Files On Crash
+-------------------------------------------------------------------------------
First of all, when you start Asterisk, you MUST start it with option
-g. This tells Asterisk to produce a core file if it crashes.
@@ -26,6 +41,10 @@
optimization or the backtrace will be (nearly) unusable. This can be
done by selecting the 'DONT_OPTIMIZE' option in the Compiler Flags
submenu in the 'make menuselect' tree before building Asterisk.
+
+Running a production server with DONT_OPTIMIZE is generally safe.
+You'll notice the binary files may be a bit larger, but in terms of
+Asterisk performance, and impact should be negligible.
After Asterisk crashes, a core file will be "dumped" in your /tmp/
directory. To make sure it's really there, you can just type the
@@ -44,11 +63,21 @@
above example), it is important to look at the file timestamps in
order to determine which one you really intend to look at.
-Now that we've verified the core file has been written to disk, the
-final part is to extract 'bt' from the core file. Core files are
-pretty big, don't be scared, it's normal.
-
-*** NOTE: Don't attach core files on the bug tracker, we only need the bt and bt full. ***
+-------------------------------------------------------------------------------
+--- Getting Information After A Crash
+-------------------------------------------------------------------------------
+
+There are two kind of backtraces (aka 'bt') which are useful: bt and bt full.
+
+Now that we've verified the core file has been written to disk, the final part
+is to extract 'bt' from the core file. Core files are pretty big, don't be
+scared, it's normal.
+
+******************************************************************************
+*** NOTE: Don't attach core files on the bug tracker as they are only useful *
+*** on the machine they were generated on. We only need the output of *
+*** the 'bt' and 'bt full.' *
+******************************************************************************
For extraction, we use a really nice tool, called gdb. To verify that
you have gdb installed on your system:
@@ -63,11 +92,25 @@
This GDB was configured as "i386-linux".
debian:/tmp#
-Which is great, we can continue. If you don't have gdb installed, go install gdb.
-
-Now load the core file in gdb, as follows:
-
-debian:/tmp# gdb asterisk /tmp/core.26252
+If you don't have gdb installed, go install gdb. You should be able to install
+using something like: apt-get install gdb --or-- yum install gdb
+
+Now load the core file in gdb with the following command. This will also save
+the output of gdb to the /tmp/backtract.txt file.
+
+# gdb -se "asterisk" -c /tmp/core.26252 | tee /tmp/backtrace.txt
+
+******************************************************************************
+*** TIP!
+*** Just run the following command to get the output into the
+*** backtrace.txt file, ready for uploading to the issue tracker. Be sure
+*** to change the name of the core file to your actual core dump file:
+***
+*** gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c /tmp/core.26252 > /tmp/backtrace.txt
+***
+******************************************************************************
+
+
[...]
(You would see a lot of output here.)
[...]
@@ -83,6 +126,7 @@
Now at the gdb prompt, type: bt
You would see output similar to:
+
(gdb) bt
#0 0x29b45d7e in ?? ()
#1 0x08180bf8 in ?? ()
@@ -108,6 +152,7 @@
The bt's output is the information that we need on the bug tracker.
Now do a bt full as follows:
+
(gdb) bt full
#0 0x29b45d7e in ?? ()
No symbol table info available.
@@ -148,13 +193,9 @@
No symbol table info available.
(gdb)
-We also need gdb's output. That output gives more details compared to
-the simple "bt". So we recommend that you use bt full instead of bt.
-But, if you could include both, we appreciate that.
-
-The final "extraction" would be to know all traces by all
-threads. Even if asterisk runs on the same thread for each call, it
-could have created some new threads.
+The final "extraction" would be to know all traces by all threads. Even if
+Asterisk runs on the same thread for each call, it could have created some new
+threads.
To make sure we have the correct information, just do:
(gdb) thread apply all bt
@@ -183,15 +224,54 @@
That output tells us crucial information about each thread.
-Now, if you turned on logging upload your gdb.txt file. Otherwise,
-create an output.txt file and dump your "bt full" (and/or "bt")
-ALONG WITH "thread apply all bt" into it.
-
-Note: Please ATTACH your output, DO NOT paste it as a note.
-
-And you're ready for upload on the bug tracker.
-
-
-If you have questions or comments regarding this documentation, feel
-free to pass by the #asterisk-bugs channel on irc.freenode.net.
-
+-------------------------------------------------------------------------------
+--- Getting Information For A Deadlock
+-------------------------------------------------------------------------------
+
+Whenever supplying information about a deadlock (i.e. when you run the
+'core show locks' command on the Asterisk console), it is useful to also have
+additional information about the threads. We can generate this information by
+attaching to a running Asterisk process and gathering that information.
+
+You can easily attach to a running Asterisk process, gather the output required
+and then detach from the process all in a single step. Execute the following
+command and upload the resulting backtrace-threads.txt file to the Asterisk
+issue tracker:
+
+ gdb -ex "thread apply all bt" --batch /usr/sbin/asterisk `pidof asterisk` > /tmp/backtrace-threads.txt
+
+Note that this gathers information from the running Asterisk process, so you
+want to make sure you run this command immediately before or after gathering
+the output of 'core show locks'. You can gather that information by running the
+following command:
+
+ asterisk -rx "core show locks" > /tmp/core-show-locks.txt
+
+-------------------------------------------------------------------------------
+--- Verify Your Backtraces
+-------------------------------------------------------------------------------
+
+Before uploading your backtraces to the issue tracker, you should double check
+to make sure the data you have is of use to the developers. Check your
+backtrace files to make sure you're not seeing several of the following:
+
+ <value optimized out>
+
+If you are, then you likely haven't compiled with DONT_OPTIMIZE. The impact of
+DONT_OPTIMIZE is negligible on most systems. Be sure you've enabled the
+DONT_OPTIMIZE flag within the Compiler Flags section of menuselect. After
+doing so, be sure to run 'make install' and restart Asterisk.
+
+-------------------------------------------------------------------------------
+--- Uploading Your Information To The Issue Tracker
+-------------------------------------------------------------------------------
+
+You're now ready to upload your files to the Asterisk issue tracker (located at
+https://issues.asterisk.org).
+
+******************************************************************************
+*** NOTE: Please ATTACH your output! DO NOT paste it as a note! *
+******************************************************************************
+
+If you have questions or comments regarding this documentation, feel free to
+pass by the #asterisk-bugs channel on irc.freenode.net.
Modified: team/pabelanger/issue17165/main/features.c
URL: http://svnview.digium.com/svn/asterisk/team/pabelanger/issue17165/main/features.c?view=diff&rev=257512&r1=257511&r2=257512
==============================================================================
--- team/pabelanger/issue17165/main/features.c (original)
+++ team/pabelanger/issue17165/main/features.c Thu Apr 15 15:37:54 2010
@@ -4419,25 +4419,33 @@
ast_unregister_features();
for (var = ast_variable_browse(cfg, "applicationmap"); var; var = var->next) {
char *tmp_val = ast_strdupa(var->value);
- char *exten, *activateon, *activatedby, *app, *app_args, *moh_class;
+ char *activateon;
struct ast_call_feature *feature;
-
- /* strsep() sets the argument to NULL if match not found, and it
- * is safe to use it with a NULL argument, so we don't check
- * between calls.
- */
- exten = strsep(&tmp_val,",");
- activatedby = strsep(&tmp_val,",");
- app = strsep(&tmp_val,",");
- app_args = strsep(&tmp_val,",");
- moh_class = strsep(&tmp_val,",");
-
- activateon = strsep(&activatedby, "/");
+ AST_DECLARE_APP_ARGS(args,
+ AST_APP_ARG(exten);
+ AST_APP_ARG(activatedby);
+ AST_APP_ARG(app);
+ AST_APP_ARG(app_args);
+ AST_APP_ARG(moh_class);
+ );
+
+ AST_STANDARD_APP_ARGS(args, tmp_val);
+ if (strchr(args.app, '(')) {
+ /* New syntax */
+ args.moh_class = args.app_args;
+ args.app_args = strchr(args.app, '(');
+ *args.app_args++ = '\0';
+ if (args.app_args[strlen(args.app_args) - 1] == ')') {
+ args.app_args[strlen(args.app_args) - 1] = '\0';
+ }
+ }
+
+ activateon = strsep(&args.activatedby, "/");
/*! \todo XXX var_name or app_args ? */
- if (ast_strlen_zero(app) || ast_strlen_zero(exten) || ast_strlen_zero(activateon) || ast_strlen_zero(var->name)) {
+ if (ast_strlen_zero(args.app) || ast_strlen_zero(args.exten) || ast_strlen_zero(activateon) || ast_strlen_zero(var->name)) {
ast_log(LOG_NOTICE, "Please check the feature Mapping Syntax, either extension, name, or app aren't provided %s %s %s %s\n",
- app, exten, activateon, var->name);
+ args.app, args.exten, activateon, var->name);
continue;
}
@@ -4449,20 +4457,23 @@
}
AST_RWLIST_UNLOCK(&feature_list);
- if (!(feature = ast_calloc(1, sizeof(*feature))))
- continue;
+ if (!(feature = ast_calloc(1, sizeof(*feature)))) {
+ continue;
+ }
ast_copy_string(feature->sname, var->name, FEATURE_SNAME_LEN);
- ast_copy_string(feature->app, app, FEATURE_APP_LEN);
- ast_copy_string(feature->exten, exten, FEATURE_EXTEN_LEN);
+ ast_copy_string(feature->app, args.app, FEATURE_APP_LEN);
+ ast_copy_string(feature->exten, args.exten, FEATURE_EXTEN_LEN);
- if (app_args)
- ast_copy_string(feature->app_args, app_args, FEATURE_APP_ARGS_LEN);
-
- if (moh_class)
- ast_copy_string(feature->moh_class, moh_class, FEATURE_MOH_LEN);
-
- ast_copy_string(feature->exten, exten, sizeof(feature->exten));
+ if (args.app_args) {
+ ast_copy_string(feature->app_args, args.app_args, FEATURE_APP_ARGS_LEN);
+ }
+
+ if (args.moh_class) {
+ ast_copy_string(feature->moh_class, args.moh_class, FEATURE_MOH_LEN);
+ }
+
+ ast_copy_string(feature->exten, args.exten, sizeof(feature->exten));
feature->operation = feature_exec_app;
ast_set_flag(feature, AST_FEATURE_FLAG_NEEDSDTMF);
@@ -4477,13 +4488,13 @@
continue;
}
- if (ast_strlen_zero(activatedby))
+ if (ast_strlen_zero(args.activatedby))
ast_set_flag(feature, AST_FEATURE_FLAG_BYBOTH);
- else if (!strcasecmp(activatedby, "caller"))
+ else if (!strcasecmp(args.activatedby, "caller"))
ast_set_flag(feature, AST_FEATURE_FLAG_BYCALLER);
- else if (!strcasecmp(activatedby, "callee"))
+ else if (!strcasecmp(args.activatedby, "callee"))
ast_set_flag(feature, AST_FEATURE_FLAG_BYCALLEE);
- else if (!strcasecmp(activatedby, "both"))
+ else if (!strcasecmp(args.activatedby, "both"))
ast_set_flag(feature, AST_FEATURE_FLAG_BYBOTH);
else {
ast_log(LOG_NOTICE, "Invalid 'ActivatedBy' specification for feature '%s',"
@@ -4492,8 +4503,8 @@
}
ast_register_feature(feature);
-
- ast_verb(2, "Mapping Feature '%s' to app '%s(%s)' with code '%s'\n", var->name, app, app_args, exten);
+
+ ast_verb(2, "Mapping Feature '%s' to app '%s(%s)' with code '%s'\n", var->name, args.app, args.app_args, args.exten);
}
ast_unregister_groups();
More information about the svn-commits
mailing list