IOS Ported libjingle hangs on PhysicalSocketServer::Wait

[GoogleCodeExporter]

Apologies if this is an inappropriate forum for my issue, 

I've ported the latest lib jingle to iOS, modifying macsocketserver to avoid 
compiling framework as carbon when IOS is defined. I also removed the OSX 
definition from main.scons. 
The entire scons is available here: 
https://github.com/alist/libjingle_ios/blob/master/main.scons

In my app, I create a new thread which calls _setupXMPPConnection after app 
startup.  
https://github.com/swyp/swyp/blob/jingle/libSwyp/swypCloudNetService.mm#L92

On line 135, XmppSocket::XmppSocket within xmppsocket.cc believes it has 
created a talk_base::AsyncSocket* socket (it has a valid pointer ref).

Calling the hierarchy:
XmppSocket::XmppSocket /* containing the code:
talk_base::AsyncSocket* socket =
    pth->socketserver()->CreateAsyncSocket(SOCK_STREAM);
*/
PhysicalSocketServer::CreateAsyncSocket
SocketDispatcher::SocketDispatcher
PhysicalSocket::PhysicalSocket 

So far seems normal. 

Then also in pump.DoLogin 
XmppClient::Connect seems to be fine, passing
  if (d_->socket_.get() != NULL)
    return XMPP_RETURN_BADSTATE;
without an issue. 

XmppClient::ProcessStartXmppLogin is never called
XmppSocket::Connect is never called
physicalsocketserver.cc's Bind(const SocketAddress& addr) is never called. 

The thread hangs at PhysicalSocketServer::Wait on line 1287 with:
    int n = select(fdmax + 1, &fdsRead, &fdsWrite, NULL, ptvWait);
it hangs here forever, after running the trace:

#0  talk_base::PhysicalSocketServer::Wait(int, bool) at 
./libjingle/talk/base/physicalsocketserver.cc:1287
#1  talk_base::MessageQueue::Get(talk_base::Message*, int, bool) at 
./libjingle/talk/base/messagequeue.cc:242
#2  talk_base::Thread::ProcessMessages(int) ()
#3  talk_base::Thread::Run() at ./libjingle/talk/base/thread.cc:342
#4  -[swypCloudNetService _setupXMPPConnection] at ./swypCloudNetService.mm:139

It hangs here forever. I'm not sure what to try, socket things aren't calling, 
but I'm not sure if that's a symptom of the hang at Wait, or what. 
I initially began with the auto threading suggestion given at 
http://code.google.com/apis/talk/libjingle/login.html, but this implementation 
seems better to me… Btw that wasn't working. 

Help or advice would save my life. 
Regards.

Original issue reported on code.google.com by atl...@gmail.com on 28 Jan 2012 at 11:04

[GoogleCodeExporter]

Linux manual for "select":  Consider timeout to be undefined after select() 
returns

...so does your code hang after a single iteration through the while(fWait) 
code???

MORE:    On Linux, select() modifies timeout to reflect the amount of time not 
slept; most other implementations do not do this. (POSIX.1-2001 permits either 
behavior.) This causes problems both when Linux code which reads timeout is 
ported to other operating systems, and when code is ported to Linux that reuses 
a struct timeval for multiple select()s in a loop without reinitializing it. 
Consider timeout to be undefined after select() returns.

http://linux.die.net/man/2/select

Original comment by krw2...@gmail.com on 3 Mar 2012 at 3:36

[GoogleCodeExporter]

I guess I should have addded:  since the "select" function is so primitive 
(directly into the kernel), it's very likely that the iOS kernel is setting 
your wait/wakup timer to null after the first call (and not updating it like 
Linux does).

Please let me know if this works.

Keith

Original comment by krw2...@gmail.com on 3 Mar 2012 at 3:40

[GoogleCodeExporter]

How can I build libjingle user armv6 or armv7. not iPhoneSimulator4.3. thank 
you.

Original comment by kan...@gmail.com on 10 Jun 2012 at 3:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

1.reference this:
https://bitbucket.org/ivucica/libjingle-builder
http://blog.csdn.net/ipromiseu/article/details/6140115

2.use this patch,maybe u need to modify some path as yours in patch file. 

3.mail me(guohui.great --- gmail )

Original comment by guohui.g...@gmail.com on 5 Jul 2012 at 6:19

Attachments:

• ivucica-libjingle-builder-52946af5bde4.zip

[GoogleCodeExporter]

Was there ever a workaround found for this issue? It looks like IOS builds are 
still hanging on that same line.

Original comment by Zack.Man...@gmail.com on 18 Mar 2013 at 6:47

[GoogleCodeExporter]

Closing this issue; for updates, follow the iOS-related issues in the WebRTC 
issue tracker.

Original comment by juberti@google.com on 1 Jun 2013 at 4:42

• Changed state: WontFix