librdkafka
librdkafka copied to clipboard
Segfault when destroying producer
Description
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fe12277026c in ?? () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7fe1221e3440 (LWP 1678161))]
(gdb) bt
#0 0x00007fe12277026c in ?? () from /usr/lib/libc.so.6
#1 0x00007fe122720a08 in raise () from /usr/lib/libc.so.6
#2 0x00007fe122709538 in abort () from /usr/lib/libc.so.6
#3 0x00007fe12270a2db in ?? () from /usr/lib/libc.so.6
#4 0x00007fe122719227 in ?? () from /usr/lib/libc.so.6
#5 0x00007fe1227768a1 in ?? () from /usr/lib/libc.so.6
#6 0x00007fe1227711ff in ?? () from /usr/lib/libc.so.6
#7 0x00007fe122776f4d in mtx_lock () from /usr/lib/libc.so.6
#8 0x00007fe122a0e874 in rd_kafka_q_disable0 (do_lock=1, rkq=0x55d7ed6b9a80)
at /home/vb/code/aur/librdkafka/trunk/src/librdkafka-2.1.1/src/rdkafka_queue.h:193
#9 rd_kafka_q_destroy0 (disable=1, rkq=0x55d7ed6b9a80)
at /home/vb/code/aur/librdkafka/trunk/src/librdkafka-2.1.1/src/rdkafka_queue.h:221
#10 rd_kafka_q_destroy_owner (rkq=0x55d7ed6b9a80)
at /home/vb/code/aur/librdkafka/trunk/src/librdkafka-2.1.1/src/rdkafka_queue.h:247
#11 rd_kafka_destroy_final (rk=0x55d7ed6e2b70) at rdkafka.c:954
#12 0x00007fe122a100bb in rd_kafka_destroy_app (rk=0x55d7ed6e2b70, flags=<optimized out>, flags@entry=0) at rdkafka.c:1115
#13 0x00007fe122a1047b in rd_kafka_destroy (rk=<optimized out>) at rdkafka.c:1122
Checklist
IMPORTANT: We will close issues where the checklist has not been completed.
Please provide the following information:
- [x] librdkafka version 2.1.1
- [x] Apache Kafka version: 3.4.0
- [x] librdkafka client configuration:
log.queue = true - [x] Operating system:
Archlinux - [ ] Provide logs (with
debug=..as necessary) from librdkafka - [ ] Provide broker log excerpts
- [ ] Critical issue
Do you use sticky cooperative rebalance strategy?
No. But I've found why it happens. It happens when I use rd_kafka_queue_event_enable and I close the provided fd before calling rd_kafka_destroy.
So I can fix this for my use case but I guess it should not segfault anyway.
This seem to be caused by rk->rk_rep being already destroyed (rdkafka.c:954). Could you provide some example code for reproducing this?
@vbmithr Wanted to ping you on the last request by @emasab. If this issue has been resolved or you found a fix, we can close this issue