[ZBX-10784] Validation of double/Numeric(float) values is inconsistent and sometimes really wrong Created: 2016 May 12  Updated: 2024 Apr 10  Resolved: 2018 Oct 08

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: 2.2.13rc1, 3.0.3rc1, 3.2.0alpha1
Fix Version/s: 4.0.1rc1, 4.2.0alpha1, 4.2 (plan)

Type: Incident report Priority: Major
Reporter: Glebs Ivanovskis (Inactive) Assignee: Michael Veksler
Resolution: Fixed Votes: 1
Labels: float, validation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File sub_issue_4.xml     Text File valgrind_report.txt    
Epic Link: DEV-591
Team: Team A
Team: Team A
Sprint: Sprint 36, Sprint 37, Sprint 38, Sprint 39, Sprint 40, Sprint 41, Sprint 42, Sprint 43, Sprint 44
Story Points: 2

 Description   

Zabbix has multiple functions to check whether string contains a float and several functions to convert string to double. Results of it are really weird.

Calculated item with expression count(float.trapper,#10,.) will count zeros because is_double_suffix() treats "." as a valid number and str2double() than converts it using atof() which cannot return errors.

Calculated item with expression count(float.trapper,#10,+1) will fail to count anything. In 3.0 it will always return 0, in current trunk it will return a visible error. That's because is_double_suffix() rejects numbers starting with plus.

is_double_suffix() is used in trigger function count() and for user macro resolving in trigger and calculated item expressions. is_double correctly says that "." is not a number and numbers starting with plus sign are OK.

The consequences of performing

			zbx_rtrim(c, " \"");
			zbx_ltrim(c, " \"+");

in set_result_type() and get_result_dbl_value() are that one can do so:

$ src/zabbix_sender/zabbix_sender -z localhost -p 30051 -s Testing -k float.trapper -o ' "+ "+ + + -3.0  "   " '
info from server: "processed: 1; failed: 0; total: 1; seconds spent: 0.000066"
sent: 1; skipped: 0; total: 1

and Zabbix will store -3.0 in database.

This affects all checks using text to double conversion at some point: user parameters, external scripts, etc. with type Numeric (float).

There should be one function to validate and optionally convert string containing a decimal number (possibly surrounded by whitespace, possibly quoted, possibly with plus or minus, possibly with exponent or suffixes).

 Comments   
Comment by Glebs Ivanovskis (Inactive) [ 2016 Sep 20 ]

In ZBX-11231 a script returning valid numeric value with extra linefeed character caused very uninformative error:

Received value [1216122185] is not suitable for value type [Numeric (float)]

The problem is that is_double() can skip only space characters while to produce such error message Zabbix trims spaces, LF and CR characters of received value.

Comment by Alexander Vladishev [ 2018 Jul 24 ]

Validation of dot "." should be fixed under this issue. Other issues are very controversial.

mindbound Should the rest of the changes made so far (i.e., the new is_double() that includes the functionality of both is_double_suffix() and old is_double()) be reverted, or should just the support for unary plus be removed? The new is_double() correctly doesn't recognise "." as a valid number. In principle, I could simply add an extra flag/-s for controlling whether unary plus and/or other characters are recognised, similar to what is currently being done with suffixes.

vso please also check with frontend, Zabbix server shall not allow more than frontend allows (it's not only unary plus but also exponent)

Comment by Michael Veksler [ 2018 Oct 03 ]

Available in:

  • 4.0.1rc1 r85422
  • 4.2.0alpha1 (trunk) r85421
Comment by Glebs Ivanovskis [ 2018 Dec 14 ]

Spelling issues in tests/libs/zbxcommon/is_double.yaml: "succseed" → "succeed".

MVekslers Done. Thx.

Comment by Glebs Ivanovskis [ 2018 Dec 22 ]

As I understood only part of original request was completed, but the issue is closed. What should we do about the rest?

Comment by Vladislavs Sokurenko [ 2018 Dec 22 ]

It would be best to create separate issue for the rest, thanks!

Comment by Glebs Ivanovskis [ 2019 Jan 12 ]

ZBX-15444, ZBX-15445, welcome!

Comment by Glebs Ivanovskis [ 2019 Jan 25 ]

ZBX-15494 is related.

Generated at Fri Apr 19 19:14:57 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.