You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi ,
We recently upgraded from 0.7.0 to 0.11.0. With the latest version(0.11.0) we are observing crash while fetching AMQP headers.
Basically we have applications written in Java and C++. For c++ applications we are using rabbitmq-c 0.11.0 version. Java based applications are using spring-rabbit version is 2.3.10. There is an exchange of messages between c++ and java via RMQ. Scenario :
When Java based applications are setting empty AMQP headers (key is set , but value is either not set or set to NULL) , C++ applications are crashing while fetching it.
BT:
Thread 1 (Thread 0x7f86ad7fa700 (LWP 27862)):
#0 0x00007f893d1b6387 in raise () from /lib64/libc.so.6 #1 0x00007f893d1b7a78 in abort () from /lib64/libc.so.6 #2 0x00007f893dac6a95 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6 #3 0x00007f893dac4a06 in ?? () from /lib64/libstdc++.so.6 #4 0x00007f893dac4a33 in std::terminate() () from /lib64/libstdc++.so.6 #5 0x00007f893dac4c53 in __cxa_throw () from /lib64/libstdc++.so.6 #6 0x00007f893dac51ed in operator new(unsigned long) () from /lib64/libstdc++.so.6 #7 0x00007f893db23cd9 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) () from /lib64/libstdc++.so.6 #8 0x00007f893db23e96 in std::string::_M_mutate(unsigned long, unsigned long, unsigned long) ()
from /lib64/libstdc++.so.6 #9 0x00007f893db2445e in std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) () from /lib64/libstdc++.so.6 #10 0x00007f893f487b65 in AMQPMessage::addHeader (this=0x7f8690003000, name=0x7f86ad7eefc0,
value=0x7f86ad7eefb0) at src/AMQPMessage.cpp:138 #11 0x00007f893f48ae3e in AMQPQueue::setHeaders (this=0x7f86900e7fb0, p=0x7f87e4098228)
at src/AMQPQueue.cpp:738 #12 0x00007f893f48a868 in AMQPQueue::sendConsumeCommand (this=0x7f86900e7fb0) at src/AMQPQueue.cpp:674 #13 0x00007f893f489f6b in AMQPQueue::Consume (this=0x7f86900e7fb0, param=0, timeout=1)
at src/AMQPQueue.cpp:511
Core Analysis : frame #12
(gdb) p (p->headers.entries[0].value.value.bytes.len)
$13 = 6
(gdb) p (p->headers.entries[1].value.value.bytes.len)
$14 = 3472615286093461794 ---------> Len appears to be some garbage value .
(gdb)
When run on valgrind , we observed invalid read at AMQPMessage::addHeader() due to un-initialized heap.
orign source of un-initialized block was pointing to malloc() at amqp_decode_table() in amqp_table.c
we tried initializing the memory using memset() after malloc(). With this we are not observing crash and able fetch the headers correctly.
entries = malloc(allocated_entries * sizeof(amqp_table_entry_t));
memset(entries, 0, allocated_entries * sizeof(amqp_field_value_t));
Please note that this issue was not observed with rabbitmq-c 0.7.0.
Also we do not observe this if AMQP headers are set and fetched within c++ applications using rabbitmq-c 0.11.0.
Kindly please check on this. If the workaround we applied is a valid fix , please do consider it to fix in your official release.
The text was updated successfully, but these errors were encountered:
Hi ,
We recently upgraded from 0.7.0 to 0.11.0. With the latest version(0.11.0) we are observing crash while fetching AMQP headers.
Basically we have applications written in Java and C++. For c++ applications we are using rabbitmq-c 0.11.0 version. Java based applications are using spring-rabbit version is 2.3.10. There is an exchange of messages between c++ and java via RMQ.
Scenario :
When Java based applications are setting empty AMQP headers (key is set , but value is either not set or set to NULL) , C++ applications are crashing while fetching it.
BT:
Thread 1 (Thread 0x7f86ad7fa700 (LWP 27862)):
#0 0x00007f893d1b6387 in raise () from /lib64/libc.so.6
#1 0x00007f893d1b7a78 in abort () from /lib64/libc.so.6
#2 0x00007f893dac6a95 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
#3 0x00007f893dac4a06 in ?? () from /lib64/libstdc++.so.6
#4 0x00007f893dac4a33 in std::terminate() () from /lib64/libstdc++.so.6
#5 0x00007f893dac4c53 in __cxa_throw () from /lib64/libstdc++.so.6
#6 0x00007f893dac51ed in operator new(unsigned long) () from /lib64/libstdc++.so.6
#7 0x00007f893db23cd9 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) () from /lib64/libstdc++.so.6
#8 0x00007f893db23e96 in std::string::_M_mutate(unsigned long, unsigned long, unsigned long) ()
from /lib64/libstdc++.so.6
#9 0x00007f893db2445e in std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) () from /lib64/libstdc++.so.6
#10 0x00007f893f487b65 in AMQPMessage::addHeader (this=0x7f8690003000, name=0x7f86ad7eefc0,
value=0x7f86ad7eefb0) at src/AMQPMessage.cpp:138
#11 0x00007f893f48ae3e in AMQPQueue::setHeaders (this=0x7f86900e7fb0, p=0x7f87e4098228)
at src/AMQPQueue.cpp:738
#12 0x00007f893f48a868 in AMQPQueue::sendConsumeCommand (this=0x7f86900e7fb0) at src/AMQPQueue.cpp:674
#13 0x00007f893f489f6b in AMQPQueue::Consume (this=0x7f86900e7fb0, param=0, timeout=1)
at src/AMQPQueue.cpp:511
Core Analysis : frame #12
(gdb) p (p->headers.entries[0].value.value.bytes.len)
$13 = 6
(gdb) p (p->headers.entries[1].value.value.bytes.len)
$14 = 3472615286093461794 ---------> Len appears to be some garbage value .
(gdb)
When run on valgrind , we observed invalid read at AMQPMessage::addHeader() due to un-initialized heap.
orign source of un-initialized block was pointing to malloc() at amqp_decode_table() in amqp_table.c
we tried initializing the memory using memset() after malloc(). With this we are not observing crash and able fetch the headers correctly.
entries = malloc(allocated_entries * sizeof(amqp_table_entry_t));
memset(entries, 0, allocated_entries * sizeof(amqp_field_value_t));
Please note that this issue was not observed with rabbitmq-c 0.7.0.
Also we do not observe this if AMQP headers are set and fetched within c++ applications using rabbitmq-c 0.11.0.
Kindly please check on this. If the workaround we applied is a valid fix , please do consider it to fix in your official release.
The text was updated successfully, but these errors were encountered: