dry-run crashes on MacOS #11089
Description
Bug Report
Describe the bug
fluent-bit --dry-run always crashes on a mac:
zsh ❯ fluent-bit --dry-run
Fluent Bit v4.1.1
* Copyright (C) 2015-2025 The Fluent Bit Authors
* Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
* https://fluentbit.io
______ _ _ ______ _ _ ___ __
| ___| | | | | ___ (_) | / | / |
| |_ | |_ _ ___ _ __ | |_ | |_/ /_| |_ __ __/ /| | `| |
| _| | | | | |/ _ \ '_ \| __| | ___ \ | __| \ \ / / /_| | | |
| | | | |_| | __/ | | | |_ | |_/ / | |_ \ V /\___ |__| |_
\_| |_|\__,_|\___|_| |_|\__| \____/|_|\__| \_/ |_(_)___/
configuration test is successful
fluent-bit(46239,0x1f84d20c0) malloc: *** error for object 0x1f84d20c0: pointer being freed was not allocated
fluent-bit(46239,0x1f84d20c0) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort fluent-bit --dry-run
This appears to be the same issue as #7283, which was closed as stale but no definitive fix was ever reported. Like that issue, it appears to be confined to MacOS, as I cannot reproduce it in Docker:
zsh ❯ docker run --rm -it fluent/fluent-bit:4.1.1 --dry-run
Fluent Bit v4.1.1
* Copyright (C) 2015-2025 The Fluent Bit Authors
* Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
* https://fluentbit.io
______ _ _ ______ _ _ ___ __
| ___| | | | | ___ (_) | / | / |
| |_ | |_ _ ___ _ __ | |_ | |_/ /_| |_ __ __/ /| | `| |
| _| | | | | |/ _ \ '_ \| __| | ___ \ | __| \ \ / / /_| | | |
| | | | |_| | __/ | | | |_ | |_/ / | |_ \ V /\___ |__| |_
\_| |_|\__,_|\___|_| |_|\__| \____/|_|\__| \_/ |_(_)___/
configuration test is successful
To Reproduce
- Steps to reproduce the problem: Run
fluent-bit --dry-runon a Mac.
Expected behavior
No crashing 😄
Screenshots
n/a
Your Environment
- Version used: 4.1.1
- Configuration: N/A, crashes regardless of config provided
- Environment name and version (e.g. Kubernetes? What version?): MacOS 15.6.1
- Server type and version: n/a
- Operating System and version: MacOS 15.6.1
- Filters and plugins: n/a
Additional context
It seems like the call to flb_destroy introduced in 12ed555 is related; commenting that out makes the crash go away for me. But I am not sure what the impact of that would be.