Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
applied patch fixing XPCGetProtocol issue across threads
Gents, I think I've found a glitch in the MOOSDB source code. This applies to MOOS-IvP 14.7.1 (the latest on moos-ivp.org) with asynchronous clients support active. The problem is more evident when the code is cross compiled for ARM (at least from my experience). The effects of the bug are MOOSDB not starting correctly and continuously dumping error messages regarding a problem in listening for connection from the TCP socket. Actually the output is as follows: # ./MOOSDB ------------------- MOOSDB V10 ------------------- Hosting community "#1" Name look up is off Asynchronous support is on Connect to this server on port 9000 -------------------------------------------------- network performance data published on localhost:9020 listen with "nc -u -lk 9020" Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported Exception Thrown in listen loop: Error Listening To Socket. Operation not supported (goes on endlessly) The cause was identified in an *UDP* socket asked to listen for connections.... After digging a bit in the code I found the problem in XPCGetProtocol. The constructors of this class are concurrently called by two threads, one creating a TCP socket, the other an UDP one. The class has proper mutex locking, BUT uses, as inner data member, the ret value of the system function "getprotobyname()", which returns info about protocols as a pointer to a statically allocated struct (thus creating a non protected shared data between the two concurrent instances). Making local copies (in XPCGetProtocol) of the protocol name and number solved the problem. Please let me know if you agree with my analysis. Best ragards, Alberto Grati Engineering Department E-mail: [email protected]<mailto:[email protected]%20>
- Loading branch information