Custom Query (2195 matches)

Known issues with current configure-android:

• Detected TARGET_HOST 'llvm' is not recognized by config.sub.
• C++ STL backend uses gnustl_static (llvm does not support it?).
• The default TARGET_ABI, i.e: 'armeabi', is removed since NDK r17.

Thank you Ryan Wallach for the feedback.

There have been some reports about crash in timer heap (there was #2172, but reported that crash still occurs even after integrating the patch). Creating a stress test for timer heap to reproduce the issue could be useful in identifying the problem and verifying a future solution.

Few notes after running the stress test

• The stress test could reproduce the previously suspected issue of "pop_freelist()+push_freelist() after remove_node() in pj_timer_heap_poll()", here is a bit more description on it:

pop_freelist() will only preserve the timer_id, not the timer entry as the timer entry node has been completely detached from the heap. it may cause crash, as the number of free timer_id is less than timer heap slot, e.g: if the app has 4 timer polling threads, there can be 4 less free timer_id than timer heap slot, while the timer heap slot will grow only when there are 2 free timer heap slot left.

So r5934 removes pop_freelist() + push_freelist() after remove_node().

• The issue described in #2172 (double destroy after cancel_timer() return code not checked) could not be reproduced, but later after a further investigation, found out that it may actually be a false alarm because the poll() sets timer entry group lock to NULL (within the same timer lock block as remove_node()) before invoking callback, so it should be safe from the double destroy issue.

Scenario:

1. send INVITE
2. recv 200/OK
3. app implements on_send_ack() and calls pjsip_inv_create_ack(), but have not sent it.
4. recv retransmission of 200/OK
5. PJSIP auto answers the ACK

The doc of on_send_ack() says:

     * Application creates the ACK request
     *
     * Once it has sent the ACK request, the framework will keep 
     * this ACK request in the cache. Subsequent receipt of 2xx response
     * will not cause this callback to be called, and instead automatic
     * retransmission of this ACK request from the cache will be done
     * by the framework.

But actually pjsip_inv_create_ack() is the one that saves inv->last_ack. So the auto transmission already happens in inv_send_ack() of sip_inv.c, even though app hasn't sent the ACK.