[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:
|
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 |