merging #1
Open
merging #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PettitWesley
pushed a commit
that referenced
this pull request
Jun 16, 2021
output_thread patch #1 : pipe creation is platform dependent, in unixes it's achieved through the pipe syscall but in windows it's a socket pair created through libevent which means instead of read/write we need to use recv/send which was already abstracted through flb_pipe_(r/w). output_thread patch #2 : in windows the SOCKET data type is defined as an UINT_PTR which means in 64 bit operating systems it's an 8 byte number instead of 4. libevent abstracts this through the evutil_socket_t data type which in turn is abstracted using the flb_pipefd_t data type in fluent bit. The problem comes to play when calling mk_event_channel_create which receives 2 int pointers to return both pipe endpoints. This means there are 2 possible bugs (one of which was happening and the other is not really a concern I think) : Since mk_event_channel_create was only modifying the low part of the elements in the ch_parent_events array and the structure was not zeroed when allocated, the high parts of those 64 bit members contained garbage which caused any winsock calls to return error 10038 (not a socket). That's the reason why I added a memset call in line 421. There is still a possible issue with mk_event_channel_create which we should fix by moving our platform dependent data type to mk_lib and defining our flb local data types to those if need be (for consistency). Signed-off-by: Leonardo Alminana <[email protected]>
PettitWesley
pushed a commit
that referenced
this pull request
Jun 17, 2021
output_thread patch #1 : pipe creation is platform dependent, in unixes it's achieved through the pipe syscall but in windows it's a socket pair created through libevent which means instead of read/write we need to use recv/send which was already abstracted through flb_pipe_(r/w). output_thread patch #2 : in windows the SOCKET data type is defined as an UINT_PTR which means in 64 bit operating systems it's an 8 byte number instead of 4. libevent abstracts this through the evutil_socket_t data type which in turn is abstracted using the flb_pipefd_t data type in fluent bit. The problem comes to play when calling mk_event_channel_create which receives 2 int pointers to return both pipe endpoints. This means there are 2 possible bugs (one of which was happening and the other is not really a concern I think) : Since mk_event_channel_create was only modifying the low part of the elements in the ch_parent_events array and the structure was not zeroed when allocated, the high parts of those 64 bit members contained garbage which caused any winsock calls to return error 10038 (not a socket). That's the reason why I added a memset call in line 421. There is still a possible issue with mk_event_channel_create which we should fix by moving our platform dependent data type to mk_lib and defining our flb local data types to those if need be (for consistency). Signed-off-by: Leonardo Alminana <[email protected]>
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
PettitWesley
pushed a commit
that referenced
this pull request
Aug 14, 2024
The tls variable for out_flush_params is not initialized as the
flb_start function is not called during the dry run. Call flb_init
directly and then shutdown the engine.
configuration test is successful
=================================================================
==63633==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x0001f71b3ac0 in thread T0
#0 0x103c9f260 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x53260)
#1 0x100179d9c in flb_free flb_mem.h:127
#2 0x10017f4a0 in flb_output_exit flb_output.c:481
#3 0x1001cb038 in flb_engine_shutdown flb_engine.c:1119
#4 0x10010d45c in flb_destroy flb_lib.c:240
#5 0x100008c40 in flb_main fluent-bit.c:1348
#6 0x10000c644 in main fluent-bit.c:1456
#7 0x18f11e0dc (<unknown module>)
frame #6: 0x000000010017f4a4 fluent-bit`flb_output_exit(config=0x0000000102b00200) at flb_output.c:481:9
478
479 params = FLB_TLS_GET(out_flush_params);
480 if (params) {
-> 481 flb_free(params);
482 }
483 }
Signed-off-by: Holger Hans Peter Freyther <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.