[ZBXNEXT-3389] Increase maximum length of data that could be sent by zabbix_sender Created: 2016 Aug 19  Updated: 2016 Sep 06  Resolved: 2016 Sep 06

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G)
Affects Version/s: 2.2.14, 3.0.4, 3.2.0alpha1
Fix Version/s: 2.2.15, 3.0.5, 3.2.0beta2

Type: Change Request Priority: Minor
Reporter: Andris Zeila Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the maximum length of data that could be send by zabbix_sender when using file input is limited to 64kb. This might not enough for LLD data. The maximum lentgh of data accepted by server is 128mb, so there is no need to truncate it to 64kb when sending with zabbix_sender.



 Comments   
Comment by Andris Zeila [ 2016 Aug 19 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-3389

Comment by Aleksandrs Saveljevs [ 2016 Aug 30 ]

(1) Please see r62040 for stylistic suggestions. In particular, it replaces "* 1.5" with "* 3 / 2", for consistency with other places.

wiper Thanks, CLOSED

Comment by Aleksandrs Saveljevs [ 2016 Aug 30 ]

(2) The code in zbx_fgets_alloc() function seems to assume that the read line will be non-empty. However, according to http://stackoverflow.com/questions/3927311/can-fgets-ever-read-an-empty-string and https://www.securecoding.cert.org/confluence/display/c/FIO37-C.+Do+not+assume+that+fgets()+or+fgetws()+returns+a+nonempty+string+when+successful this assumption is wrong, because the input stream may have NUL bytes.

wiper RESOLVED in r62045

asaveljevs Well, strictly speaking, it does not matter much, but if we wish to be pedantic, then the behavior of zbx_fgets_alloc() is different if NUL occurs in the first position or somewhere in the middle. In the first case, it will not call fgets() again. In the second case, it will. It should be consistent, considering that zbx_fgets_alloc() has the potential of graduating beyond being a "static" function. REOPENED.

wiper RESOLVED in r62082

asaveljevs CLOSED

Comment by Andris Zeila [ 2016 Aug 31 ]

Released in:

  • pre-2.2.15rc1 r62088
  • pre-3.0.5rc1 r62089
  • pre-3.2.0beta2 r62091
Comment by Sandis Neilands (Inactive) [ 2016 Sep 01 ]

(3) Please take a look at CID 152405.

** CID 152405:  Null pointer dereferences  (FORWARD_NULL)
/src/zabbix_sender/zabbix_sender.c: 1004 in main()


________________________________________________________________________________________________________
*** CID 152405:  Null pointer dereferences  (FORWARD_NULL)
/src/zabbix_sender/zabbix_sender.c: 1004 in main()
998     /* take long and hit timeout, so we limit values to 250 per connection */
999     #define VALUES_MAX	250
1000     
1001     int	main(int argc, char **argv)
1002     {
1003     	FILE			*in;
>>>     CID 152405:  Null pointer dereferences  (FORWARD_NULL)
>>>     Assigning: "key_value" = "NULL".
1004     	char			*in_line = NULL, hostname[MAX_STRING_LEN], key[MAX_STRING_LEN], *key_value = NULL,
1005     				clock[32];
1006     	int			total_count = 0, succeed_count = 0, buffer_count = 0, read_more = 0, ret = FAIL,
1007     				timestamp;
1008     	size_t			in_line_alloc = MAX_BUFFER_LEN, key_value_alloc = 0;
1009     	double			last_send = 0;

asaveljevs Looks like a false positive to me.

sasha I agree. CLOSED

Generated at Thu Mar 28 12:01:55 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.