Summary:ASTERISK-06532: [patch] DateTime crashes on AMD64 system
Reporter:Tom Huibregtse (thuibregtse)Labels:
Date Opened:2006-03-12 22:02:53.000-0600Date Closed:2011-06-07 14:01:07
Versions:Frequency of
Environment:Attachments:( 0) 20060312__bug6710.diff.txt
Description:After updating to SVN-trunk-r12688, existing extensions.conf with DateTime function now crash.

GDB bt full ouptut is:
#0  ast_say_date_with_format_en (chan=0x6a1580, time=1142221952,
   ints=0x2aaaae24e1f2 "0123456789#*ABCD", lang=0x67ffb1 "en", format=0x0,
   timezone=0x0) at say.c:2989
       tm = {tm_sec = 32, tm_min = 52, tm_hour = 20, tm_mday = 12,
 tm_mon = 2, tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0,
 tm_gmtoff = -25200, tm_zone = 0x6a6d6c "MST"}
       res = Variable "res" is not available.


AMD64 platform
Comments:By: Tilghman Lesher (tilghman) 2006-03-12 23:14:08.000-0600

Patch uploaded.  Please TEST and notate if it fixes your issue.

By: Tom Huibregtse (thuibregtse) 2006-03-13 00:05:26.000-0600

Problems apparently still there after updating to version r12714.  Asterisk crashes after dialing an extension with DateTime.

This system is running on AMD64, with SCCP phones.  No changes to extensions.conf layout...other functions (dial phone, native MOH) seem to work fine.

Here is the output from asterisk console showing dial/crash:

   -- SEP000E84F6016D: format request: 268/4
   -- SEP000E84F6016D: Channel SCCP/1101-00000004, capabilities: DEVICE 0x10c (ulaw|alaw|g729) NATIVE 0x10c (ulaw|alaw|g729) BEST 4 (ulaw)
   -- SEP000E84F6016D: New call on line 1101
   -- SEP000E84F6016D: Cisco Digit: 00000001 (1) on line 1101
   -- SEP000E84F6016D: Cisco Digit: 00000000 (0) on line 1101
   -- SEP000E84F6016D: Cisco Digit: 00000000 (0) on line 1101
   -- SEP000E84F6016D: Cisco Digit: 00000000 (0) on line 1101
   -- Executing Answer("SCCP/1101-00000004", "") in new stack
   -- SCCP: Outgoing call has been answered SCCP/1101-00000004 on 1101@SEP000E84F6016D-4
   -- Executing DateTime("SCCP/1101-00000004", "") in new stack
Disconnected from Asterisk server
Executing last minute cleanups

By: Luigi Rizzo (rizzo) 2006-03-13 02:40:50.000-0600

the problem exists on all platforms (as oej and i reported
on friday on the -dev list) and it is due to args.format set to NULL
if the caller doesn't specify a format.

corydon's patch should indeed fix the issue (for the poster: the patch
has not been committed so SVN update won't help - you have to apply
it manually), however it is a bit redundant because ast_get_time_t()
already did the right thing in initializing the time with the proper
Also, supplying a default value for ast_say_date_with_format()
doesn't belong here but in the function itself.
So i would suggest, as a fix, to just remove this line from

      args.format = "c";

and to add the following at the beginning of say.c::say_date_with_format()

static int say_date_with_format(struct ast_channel *chan,, ...
+       if (format == NULL)
+               "ABdY 'digits/at' IMp";
       if (!strcasecmp(lang, "en") ) { /* English syntax */

This is only a quick workaround to avoid the crash.

say.c is going away soon, and if you want a language-specific format
you can easily put your preferred format in the call to DateTime().

By: Olle Johansson (oej) 2006-03-13 02:55:51.000-0600

Corydon76: There is a feature difference between 1.2 head and trunk here that I would like you to look at. 1.2 head has implementation of language-specific default formats, where trunk simply sets it to "c". Can you please check if there's a reason for removing these or if it's done by mistake?


By: Olle Johansson (oej) 2006-03-13 03:05:57.000-0600

Committed Luigi's fix to say.c to prevent the crash. Leaving the rest for Corydon to decide.

By: Tilghman Lesher (tilghman) 2006-03-13 07:36:27.000-0600

What my patch does is to partially revert recent changes to app_sayunixtime.  I don't know where the "c" format came from:  there's no such format in the _with_format implementation, save for the "he" language.

By: Tom Huibregtse (thuibregtse) 2006-03-14 21:08:11.000-0600

The workaround (temporary code tweaks) seems to work.  Thanks!