mayank-kratin / libjingle

Automatically exported from code.google.com/p/libjingle
0 stars 0 forks source link

Assertion Failure With PCP in SecureTunnelSessionClient.cc #371

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Compile Libjingle 0.6.14 as described in the README
2. From Libjingle/talk, execute: ./build/dbg/staging/pcp --verbose 
receiver@gmail.com
3. Read full resource from receiver@gmail.com connection
4. From Libjingle/talk/build/dbg/staging, execute: ./pcp --verbose 
sender@gmail.com file_read.extension receiver@gmail.com/(full 
resource):file_write.extension

What is the expected output? What do you see instead?
Expected output: completed file transfer between receiver@gmail.com and 
sender@gmail.com
Seen output: After the tunneling session is initiated and an accept is sent by 
the receiver, the following error occurs on the receiver's end of the 
connection:
Error(common.cc:67): session/tunnel/securetunnelsessionclient.cc(370): ASSERT 
FAILED: ssl_stream_reference_.get() != NULL @ OnAccept
Aborted (core dumped)

What version of the product are you using? On what operating system?
Libjinlge 0.6.14, Ubuntu 12.04, Python 2.7.3, all third party versions 
specified in the README

Please provide any additional information below.
I have attached the full (verbose) debug output from each direction. From what 
little I pretend to know about the program and interactions, it seems like the 
receiver is never actually sending an session accept to the sender (at least in 
the xml stanza sense/space). I looked in the "TunnelSessionClient.cc" and found 
that under the case:STATE_SENTACCPET there is no code executed. I do not know 
if this is what is causing the ssl_stream_reference_ to be null, or is in 
anyway relevant, just one of my many observations while trying to track down 
this error.

Original issue reported on code.google.com by Cummings.Kyle.M on 9 Jul 2012 at 9:12

Attachments:

GoogleCodeExporter commented 9 years ago
Ignore this. Following Issue 135's "patch" fixes the problem. Sorry for the 
needless extra post.

Original comment by Cummings.Kyle.M on 9 Jul 2012 at 10:15