Some more debug information:<div><br></div><div>Just tried to run on both x86 and ARM. There's a difference in execution flow, even though they connect to the same server from the same subnet.</div><div><br></div><div><div><br></div><div>Similar flow for both:</div><div>- goes into while(amqp_data_in_buffer(state))</div><div>- receives result from server</div><div>- goes to the tick of while(1) loop</div><div>- enters while(amqp_data_in_buffer(state)) for the second time</div><div><br></div><div>ARM:</div><div>- tries to receive result from server again, but recv returns 0, which indicates that peer has performed a shutdown</div><div><br></div><div>x86:</div><div>- (decoded_frame-&gt;frame_type != 0) condition is met, so it returns 0 from function and moves on to sending log in credentials</div><div><br></div><div>If I understand correctly, that comment is relevant to that condition:&nbsp;</div><div>decoded frame type&nbsp;== 0: Returning frame_type of zero indicates either insufficient input, or a complete, ignored frame was read.</div><div><br></div><div><br></div><div>Also, what I noticed, on ARM machine, inside of amqp_handle_input if (state-&gt;inbound_offset &lt; state-&gt;target_size) is true...</div><div><br></div><div>But I'm not sure where to dig further.</div><div>Could it be a bug in rabbitmq-c? Or it's more likely something regarding cross-compiled lib itself or processor spec ?</div></div>