Memory dump using basic example shown in stdin documentation #4544
Comments
|
I built master and tested on Fedora 35 |
|
Weill, I've tried downloading and compiling Fluentbit's source code again and I keep getting this error. sudo dnf install git cmake flex bison gcc gcc-c++ systemd-devel Thanks for your interest. |
|
@q2dg Thank you for information. I tested your operation, but I can't reproduce your issue... |
|
@q2dg can you send your coredump ? |
|
Yes, of course!
I've uploaded the coredump file here. https://file.io/MCs38yXCH8Hw |
The file is already not available. Could you re-upload them with a longer expiration time? It seems that it does not crash in a specific parser but probably while dereferencing parser->type as the last non-signal handler code ran is flb_parser_do which does nothing that should cause a sigsegv besides the parser-> dereference. Either that or the crash happened in another thread not visible in the print you sent :) Can you compile with -fsanitize=address ? |
|
Well, I don't know if I've done well or not (I don't know how Cmake works)...I've just added these lines in main CMakeLists.txt file: set(CFLAGS -fsanitize=address) Anyway, the result is the same. I reuploaded my coredump file here: https://www.mediafire.com/file/v8ys6ym1wbgyo1k/coredump.zst/file Thanks |
|
Hey, sorry for the delay and tick-tock but i am not used to help on machines i do not control and forgot some extra details: Can you provide me with the unstripped binary you used to get the coredump? Make sure the binary is not stripped. If you build with -DFLB_DEV=On you should have a proper unstripped binary. Also given that we cannot reproduce It makes me think this is some issue triggered by your environment. Have you tried to change your locale to for example C.UTF-8, and run the reproducer again? |
|
Doing export LANG=C.UTF-8 before running FluentBit or having my standard environment it's the same: I get the same error
My fluent-bit binary is not stripped...:
Thanks a lot and sorry for the inconvenience. |
|
Changing the locale led to a very strange outcome but, not helpful. No inconvenience. Just doing our best :) |
|
Here it is: the binary file! https://www.mediafire.com/file/ykprv1vnc869qye/fluent-bit/file |
in_stdin_collect tests !ctx->parser to decide whether a parser is associated with the context or not. The problem with that check is ctx->parser is not explictily initialized in in_stdin_init and the malloc allocation does not guarantee that the memory assigned to ctx, and ctx->parser is zero initialized. This then will lead to undefined behavior where sometimes the ctx->parser will not be 0 and a non existing parser used. Errors like fluent#4544 will then pop up randomly. This fix was validated with valgrind and the example provided in fluent#4544
|
From the gdb session with your coredump and exe: As you can see flb_log_create is passed a 0x0 config and type and level. A 0x0 config pointer will immediately lead to a crash and from what I see in the caller Can you run When i run this i get: This looks like the path that lead to your crash and is an obvious undefined behavior because no initialization to 0 is done with malloc and code relies on it being 0. I made a pull request at https://github.com/ptsneves/fluent-bit/pull/new/issue-4544 |
in_stdin_collect tests !ctx->parser to decide whether a parser is associated with the context or not. The problem with that check is ctx->parser is not explictily initialized in in_stdin_init and the malloc allocation does not guarantee that the memory assigned to ctx, and ctx->parser is zero initialized. This then will lead to undefined behavior where sometimes the ctx->parser will not be 0 and a non existing parser used. Errors like fluent#4544 will then pop up randomly. This fix was validated with valgrind and the example provided in fluent#4544 Signed-off-by: Paulo Neves <[email protected]>
|
YES. IT WORKS!! |
|
Glad it works. Keep in mind this has not been merged yet, and i do not know what is the timeframe or if it will be merged at all :) |
in_stdin_collect tests !ctx->parser to decide whether a parser is associated with the context or not. The problem with that check is ctx->parser is not explictily initialized in in_stdin_init and the malloc allocation does not guarantee that the memory assigned to ctx, and ctx->parser is zero initialized. This then will lead to undefined behavior where sometimes the ctx->parser will not be 0 and a non existing parser used. Errors like #4544 will then pop up randomly. This fix was validated with valgrind and the example provided in #4544 Signed-off-by: Paulo Neves <[email protected]>
|
merged |
in_stdin_collect tests !ctx->parser to decide whether a parser is associated with the context or not. The problem with that check is ctx->parser is not explictily initialized in in_stdin_init and the malloc allocation does not guarantee that the memory assigned to ctx, and ctx->parser is zero initialized. This then will lead to undefined behavior where sometimes the ctx->parser will not be 0 and a non existing parser used. Errors like #4544 will then pop up randomly. This fix was validated with valgrind and the example provided in #4544 Signed-off-by: Paulo Neves <[email protected]> Signed-off-by: Patrick Stephens <[email protected]>
Bug Report
Describe the bug
It is shown in this picture:
Your Environment
I've installed Fluentbit from source in a Fedora 35 system through git clone... (If I do fluent-bit -V I get v.1.9.0)
Thanks!
The text was updated successfully, but these errors were encountered: