My application uses library rabbitmq-c and sometimes it crashes on HP-UX 11.31 with below stack:
#0 0xc00000000054bc70:0 in _waitpid_sys+0x30 () from /lib/hpux64/libc.so.1
#1 0xc000000000562b80:0 in waitpid ()
#2 0xc00000000a3d9e00:0 in <unknown_procedure> + 0xa0 ()
#3 0xc00000000a3da280:0 in <unknown_procedure> + 0x90 ()
#4 <signal handler called> #5 0xc000000000211ab0:0 in _lwp_kill+0x30 () from /lib/hpux64/libpthread.so.1
#6 0xc000000000178810:0 in pthread_kill ()
#7 0xc0000000003f8140:0 in raise ()
#8 0xc000000000508d00:0 in abort ()
#9 0xc0000000043df860:0 in amqp_abort (
#10 0xc0000000043e06f0:0 in amqp_handle_input (state=0x600000000480bc60,
#11 0xc0000000043e1fe0:0 in wait_frame_inner (state=0x600000000480bc60,
#12 0xc00000000a9b4ad0:0 in RabbitMQ::RabbitMQQueueImpl::recv (
#13 0xc00000000a992ee0:0 in consumer_impl::execute (this=0x600000000428edf8)
#14 0xc00000000a436af0:0 in threads::thread_proc(void*)+0x1c0 ()
#15 0xc00000000013fb20:0 in __pthread_bound_body ()
And in log file I can see following message:
Failed to start consumer with configurationInternal error: invalid amqp_connection_state_t->state 0
So as I understand, I get corrupted packet and as a result abort is called from amqp_abort.
I think it isn't a good idea to call abort into library because my application is crashed and I can't
managed this situation (for example clean resources and reconnect or something else).
Is it possible to remove abort function from library?
The problem is that I use only one thread in my program (only one thread
works with connection to rabbitmq)
Is there only one thread in your program, or is there more than one thread but only one which uses librabbitmq? If there's more than one, perhaps another thread is chewing up memory somehow.
I heard that on HP-UX TCP/IP stack protocol API is different to other UNIX
SYSTEMS and to fix it I need use libxnet and _XOPEN_SOURCE_EXTENDED define
This doesn't sound like the problem, but I could be wrong.
From the error message you found in the logs, it looks to me like something is setting state->state to CONNECTION_STATE_IDLE (== 0) between amqp_connection.c lines 234 and 245. The obvious suspect is consume_data but unless things are already corrupted, it's hard to see what could be happening.
If you can run your program in a debugger, try breaking on the abort and examining state's memory at that time. It might give some clues as to what is going wrong.
Does the problem occur when the message rate is high, or low, or is it not correlated with either?
I should also mention I'm looking at git revision 31ecd4f52f17dbf9e189625cd1ba2ad08af29851. Which revision of the library are you using?
first thread creates all things (connection, channels to queue and
exchanges), call basic.consume and start new thread that reads messages from
queue and processes them...
In principle, this is fine. I would still not do it, myself: instead, I would never let a connection "cross over" between threads. But that's probably just superstitious of me :-)
But first thread can call one method, that add some binds and maybe declare
Aha! OK. Yes, that is probably the cause of the problem.
Try making sure that each thread has its own private connection to the broker. Perhaps the thread that only occasionally needs to use a connection could create it when needed, and destroy it when it is finished.
Connections *must* not be shared between threads.
But can it be the root of problem?
I use separate channel for each used exchange and queue.
There is *no* locking in librabbitmq, so *any* use of a connection across threads requires you to do the locking manually.
And one thing for thinking. My program crashes only on HP-UX 11.31, on
windows, Solaris and Linux Red Hat it works well
My guess is that this is just chance. If two threads are sharing a single librabbitmq connection without any mutexing, then the bug exists on all platforms, even if it doesn't manifest deterministically.
 Unless you do some locking yourself, which is difficult and error-prone, and not something I'd recommend.
Is it enough if I cover reading message by mutex and guarantee that I call
bind methods only then I don't call read method?
I can't guarantee that, and it sounds difficult (= impossible, probably) to implement because what if you want to do a bind() while the other thread is blocked, reading from the socket?
Thinking harder about this, I suspect that only a very few limited kinds of concurrent use of a connection can be implemented by managing your own mutexing; to get the full range, there'd have to be very deep reorganisation of the library's structure to use threads internally. Which was an anti-goal when I wrote it initially.
My recommendation, then, is to never try to share a connection between threads.