Hi again
Now I am experiencing very frequently the exception #2, which happens
when, in sess_init_update, one of ice_st's components is NULL.
This even happens in the beggining, in caller before the initial offer
(when ICE procedures are starting). As you can see in the capture, only
a STUN binding request and its answer were captured.
As can be seen in the log, I printed ice_st's components, and they don't
seem to be changed in the call stack (you can see the complete call
stack below).
We can see that ice_st's comp[0] is not NULL, but ice_st's comp[1] is
NULL since on_request_complete
18:52:56.245 stun_sock.c pandre-dbg comp=15C7BC0C i=0 on
sess_on_request_complete
18:52:56.266 stun_sock.c pandre-dbg comp=00000000 i=1 on
sess_on_request_complete
18:52:56.307 ice_strans.c pandre-dbg comp=15C7BC0C i=0 on
stun_on_status(1)
18:52:56.337 ice_strans.c pandre-dbg comp=00000000 i=1 on
stun_on_status(1)
18:52:56.418 ice_strans.c pandre-dbg comp=15C7BC0C i=0 on stun_on_status
18:52:56.457 ice_strans.c pandre-dbg comp=00000000 i=1 on stun_on_status
18:52:56.488 ice_strans.c pandre-dbg comp=15C7BC0C i=0 on
sess_init_update
18:52:56.514 ice_strans.c pandre-dbg comp=00000000 i=1 on
sess_init_update
From previous runs I know that some components can be NULL, but then
they get some value.
In this case, they keep the NULL value until sess_init_update is called.
Is there something missing?
I don't know why this happens, nor do I know how to solve this issue,
despite my efforts.
Best Regards
Pedro Gon?alves
Complete call stack:
> PCCommunicator.exe!sess_init_update(pj_ice_strans *
ice_st=0x15b52c5c) Line 547 + 0x18 bytes C
PCCommunicator.exe!stun_on_status(pj_stun_sock *
stun_sock=0x15c7fe0c, pj_stun_sock_op op=PJ_STUN_SOCK_BINDING_OP, int
status=0) Line 1276 + 0x9 bytes C
PCCommunicator.exe!sess_on_request_complete(pj_stun_session *
sess=0x15c8783c, int status=0, void * token=0x00000001, pj_stun_tx_data
* tdata=0x15ca1c5c, const pj_stun_msg * response=0x15c9fc5c, const void
* src_addr=0x15c81e9c, unsigned int src_addr_len=16) Line 706 + 0x14
bytes C
PCCommunicator.exe!stun_tsx_on_complete(pj_stun_client_tsx *
tsx=0x15ca3f44, int status=0, const pj_stun_msg * response=0x15c9fc5c,
const void * src_addr=0x15c81e9c, unsigned int src_addr_len=16) Line
424 + 0x29 bytes C
PCCommunicator.exe!pj_stun_client_tsx_on_rx_msg(pj_stun_client_tsx
* tsx=0x15ca3f44, const pj_stun_msg * msg=0x15c9fc5c, const void *
src_addr=0x15c81e9c, unsigned int src_addr_len=16) Line 395 + 0x1e
bytes C
PCCommunicator.exe!on_incoming_response(pj_stun_session *
sess=0x15c8783c, unsigned int options=5, const unsigned char *
pkt=0x15c8380c, unsigned int pkt_len=88, pj_stun_msg * msg=0x15c9fc5c,
const void * src_addr=0x15c81e9c, unsigned int src_addr_len=16) Line
1189 + 0x18 bytes C
PCCommunicator.exe!pj_stun_session_on_rx_pkt(pj_stun_session *
sess=0x15c8783c, const void * packet=0x15c8380c, unsigned int
pkt_size=88, unsigned int options=1, void * token=0x00000000, unsigned
int * parsed_len=0x00000000, const void * src_addr=0x15c81e9c, unsigned
int src_addr_len=16) Line 1416 + 0x21 bytes C
PCCommunicator.exe!on_data_recvfrom(pj_activesock_t *
asock=0x15c7ffb8, void * data=0x15c8380c, unsigned int size=88, const
void * src_addr=0x15c81e9c, int addr_len=16, int status=0) Line 817 +
0x25 bytes C
PCCommunicator.exe!ioqueue_on_read_complete(pj_ioqueue_key_t *
key=0x08b458d4, pj_ioqueue_op_key_t * op_key=0x15c81e0c, long
bytes_read=88) Line 341 + 0x38 bytes C
PCCommunicator.exe!ioqueue_dispatch_read_event(pj_ioqueue_t *
ioqueue=0x0da80928, pj_ioqueue_key_t * h=0x08b458d4) Line 549 + 0x16
bytes C
PCCommunicator.exe!pj_ioqueue_poll(pj_ioqueue_t *
ioqueue=0x0da80928, const pj_time_val * timeout=0x0dd3fcac) Line 763 +
0x17 bytes C
PCCommunicator.exe!pjsip_endpt_handle_events2(pjsip_endpoint *
endpt=0x0b9c705c, const pj_time_val * max_timeout=0x0dd3fe7c, unsigned
int * p_count=0x00000000) Line 694 + 0x10 bytes C
PCCommunicator.exe!pjsip_endpt_handle_events(pjsip_endpoint *
endpt=0x0b9c705c, const pj_time_val * max_timeout=0x0dd3fe7c) Line 721
+ 0xf bytes C
PCCommunicator.exe!EventHandler(void * __formal=0x00000000) Line
630 + 0x16 bytes C++
PCCommunicator.exe!thread_main(void * param=0x08af5e7c) Line 413 +
0x11 bytes C
Benny Prijono wrote:
> On Wed, Aug 6, 2008 at 11:42 AM, Pedro Gon?alves
> <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote:
>
> Benny Prijono wrote:
>
> On Tue, Aug 5, 2008 at 6:20 PM, Pedro Gon?alves
> <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>
> <mailto:pedro.pandre at gmail.com
> <mailto:pedro.pandre at gmail.com>>> wrote:
>
> Hi!
>
> With the help from PJSIP list useres, I think I am close to
> having my
> program to use PJSIP's ICE functionalities 100% correctly.
>
>
> Not that I'm discouraging you, but I think you've still got
> some issues to fix there (as discussed on the other thread). :)
> Regarding the crashes below, do you know in what stage did
> these happen? E.g. during ICE creation, in the middle of
> conversation, or during ICE destroy sequence? We had this bug
> that looks similar: http://trac.pjsip.org/repos/ticket/567
>
>
> About the other issues (the ones you told in the other thread, I
> moved the stream destruction to on_media_update(), but these
> problems persist (these problems happen in the answerer).
>
>
> Is the problem still with stream not being closed? So what do you
> exactly do in on_media_update()? And is on_media_update() called? And
> do you close the stream when the call is disconnected? A snippet will
> help.
>
> And lets discuss this on separate/the other thread please.
>
>
>
> About 1), the failing assert, it happens after initial offer /
> answer, but before the subsequent offer, during ICE negotiation
> (more specifically, during ICE connectivity checks).
>
> I've included both the application log and the capture I made
> during the exception.
>
> I can reproduce this behaviour at any time, so if there is
> something I can do to help us debug this issue, just ask.
>
> I've added some debug information in some PJSIP files, in order to
> help me understand the problem. As you can see in the end of the
> log, the assert problem seems to come from somewhere before
> pj_stun_session_on_rx_pkt, is it not?
> 11:19:15.375 stun_session.c pandre-dbg tdata=339762268
> check->tdata=338037852 on pj_stun_session_on_rx_pkt ckid=0
> 11:19:15.687 stun_session.c pandre-dbg tdata=339762268
> check->tdata=338037852 on on_incoming_response ckid=0
> 11:19:16.292 stun_session.c pandre-dbg tdata=339762268
> check->tdata=338037852 on stun_tsx_on_complete(1)
> 11:19:16.335 stun_session.c pandre-dbg tdata=339762268
> check->tdata=338037852 on stun_tsx_on_complete(2)
>
>
> Unfortunately I didn't see the messages (above) in the log, probably
> because the file has not completely been written when the assertion
> occurs. When the "pj_assert(tdata == check->tdata)" assertion occurs,
> does "check->tdata" contain a value, or is it NULL?
>
> Cheers
> Benny
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: compNULL.txt
Url: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080806/4425dfe5/attachment-0001.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compNULL.pcap
Type: application/octet-stream
Size: 472 bytes
Desc: not available
Url : http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080806/4425dfe5/attachment-0001.obj
