Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

SIGSEGV in msgpack_sbuffer_write #682

Closed
ChitraKumarS opened this issue Jul 13, 2018 · 2 comments
Closed

SIGSEGV in msgpack_sbuffer_write #682

ChitraKumarS opened this issue Jul 13, 2018 · 2 comments
Assignees

Comments

@ChitraKumarS
Copy link

Bug Report

Describe the bug
When there is a multiline log that does not match the Time format I parsers.conf, the app crashes with the following stack trace:
[2018/07/10 15:52:34] [error] [parser:python_regex] Invalid time format %Y:%m-%d %H:%M:%S.
[engine] caught signal (SIGSEGV)
#0  0x7fefd6aba58d      in  ???() at ???:0
#1  0x7fefd6abc751      in  ???() at ???:0
#2  0x44faa5            in  msgpack_sbuffer_write() at lib/msgpack-2.1.3/include/msgpack/sbuffer.h:77
#3  0x44f841            in  msgpack_pack_str() at lib/msgpack-2.1.3/include/msgpack/pack_template.h:759
#4  0x450360            in  flb_tail_mult_append_raw() at plugins/in_tail/tail_multiline.c:246
#5  0x450550            in  flb_tail_mult_process_content() at plugins/in_tail/tail_multiline.c:308
#6  0x44da97            in  process_content() at plugins/in_tail/tail_file.c:248
#7  0x44eb66            in  flb_tail_file_chunk() at plugins/in_tail/tail_file.c:651
#8  0x44c393            in  in_tail_collect_static() at plugins/in_tail/tail.c:129
#9  0x42a4fb            in  flb_input_collector_fd() at src/flb_input.c:995
#10 0x43103f            in  flb_engine_handle_event() at src/flb_engine.c:296
#11 0x43103f            in  flb_engine_start() at src/flb_engine.c:515
#12 0x41d460            in  main() at src/fluent-bit.c:824
#13 0x7fefd6a5dc04      in  ???() at ???:0
#14 0x41b936            in  ???() at ???:0
#15 0xffffffffffffffff  in  ???() at ???:0
Aborted (core dumped)

To Reproduce

  • Rubular link if applicable:
  • Example log message if applicable:
    2018-06-27 19:06:46 INFO ops.py:996 TRANSITION1
    a
    b
    2018:06-27 19:06:46 INFO ops.py:996 TRANSITION2
    a
    b
  • Steps to reproduce the problem:
    parsers.conf
    Format regex
    Regex (?[^(INFO|CRITICAL|WARNING|ERROR|DEBUG)]+){1} (?=(CRITICAL|WARNING|ERROR|DEBUG|INFO)+)(?[^ ]*) *(?[^:]+):(?[^ ]+) (?.)
    Time_Key time
    Time_Format %Y-%m-%d %H:%M:%S
    Time_Keep On

Expected behavior
Just error when log's time format does not match parser's time format. Don't consume string and continue processing messages.

Screenshots

Your Environment

  • Version used:0.13.4
  • Configuration:
  • Environment name and version (e.g. Kubernetes? What version?):
  • Server type and version:
  • Operating System and version:
  • Filters and plugins:

Additional context

Core dumps when some log messages doesn't conform to parser time format

@edsiper edsiper self-assigned this Jul 15, 2018
edsiper added a commit that referenced this issue Jul 23, 2018
If the parser have time lookup enabled and it fails, do not
skip the record, instead add a more verbose message about the
exception.

Signed-off-by: Eduardo Silva <eduardo@treasure-data.com>
edsiper added a commit that referenced this issue Jul 23, 2018
If the parser have time lookup enabled and it fails, do not
skip the record, instead add a more verbose message about the
exception.

Signed-off-by: Eduardo Silva <eduardo@treasure-data.com>
@edsiper
Copy link
Member

edsiper commented Jul 23, 2018

thanks for reporting this issue.

The root cause of the problem was in time_lookup, when it was specified and it failed due to format mismatch, Fluent Bit was packing the wrong number of entries in the outgoing msgpack buffer leading to a corruption.

From now if time lookup fails, it packs the record anyways but prints a more verbose message about the exception and the record will always contain the original time field.

@edsiper edsiper closed this as completed Jul 23, 2018
edsiper added a commit that referenced this issue Jul 24, 2018
If the parser have time lookup enabled and it fails, do not
skip the record, instead add a more verbose message about the
exception.

Signed-off-by: Eduardo Silva <eduardo@treasure-data.com>
edsiper added a commit that referenced this issue Jul 24, 2018
If the parser have time lookup enabled and it fails, do not
skip the record, instead add a more verbose message about the
exception.

Signed-off-by: Eduardo Silva <eduardo@treasure-data.com>
@edsiper
Copy link
Member

edsiper commented Jul 24, 2018

backported to 0.13.5

rawahars pushed a commit to rawahars/fluent-bit that referenced this issue Oct 24, 2022
Signed-off-by: ethinx <eth2net@gmail.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants