Posted by Harry Slaughter on June 5, 2012 at 9:48pm
7 followers
Jump to:
| Project: | Webform |
| Version: | 6.x-3.18 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Apache, segmentation fault |
Issue Summary
Had an end user configure the following default values for time and date fields:
TIME: Time of Day
DATE: Date of Event
This configuration caused the following gdb backtrace in apache:
Program received signal SIGSEGV, Segmentation fault.
fetch_timezone_offset (tz=0x0, ts=0, transition_time=0x7fff0ea7db88)
at /web01/installSources/php-5.2.17/ext/date/lib/parse_tz.c:295
295 if (!tz->timecnt || !tz->trans) {
(gdb) bt
#0 fetch_timezone_offset (tz=0x0, ts=0, transition_time=0x7fff0ea7db88)
at /web01/installSources/php-5.2.17/ext/date/lib/parse_tz.c:295
#1 0x00002b5ebfe9aea6 in timelib_get_time_zone_info (ts=0, tz=0x0)
at /web01/installSources/php-5.2.17/ext/date/lib/parse_tz.c:369
#2 0x00002b5ebfe7e07d in date_format (format=0xa26f7f0 "c", format_len=1,
t=0x7fff0ea7db88, localtime=1)
at /web01/installSources/php-5.2.17/ext/date/php_date.c:780
#3 0x00002b5ebfe7eb03 in zif_date_format (ht=<value optimized out>,
return_value=0xa237a98, return_value_ptr=<value optimized out>,
this_ptr=<value optimized out>, return_value_used=<value optimized out>)
at /web01/installSources/php-5.2.17/ext/date/php_date.c:1923
#4 0x00002b5ec0140a52 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff0ea7e430)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:200
#5 0x00002b5ec013fc0c in execute (op_array=0xa62bfe0)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:92
#6 0x00002b5ec0140501 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff0ea7f690)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:234
#7 0x00002b5ec013fc0c in execute (op_array=0x9c7bf60)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:92
#8 0x00002b5ec0140501 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff0ea80fa0)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:234
#9 0x00002b5ec013fc0c in execute (op_array=0xb849c30)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:92
#10 0x00002b5ec0140501 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff0ea82390)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:234
#11 0x00002b5ec013fc0c in execute (op_array=0x9372f30)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:92
#12 0x00002b5ec0140501 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff0ea83780)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:234
#13 0x00002b5ec013fc0c in execute (op_array=0x9372f30)
at /web01/installSources/php-5.2.17/Zend/zend_vm_execute.h:92Probably should sanity check those fields on user submit.
Just a quick bug report, sorry if this is fixed already :)
Comments
#1
Huh, that's surprising that it would actually crash Apache. Seems like that large a failure is probably the fault of PHP. That said, we definitely should provide some kind of validation on the default values for date/time to ensure they're going to be acceptable.
#2
any update on a patch to validate what an author is putting into the default value of the date field component? or anyone have a patch workaround i can use in the mean time?
an author on our site put 'mm/dd/yyyy' into the default value of a date field component, and when the form was loaded on the site, the page crashed with a 500 error in both chrome and IE, and firefox just let it open 31 connections to the server.
#3
A sanity check on this data seems pretty challenging given the number of characters and permutations one may use for date formatting. Adding to the fun and games is that neither of the reported dodgy inputs given above cause a crash on my installations (PHP 5.3.3) using both D6 and D7 - the closest I came to a crash was a bunch of notices thrown by
format_date()in includes/common.inc of D7.Just spit-balling here, but maybe one could try an extension module implementation of
hook_webform_component_presave(&$component)and add backslash escaping to any characters that aren't in the list of formatting options? You'll probably end up with some interesting looking dates, but it should prevent borking the server.If that works out we could then try adding a similar handling to the date component as a broader solution.
#4
We can do this with PHP's Date objects relatively easily.
<?phptry {
new Date($form_state['values']['value']);
}
catch (Exception $e) {
form_error($element, t('The provided default date is not valid.'));
}
?>
#5
I also had this problem when an end user applied a bad value for a date format. It would be really nice if the maintainers changed the way in which default values were input. I think the input should look like the actual component (with selectors for year, month, and day along with the popup calendar UI). I know that the default value can also be a relative date ("+2 days") but you could also have some nice selectors for that. This would, of course, be in addition to some default value validation which would be very helpful.
#6
Relative date selectors would be almost impossible to accomplish. Consider relative dates such as "Monday this week" to "Friday next week". Of course there are also +/- ranges, but those are the simplest use-case.