|
Could you please attach the result of
as well?
|
|
If you still have the log file with a crash, could you please show more of it? Starting with line that says "Crashing...", not just the backtrace, but also program counter, registries, etc.
|
|
Added extract from log starting from "Crashing..." till "server stopped"
|
|
Great! Thank you!
Putting it here for easier searching:
|
|
Crash happens in this function, when someone passes NULL in error:
static char *dc_expression_expand_user_macros(const char *expression, char **error)
{
zbx_vector_uint64_t functionids, hostids;
char *out;
zbx_vector_uint64_create(&functionids);
zbx_vector_uint64_create(&hostids);
get_functionids(&functionids, expression);
zbx_dc_get_hostids_by_functionids(functionids.values, functionids.values_num, &hostids);
out = zbx_dc_expand_user_macros(expression, hostids.values, hostids.values_num,
dc_expression_user_macro_validator);
if (NULL != strstr(out, "{$"))
{
*error = zbx_strdup(*error, "cannot evaluate expression: invalid macro value");
zbx_free(out);
}
zbx_vector_uint64_destroy(&hostids);
zbx_vector_uint64_destroy(&functionids);
return out;
}
Here is the relevant piece of objdump with few annotations (according to System V AMD64 ABI calling conventions second parameter error is passed in %rsi register):
From here we need to find out who and when passes NULL instead of valid error and whether crash is reproducible in latest version (so far I've been looking into 3.4.2 sources).
|
|
Hm, it is always called like this...
if (NULL != (expression_ex = DCexpression_expand_user_macros(expression, NULL)))
Seems that latest 3.0, 3.4 and trunk are all affected.
|
|
Wow, nice crash analysis (you read asm like I watch movies  )
If it's always called like this, crashes should be more frequent on invalid user macro's I guess. I see the usage is still different from the function itself, but maybe it's just an unimportant 'wrapping'.
DCexpression_expand_user_macros vs dc_expression_expand_user_macros
Another thing I see: the 'out' variable is returned, but in case of valid error there was a call 'zbx_free(out)'. I hope zbx_free is also setting it's argument (passed as reference?) to NULL. Otherwise it can result in another access violation. (I don't have the zabbix sources with me, so cannot directly validate my assumptions)
|
If it's always called like this, crashes should be more frequent on invalid user macro's I guess.
Yes, this is a bit surprising for me that no one has complained about this for so long. To my understanding Zabbix server will crash whenever it needs to expand trigger expression containing non-numeric user macro. But if there is such a trigger, but Zabbix server does not need to recalculate it and does not need it for notifications, there will be no crashes - this could explain why no crashes were reported so far. Or everyone just gets their trigger expressions spot on! 
maybe it's just an unimportant 'wrapping'.
Yes, DCexpression_expand_user_macros() is just a "public" wrapper of dc_expression_expand_user_macros() which needs configuration cache to be locked, but this can only be done from within dbconfig.c file.
I hope zbx_free() is also setting it's argument (passed as reference?) to NULL.
It does so (thanks to some macro magic, not a reference).
|
|
Dear vso, I believe ZBXNEXT-3210 is to blame.
|
|
Yes, it was broken by ZBXNEXT-3210 but later fixed and now broken again in ZBXNEXT-3659.
3.0.20rc1 is not affected as it has all the necessary NULL checks.
if (NULL != error)
*error = zbx_dsprintf(*error, "macro '%.*s' is not found", len, ptr);
if (NULL != error)
*error = zbx_dsprintf(*error, "macro '%s' value is not numeric", macro);
Also it looks like only affect references for example $1 etc when used in internal notifications for triggers going to unsupported state.
|
|
Fixed in development branch:
svn://svn.zabbix.com/branches/dev/ZBX-14500
|
|
Fixed in:
- pre-3.4.12rc1 r82357
- pre-4.0.0alpha9 (trunk) r82358
|
Generated at Fri Apr 26 08:36:58 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.
objdump_DSswx.gz
zabbix_server_backtrace.log
Team A