themoos / core-moos Goto Github PK

Hi,

This is a minor issue: MSVC complains about Stop() not returning a value:

        bool Stop()
        {
            Thread_.Stop();
        }

should be (I guess):

        bool Stop()
        {
            return Thread_.Stop();
        }

Best,
JL

CMOOSCommsClient::Notify("foo", 3) will not compile (at least on g++ 4.7.3-1ubuntu1) because the second parameter is an int, and there is no overload for int.

Notify called with an int used to implicitly cast to double in pre-10 versions of MOOS. This behavior should be restored.

If:

• You have a MOOS community consisting of only a single client using the AsyncCommClient
• And the client subscribes to DB_UPTIME, and publishes infrequently

Then:

• DB_UPTIME will be added to the MOOSDB's HeldMailMap for the client every time it is updated, but
• The client will not receive anything until any client sends a packet to the MOOSDB, at which point
• All the DB_UPTIME notifications will be received roughly simultaneously, but significantly delayed.

I believe this is because ThreadedCommServer::ProcessClient() only iterates through asynchronous client threads when data is received, and MOOSDBVar changes do not trigger this processing. Thus, poking a variable with uMS or any client transmission will force processing.

Hi there,

I'm trying to run moos inside a docker container derived from Ubuntu 18.04. I want to install only the bare minimum of apt packages to reduce the image size. I'm doing so by passing --no-install-recommends to apt install which prevents installing recommended/suggested packages.

However, I found out that if I pass --no-install-recommends to apt install, then MOOSDB and most other ivp binaries compile but don't run correctly and throw XPCException. This is being thrown somewhere in libMOOS/Comms.

Meanwhile, all is well if I don't pass --no-install-recommends and install all recommended/suggested packages, but obviously this makes the image size pretty big.

This makes me think there's an implicit runtime dependency for XPC communication. I'm trying to figure out what exactly it is, and was wondering if you have a pointer.

For your reference, here's a list of apt packages. The exception happens in both runtime and compile time images.

Runtime image:

• libboost-all-dev
• libfltk1.3
• libjpeg8
• libpcl-dev
• libtiff5
• libtiffxx5
• libvulkan1
• libxft2
• libxi6
• libxinerama1
• python3-empy
• python3-matplotlib
• python3-numpy
• python3-pip
• python3-tk
• python3-toml
• python3-yaml
• python-argparse
• python-empy
• python-future
• python-matplotlib
• python-numpy
• python-pip
• python-tk
• python-toml
• python-yaml
• ros-melodic-ros-base
• xterm
• xxd
• zip
• zlib1g

Compile time image:

• build-essential
• cmake
• curl
• exiftool
• fluid
• freeglut3-dev
• g++
• genromfs
• git
• libboost-all-dev
• libfltk1.3-dev
• libglu1-mesa-dev
• libjpeg-dev
• libopenexr-dev
• libpcl-dev
• libtiff5-dev
• libvulkan-dev
• libxft-dev
• libxi-dev
• libxinerama-dev
• openssh-server
• ninja-build
• nvidia-cg-dev
• python3-dev
• python3-empy
• python3-matplotlib
• python3-numpy
• python3-pip
• python3-tk
• python3-toml
• python3-yaml
• python-argparse
• python-dev
• python-empy
• python-future
• python-matplotlib
• python-numpy
• python-pip
• python-tk
• python-toml
• python-yaml
• subversion
• wget
• xorg-dev
• xterm
• xxd
• zip
• unzip
• zlib1g-dev

Hi, I'm new to MOOS. I want to use time from external source (ROS). Is it enough to modify MOOSLocalTime(). Regards,

I have discovered what I think is a race condition in the MOOSDB related to wildcard subscriptions. It only seems to happen when you have this situation:

App1 registers for message “foo_” from “_”
App2 registers for message “foo”
App3 sends message on “foo”

Note the two different ways to register for messages. Now only App2 will receive the message. If you change this pattern in almost any way, it works fine. For example if App2 registers before App1, or if App3 sends before App2 registers, or if App2 uses wildcard registration then both App1 and App2 will receive the message.

This issue is present in the trunk on Oct. 2 2013.

This is pretty easy to test with a few dead-simple apps. I launched them with pAntler and used a long MSBetweenLaunches to ensure things start in the order I want. Then put a delay in the publishing for enough time for everything to start.

This can also be tested with the umm utility:

Open 4 terminals

in one

./MOOSDB

in the second

./umm -w='foo_:_' --verbose

in the third

./umm -s=foo --verbose

in the forth

./umm -p=foo

Minor point but not sure whether the tone in this help is appropriate in https://github.com/themoos/core-moos/blob/24942423ce3f3ebdb3cee876edb71bdd04dc5555/Core/tools/ktm/ktm.cpp

void PrintHelpAndExit()
{
    std::cerr<<"Kill The MOOS (ktm)\n";
    std::cerr<<"--channel=<address>    address to issue kill on \n";
    std::cerr<<"--port=<int>           port to issue kill on \n";
    std::cerr<<"--phrase=<string>      pass phrase which Suicide listeners are keyed to\n";
    std::cerr<<"--all                  pass to network, it is a massacre\n";
    std::cerr<<"--query                find out who would jump\n";
    std::cerr<<"--name=<string>        only apply if matches pattern\n";

There is a race condition between threads in the MOOSDB caused by getprotobyname and getprotobynumber in XPCGetProtocol.cpp. The result is that the tcp server in the MOOSCommServer can be set as UDP instead of TCP resulting in the listen call continuously throwing an 'operation not supported' exception and putting the MOOSDB into a busy loop.

The solution is to change the getprotobyname and getprotobynumber calls in XPCGetProtocol.cpp to the thread-safe reentrant versions, getprotobyname_r and get protobynumber_r. The Linux Man page for getprotobyname_r provides a good example of the changes necessary.

When using timewarp, m_dfAppStartTime shouldn't be multiplied by timewarp:

The previous line should be :

 m_dfAppStartTime = MOOSTime(false);

Is there a reason for multiple of these these lines to have const on them twice?

This has broken pymoos (https://github.com/davidhodo/pymoos) bindings and how boost-python detects the return values.

The MOOSDB should reset the console color after the server audit lines. (line 110 of ServerAudit.cpp)

Some modifications are needed to successfuly MOOS with AppCasting under Windows.

1. In "AppCastingMOOSApp.h" add:

    #ifdef _WIN32
    #include <io.h>
    #endif 

1. And in "AppCastingMOOSApp.cpp" line 283:

    ~~if(!MOOSStrCmp(term_reporting, "true") && (isatty(1) == 0))~~
    #ifdef _WIN32
    if(!MOOSStrCmp(term_reporting, "true") && (_isatty(1) == 0))
    #else
    if(!MOOSStrCmp(term_reporting, "true") && (isatty(1) == 0))
    #endif 

We’ve found a bug that’s can cause a segfault in MOOSDB, I've attached a patch for a fix as .txt files as that's what's supported for upload. There are possible performance implications with our patch, as we're now mutex locking ProcessClient which may have been concurrent before, and now is more sequential. This can only be avoided with C+17 shared_lock or some complicated back-port of that to C++11 ( our compiler standard).

The bug ultimately caused a segfault in MOOSDB at ThreadedCommServer.cpp#388:

bool ThreadedCommServer::ProcessClient(ClientThreadSharedData &SDFromClient,MOOS::ServerAudit & Auditor)
...
for(q=m_ClientThreads.begin();q!=m_ClientThreads.end();++q)
{
ClientThread* pClient = q->second;
if(m_pfnFetchAllMailCallBack!=NULL && pClient->IsAsynchronous())

because pClient is null/uninitialised. This is caused by a race condition with:

bool ThreadedCommServer::AddAndStartClientThread(XPCTcpSocket & NewClientSocket,const std::string & sName)
...
m_ClientThreads[sName] = pNewClientThread;

Adding to m_ClientThreads needs to be mutually exclusive with any other operation on the map and needs guarding with a mutex (only with the Add though, multiple Reads can happen at once).

ThreadedCommServer.cpp.txt
ThreadedCommServer.h.txt

Since commit 1e61cbb in core-moos, essential-moos fails to build.

This is the commit in question:

------------------------------------------------------------
commit 1e61cbb23f45b2d3b93568243f0518a13e3b1e9e
Author: Paul Newman <[email protected]>
Date:   Sat Jun 10 20:39:37 2017 +0100

    putative efficiency in CMOOSCommPkt

 5 files changed, 79 insertions(+), 102 deletions(-)
------------------------------------------------------------

and the error message in essential-moos is this:

<redacted>/essential-moos/Essentials/pMOOSBridge/MOOSUDPLink.cpp:173:19: error: no member named 'Fill' in 'CMOOSCommPkt'
            PktRx.Fill(pBuffer+q,nRqd);
            ~~~~~ ^
1 error generated.

Iterate is delayed after receiving mail. Even indefinitely if mail is regular and faster than app_tick.

OnNewMail is always called as soon as mail arrives, even if max_app_tick should be limiting it.

Reproduction:

• A simple MOOSApp that subscribes to a single variable. Run with iterate_mode=2, app_tick=1, max_app_tick=1. Print a message on each Iterate and OnNewMail.
• publish data at 2hz with umm
• Observe behavior of the subscriber app: OnNewMail is called at 2hz, Iterate is not called.

Test app

• Run with main --moos_app_tick=1 --moos_max_app_tick=1 --moos_iterate_mode=2
• Run umm with umm -p=TEST_VAR:10@2

#include <MOOS/libMOOS/App/MOOSApp.h>

#include <iostream>
#include <chrono>

using namespace std::chrono;

class TestApp : public CMOOSApp
{
	bool OnConnectToServer() override;
	bool OnNewMail(std::list<CMOOSMsg>& Main) override;
	bool Iterate() override;

private:
	steady_clock::time_point iter_time, mail_time;
	int mail_count{0}, iter_count{0};
};

int main(int argc, char** argv){

	TestApp App;

	std::cerr << "Running...\n";
	App.Run("TestApp", "mission.moos", argc, argv);
	std::cerr << "Done\n";
}

bool TestApp::OnConnectToServer() {
	std::cerr << "OnConnectToServer\n";

	Register("TEST_VAR", 0);
	return true;
}

bool TestApp::OnNewMail(std::list<CMOOSMsg>& mail) {
	auto now = steady_clock::now();
	double dt_s = duration_cast<duration<double>>(now - mail_time).count();
	mail_time = now;

	std::cerr << "\nOnNewMail " << mail_count++
	          << " " << dt_s << ": " + std::to_string(mail.size()) + "\n";

	for(CMOOSMsg& msg : mail){
		msg.Trace();
	}

	return true;
}


bool TestApp::Iterate() {
	auto now = steady_clock::now();
	double dt_s = duration_cast<duration<double>>(now - iter_time).count();
	iter_time = now;

	std::cerr << "\nIterate " << iter_count++ << " " << dt_s << "\n";

	return true;
}```

the CMakeLists.txt was updated to reflect the version of 10.5, but an associated tag was not created for it. Could that be done?

The user should have the option to compile libMOOS as a static archive (.a) or shared library (.so).

Currently, the CMakeLists.txt for libMOOS is hard-coded to build a static archive.