gobysoft / goby3 Goto Github PK
View Code? Open in Web Editor NEWThe Goby Underwater Autonomy Project Version 3
License: Other
goby3's People
Contributors
Stargazers
Watchers
Forkers
seatrix shawndooley mission-systems-pty-ltd henrikschmidt aaraste lilymuir jturner314-nrl edsanville bzoss tsaubergine jmount-bossgoby3's Issues
Compile error with canonicalize_file_name
When compiling with GCC 8.3.0 I am getting this error in the goby_moos module:
[ 70%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/goby_moos_app.cpp.o
In file included from /apk_src/goby/src/goby3-3.0/src/apps/middleware/gobyd/gobyd.cpp:22:
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h: In constructor 'goby::common::ApplicationBase3<Config>::ApplicationBase3()':
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h:180:30: error: there are no arguments to 'canonicalize_file_name' that depend on a template parameter, so a declaration of 'canonicalize_file_name' must be available [-fpermissive]
int result = symlink(canonicalize_file_name(file_name.c_str()), file_symlink.c_str());
^~~~~~~~~~~~~~~~~~~~~~
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h:180:30: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h: In instantiation of 'goby::common::ApplicationBase3<Config>::ApplicationBase3() [with Config = goby::protobuf::GobyDaemonConfig]':
/apk_src/goby/src/goby3-3.0/src/apps/middleware/gobyd/gobyd.cpp:69:63: required from here
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h:180:52: error: 'canonicalize_file_name' was not declared in this scope
int result = symlink(canonicalize_file_name(file_name.c_str()), file_symlink.c_str());
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
[ 70%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/modem_id_convert.cpp.o
[ 71%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/moos_translator.cpp.o
make[2]: *** [src/apps/middleware/gobyd/CMakeFiles/gobyd.dir/build.make:63: src/apps/middleware/gobyd/CMakeFiles/gobyd.dir/gobyd.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:979: src/apps/middleware/gobyd/CMakeFiles/gobyd.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 71%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/moos_protobuf_helpers.cpp.o
[ 71%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/moos_ufield_sim_driver.cpp.o
[ 72%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/moos_bluefin_driver.cpp.o
[ 72%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/transitional/message_val.cpp.o
[ 73%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/transitional/message_algorithms.cpp.o
[ 73%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/moos_geodesy.cpp.o
[ 74%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/frontseat/frontseat.cpp.o
[ 74%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/middleware/moos_plugin_translator.cpp.o
In file included from /apk_src/goby/src/goby3-3.0/build/include/goby/middleware/multi-thread-application.h:28,
from /apk_src/goby/src/goby3-3.0/src/moos/middleware/moos_plugin_translator.h:27,
from /apk_src/goby/src/goby3-3.0/src/moos/middleware/moos_plugin_translator.cpp:23:
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h: In constructor 'goby::common::ApplicationBase3<Config>::ApplicationBase3()':
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h:180:30: error: there are no arguments to 'canonicalize_file_name' that depend on a template parameter, so a declaration of 'canonicalize_file_name' must be available [-fpermissive]
int result = symlink(canonicalize_file_name(file_name.c_str()), file_symlink.c_str());
^~~~~~~~~~~~~~~~~~~~~~
/apk_src/goby/src/goby3-3.0/build/include/goby/common/application_base3.h:180:30: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
[ 75%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/__/__/include/goby/moos/protobuf/bluefin_driver.pb.cc.o
[ 75%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/__/__/include/goby/moos/protobuf/ctd_sample.pb.cc.o
[ 76%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/__/__/include/goby/moos/protobuf/desired_course.pb.cc.o
[ 76%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/__/__/include/goby/moos/protobuf/frontseat.pb.cc.o
[ 77%] Building CXX object src/moos/CMakeFiles/goby_moos.dir/__/__/include/goby/moos/protobuf/frontseat_config.pb.cc.o
make[2]: *** [src/moos/CMakeFiles/goby_moos.dir/build.make:297: src/moos/CMakeFiles/goby_moos.dir/middleware/moos_plugin_translator.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:500: src/moos/CMakeFiles/goby_moos.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
>>> ERROR: goby: build failed
Race condition in goby_test_middleware5
AddressSanitizer: heap-use-after-free in goby_test_middleware3
Please see the attached log file. There is a memory management issue, possibly related to the goby::InterProcessPortal, that leads to an object being used after it has been freed.
-n flag for goby applications overrides -vvv settings
-n should respect -vv verbosity settings.
single_thread_app1 test case is timing-sensitive
The single_thread_app1 test case fails when built with ThreadSanitizer, because it gets slowed down by the extra instrumentation.
For now I'll disable the test when building with TSAN.
Time warp problems with AMAC
Goby MAC doesn't work correctly with time warp values > 1.
Add configure stage to application lifecycle
Currently, the config reference returned by app_cfg() is mutable. This has some downsides:
- There is no built-in locking or signaling around modifying the config object, which would be highly error-prone in a multithreaded app.
- We want to publish an app's configuration on startup, but we would also have to re-publish on every modification.
- The getter cannot be marked
const, which means you cannot call it from otherconstmethods.
I propose extending the lifecycle of the app to have a startup configure stage, which executes before the main runloop. The method for this stage would accept a mutable config object which it can populate. Afterwards, only an immutable reference can be accessed through the app_cfg() getter.
The configuration can be automatically published as soon as configure() returns.
The inherited default implementation of this method would parse command line arguments and populate the object's fields. The subclass can optionally call the superclass implementation if this default behavior is desired, and then make additional changes to the config object.
Goby3 multithreaded applications do not always quit when one of the threads throws and uncaught exception
Make sure the application always quits if a thread throws an uncaught exception.
Need wildcard subscription option of some sort for interprocess at least.
Cannot build moos app pAcommsHandler if dccl not built with b64
Can cmake be made to error and/or not build pTranslator target if DCCL was not built with b64 support?
[ 87%] Building CXX object src/apps/moos/pAcommsHandler/CMakeFiles/pAcommsHandler.dir/pAcommsHandler.cpp.o
/apk_src/goby/src/goby3-3.0/src/apps/moos/pAcommsHandler/pAcommsHandler.cpp: In member function 'void CpAcommsHandler::handle_config_file_request(const CMOOSMsg&)':
/apk_src/goby/src/goby3-3.0/src/apps/moos/pAcommsHandler/pAcommsHandler.cpp:305:19: error: 'b64_encode' is not a member of 'dccl'
dccl::b64_encode(cfg_.SerializeAsString()));
^~~~~~~~~~
/apk_src/goby/src/goby3-3.0/src/apps/moos/pAcommsHandler/pAcommsHandler.cpp:305:19: note: suggested alternative: 'hex_encode'
dccl::b64_encode(cfg_.SerializeAsString()));
^~~~~~~~~~
hex_encode
Use new Proj API
SimpleThreads should set the thread name
A basic MultiThreadApplication seems to have 6+ threads running even in a simple application. When I look at info threads in GDB, I can't tell them apart.
I don't care so much about Goby's internal threads, but any threads I start up using launch_thread(), I'd like to be able see the class name associated with it.
Need to load DCCL message with publication
If gobyd doesn't have the DCCL message loaded, it needs to be able to load it. We can do this with the first publication or upon request on subsequent publications.
Can we remove the io_service from the UDPDriver, etc. constructors and just create it in the class?
`gobyd --help` is truncated, doesn't emit an ANSI reset sequence
I'm on commit abca7af7e7e7177a12b1c4a73053b9e8ddca64cb.
After I run gobyd --help, my prompt stays green, indicating an ANSI escape sequence to reset colors isn't output. What it looks like is actually the whole thing is being truncated:
...
mac_cfg { Configure the acoustic Medium
Access Control (optional)
modem_id: 1 Unique number 1-31 to
identify this node (optional)
type: MAC_NONE The type of TDMA MAC
scheme to use (MAC_NONE, MAC_FIXED_DECENTRALIZED,
MAC_POLLED) (optional) (default=MAC_NONE)
slot { Configure a slot in the
communications cycle. Slots are run in the order
they are declared. (repeated)
src: -1 modem ID of message source. 0
indicates BROADCAST. (optional) (default=-1)
dest: -1 modem ID of message
destination. 0 indicates BROADCAST, -1 indicates
QUERY_DESTINATION_ID (i.e., destination is set to
the destination of the next available packet
(optional) (default=-1)
rate: 0 0 (lowest) - 14 (highest), -1
(QUERY_RATE). QUERY_RATE is currently unsupported
by Goby-Queue (optional) (default=0)
type: UNKNOWN Type of this
transmission. DRIVER_SPECIFIC types are
enumerated in the extensions for the selected
driver. (UNKNOWN, DATA, ACK, DRIVER_SPECIFIC)
(optional) (default=UNKNOWN)
max_num_frames: 1 (optional)
(default=1)
max_frame_bytes: (optional)
ack_requested: true (optional)
(default=true)
frame: "" Data to transmit, represented
as ASCII or octal bytes preceeded by a '' (e.g.
Given on command line only:
The mac_cfg message/arguments aren't completed.
Cleanly close MultiThreadApplication threads
Currently, the threads will not join if loop_frequency_hertz() < 0 (no loop()) and no data is being published to that thread to get it to exit PollerInterface::poll().
We need a clear synchronized way to ensure that we can join the threads upon quit().
There should be a way to send a message from the command line
See #53 for one use case.
It should be possible to publish a message from the command line. This could be the API used by shell scripts, web GUIs, etc. for interacting with a Goby3-based system.
I envision a tool that reads from standard input and is invoked something like:
goby_publish --socket goby.sock --domain interprocess --group asdf --scheme foobar
It would be up to the sender of the message to pack it in the appropriate format corresponding to the scheme.
cmake fails if MOOS not found
While trying to build #75 I came across this issue which is a result of a recent commit.
I am not familiar with cmake enough to offer a patch.
>> Could not find MOOS v10, trying to find MOOS pre-v10.
>> setting build_moos to OFF ... if you need this functionality: 1) install MOOS and libproj-dev; 2) run cmake -Dbuild_moos=ON
-- Configuring done
CMake Error: INSTALL(EXPORT) given unknown export "goby_moos-config"
-- Generating done
goby_launch should have a way to tag commands that need to be cleaned up
From a discussion elsewhere:
Is it just going to like killall socat? Maybe it would be better for the launch script to be able to tag a command, like one of:
[kill=SIGTERM] socat --whatever
[not-goby] socat --whatever
Then the launch tool can know that it needs to grab the PID of the launched subprocess and kill it later.
CDash integration with Github
Goby3 already has a number of unit tests - it would be great to have these run using CDash for each pull request: https://blog.kitware.com/cdash-integration-with-github/
Prefer PROTOBUF to DCCL on interprocess
Can we default to PROTOBUF marshalling when publishing DCCL messages on interprocess?
Build Failure in 18.04ubuntu
Use of date in log filename should not be required
file_name string must contain "%1%" which is expanded to the current application start time (e.g. 20190201T184925)
I don't think this should be enforced. I envision needing to write tests that spawn a set of Goby applications and then grep the debug log for specific warnings, etc.
Normally I would generate a temporary filename and specify that as the log file path. But since you enforce that the filename is dynamic, I would have to then apply a glob pattern to find the generated log file---easy in a shell script, less easy in Python, and tedious in C++.
It just seems like this is something Goby doesn't need to have an opinion of. If I give it the same name as an existing file, and you don't want to append, then that's fine, just die with an error, perhaps giving the hint to include %1% to prevent collisions. People will figure it out.
Logger and Scope tools
All basic middlewares have some form of logging and scoping utilities. These need to be written.
failed compile on boost 1.67 - posix_time and time_durations, native_handle
Issue when compiling with:
$ apk info boost-dev
boost-dev-1.67.0-r2 description:
Free peer-reviewed portable C++ source libraries (development files)
[ 64%] Building CXX object src/acomms/CMakeFiles/goby_acomms.dir/queue/queue_manager.cpp.o
/apk_src/goby/src/goby3-3.0.0_alpha17/src/acomms/queue/queue_manager.cpp: In member function 'goby::acomms::Queue* goby::acomms::QueueManager::find_next_sender(const goby::acomms::protobuf::ModemTransmission&, const string&, bool)':
/apk_src/goby/src/goby3-3.0.0_alpha17/src/acomms/queue/queue_manager.cpp:547:88: error: no matching function for call to 'boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>::subsecond_duration(double)'
cfg_.on_demand_skew_seconds() * 1e6) <
^
In file included from /usr/include/boost/date_time/posix_time/posix_time_config.hpp:16,
from /usr/include/boost/date_time/posix_time/posix_time_system.hpp:13,
from /usr/include/boost/date_time/posix_time/ptime.hpp:12,
from /usr/include/boost/date_time/posix_time/posix_time_types.hpp:12,
from /usr/include/boost/thread/thread_time.hpp:11,
from /usr/include/boost/thread/lock_types.hpp:18,
from /usr/include/boost/thread/pthread/thread_data.hpp:12,
from /usr/include/boost/thread/thread_only.hpp:17,
from /usr/include/boost/thread/thread.hpp:12,
from /usr/include/boost/thread.hpp:13,
from /apk_src/goby/src/goby3-3.0.0_alpha17/build/include/goby/common/logger/flex_ostreambuf.h:33,
from /apk_src/goby/src/goby3-3.0.0_alpha17/build/include/goby/common/logger/flex_ostream.h:35,
from /apk_src/goby/src/goby3-3.0.0_alpha17/build/include/goby/common/logger.h:28,
from /apk_src/goby/src/goby3-3.0.0_alpha17/src/acomms/queue/queue_manager.cpp:25:
/usr/include/boost/date_time/time_duration.hpp:285:14: note: candidate: 'template<class T> boost::date_time::subsecond_duration<base_duration, frac_of_second>::subsecond_duration(const T&, typename boost::enable_if<boost::is_integral<T>, void>::type*)'
explicit subsecond_duration(T const& ss,
^~~~~~~~~~~~~~~~~~
/usr/include/boost/date_time/time_duration.hpp:285:14: note: template argument deduction/substitution failed:
/usr/include/boost/date_time/time_duration.hpp: In substitution of 'template<class T> boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>::subsecond_duration(const T&, typename boost::enable_if<boost::is_integral<T>, void>::type*) [with T = double]':
/apk_src/goby/src/goby3-3.0.0_alpha17/src/acomms/queue/queue_manager.cpp:547:88: required from here
/usr/include/boost/date_time/time_duration.hpp:285:14: error: no type named 'type' in 'struct boost::enable_if<boost::is_integral<double>, void>'
In file included from /usr/include/boost/date_time/posix_time/posix_time_config.hpp:16,
from /usr/include/boost/date_time/posix_time/posix_time_system.hpp:13,
from /usr/include/boost/date_time/posix_time/ptime.hpp:12,
from /usr/include/boost/date_time/posix_time/posix_time_types.hpp:12,
from /usr/include/boost/thread/thread_time.hpp:11,
from /usr/include/boost/thread/lock_types.hpp:18,
from /usr/include/boost/thread/pthread/thread_data.hpp:12,
from /usr/include/boost/thread/thread_only.hpp:17,
from /usr/include/boost/thread/thread.hpp:12,
from /usr/include/boost/thread.hpp:13,
from /apk_src/goby/src/goby3-3.0.0_alpha17/build/include/goby/common/logger/flex_ostreambuf.h:33,
from /apk_src/goby/src/goby3-3.0.0_alpha17/build/include/goby/common/logger/flex_ostream.h:35,
from /apk_src/goby/src/goby3-3.0.0_alpha17/build/include/goby/common/logger.h:28,
from /apk_src/goby/src/goby3-3.0.0_alpha17/src/acomms/queue/queue_manager.cpp:25:
/usr/include/boost/date_time/time_duration.hpp:270:30: note: candidate: 'boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>::subsecond_duration(const boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>&)'
class BOOST_SYMBOL_VISIBLE subsecond_duration : public base_duration
^~~~~~~~~~~~~~~~~~
/usr/include/boost/date_time/time_duration.hpp:270:30: note: no known conversion for argument 1 from 'double' to 'const boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>&'
/usr/include/boost/date_time/time_duration.hpp:270:30: note: candidate: 'boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>::subsecond_duration(boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>&&)'
/usr/include/boost/date_time/time_duration.hpp:270:30: note: no known conversion for argument 1 from 'double' to 'boost::date_time::subsecond_duration<boost::posix_time::time_duration, 1000000>&&'
make[2]: *** [src/acomms/CMakeFiles/goby_acomms.dir/build.make:277: src/acomms/CMakeFiles/goby_acomms.dir/queue/queue_manager.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:377: src/acomms/CMakeFiles/goby_acomms.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
>>> ERROR: goby: build failed
It seems boost no longer permits floating point numbers to initialise posix_time objects. If we cast these to long will there be much precision loss?
Also goby::acomms::MACManager::next_cycle_time() function seems to have numerous conversions to microseconds through out the function, some using double and some using int64. Perhaps this could be refactored?
Related issue I could find: PointCloudLibrary/pcl#2422
Variety of aesthetic and consistency fixes
- Name (using enumerations) driver_tester tests (not numbers)
- Consistently use exceptions (subclass goby::Exception), and change bad_nmea_sentence to use case convention (BadNMEASentence).
Extend publish API for sending a message without a payload
This works:
interthread().publish<groups::nav>(std::shared_ptr<void>(nullptr));
But it would be more elegant like this:
interthread().publish<groups::nav>();
The use case is where you just want to signal to another thread that it should kick off some task, but there's no specific payload content you need to include.
Need unsubscribe methods to match subscribe methods.
Clean up $launchfile after exiting goby_launch
goby_launch leaves my /tmp directory littered with a lot of copies of previous invocations.
refactor MacManager time management to use time3.h header
See discussion in #72
Also
goby::acomms::MACManager::next_cycle_time()function seems to have numerous conversions to microseconds through out the function, some using double and some using int64. Perhaps this could be refactored?
Unify Protobuf CMake modules across projects
cgsn-mooring's FindProtobufLocal.cmake varies slightly from Goby3's FindProtobufGoby.cmake, though they both define the same functions.
One consequence of this is that if you add Goby3 sources to a build with add_subdirectory(), the re-defined functions will replace the parent project's definitions.
CMake has an official built-in FindProtobuf module as well that has been significantly overhauled. It supports the PROTOC_OUT_DIR option now which might do some of what you want.
goby_logger pegs CPU and eats memory until killed when being shut down
When systemd on Ubuntu 18.04 arm64 tries to shut down goby_logger, it pegs the CPU and goes to max memory utilization until it is killed by the out-of-memory manager.
Segfault with MM driver using TCP
Running beta 4. This occurs when the TCP server is not running/cannot be reached.
When running in GDB:
-------------- moos connect ----------------------
contacting a MOOS server localhost:9100 - try 00001
Handshaking as pAcommsHandler [ok]
DB reports async support is [on]
DB is running on b93dad73c2dd
Timing skew estimation is [off] (not needed)
--------------------------------------------------
pAcommsHandler, connected to server.
pAcommsHandler, starting ...
pAcommsHandler [2468-Apr-11 20:37:54.700300]: subscribed for: ACOMMS_MAC_CYCLE_UPDATE
pAcommsHandler [2468-Apr-11 20:37:54.703430]: subscribed for: ACOMMS_FLUSH_QUEUE
pAcommsHandler [2468-Apr-11 20:37:54.705430]: subscribed for: ACOMMS_CONFIG_REQUEST
pAcommsHandler [2468-Apr-11 20:37:54.707450]: subscribed for: ACOMMS_MAC_INITIATE_TRANSMISSION
pAcommsHandler [2468-Apr-11 20:37:54.709650]: subscribed for: ACOMMS_DRIVER_RESET
pAcommsHandler [2468-Apr-11 20:37:54.711590]: subscribed for: ACOMMS_DRIVER_CONFIG_UPDATE
pAcommsHandler is Running:
|-Baseline AppTick @ 10.0 Hz
|--Comms is Full Duplex and Asynchronous
-Iterate Mode 0 :
|-Regular iterate and message delivery at 10 Hz
|-Time Warp @ 10.0
|-Time Warp delay @ 4.0 ms
pAcommsHandler [2468-Apr-11 20:37:54.815710]: (Warning): ignoring normal mail from ACOMMS_MAC_INITIATE_TRANSMISSION from before we started (dynamics still updated)
pAcommsHandler [2468-Apr-11 20:37:54.819870]: D: Starting up driver: 0x556bfa797e80
pAcommsHandler [2468-Apr-11 20:37:54.822390] {goby::acomms::modemdriver::out::1}: D: Goby Micro-Modem driver starting up.
pAcommsHandler [2468-Apr-11 20:37:54.824170] {goby::acomms::modemdriver::out::1}: D: opening tcp client: acomm-modem-host:8888
[New LWP 314]
pAcommsHandler [2468-Apr-11 20:37:54.831570] {goby::acomms::modemdriver::out::1}: D: logging raw output to file: acomm_raw.log
pAcommsHandler [2468-Apr-11 20:37:54.834890] {goby::acomms::modemdriver::out::1}: D: (Warning): Failed to open log file
pAcommsHandler [2468-Apr-11 20:37:54.866250]: (Warning): Error resolving address: acomm-modem-host:8888: Host not found (authoritative)
pAcommsHandler [2468-Apr-11 20:39:34.904170]: (Warning): Error resolving address: acomm-modem-host:8888: Host not found (authoritative)
pAcommsHandler [2468-Apr-11 20:39:35.365740] {pAcommsHandler}: (Warning): Driver exception: Modem physical connection failed to startup.
pAcommsHandler [2468-Apr-11 20:39:35.374520] {pAcommsHandler}: (Warning): Shutting down driver: 0x556bfa797e80
[LWP 314 exited]
pAcommsHandler [2468-Apr-11 20:41:14.910330] {pAcommsHandler}: (Warning): Attempting to restart driver in 60 seconds.
pAcommsHandler [2468-Apr-11 20:41:14.917310] {pAcommsHandler}: Initiating transmission: [[ModemTransmission]] src: 9
pAcommsHandler [2468-Apr-11 20:41:14.920650] {pAcommsHandler}: dest: 0
pAcommsHandler [2468-Apr-11 20:41:14.923230] {pAcommsHandler}: rate: 0
pAcommsHandler [2468-Apr-11 20:41:14.927310] {pAcommsHandler}: type: DATA
pAcommsHandler [2468-Apr-11 20:41:14.929890] {pAcommsHandler}: ack_requested: false
pAcommsHandler [2468-Apr-11 20:41:14.932670] {pAcommsHandler}: frame: "\020\003\\\006`Y\025\013BP\024\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\000"
pAcommsHandler [2468-Apr-11 20:41:14.935380] {pAcommsHandler}:
pAcommsHandler [2468-Apr-11 20:41:14.938020] {goby::acomms::modemdriver::out::1}: D: Beginning to initiate transmission.
pAcommsHandler [2468-Apr-11 20:41:14.941280] {goby::acomms::modemdriver::out::1}: D: this is a DATA transmission
pAcommsHandler [2468-Apr-11 20:41:14.944840] {goby::acomms::queue::priority::1}: D2: Finding next sender: [[ModemTransmission]] src: 9
pAcommsHandler [2468-Apr-11 20:41:14.946880] {goby::acomms::queue::priority::1}: dest: 0
pAcommsHandler [2468-Apr-11 20:41:14.949010] {goby::acomms::queue::priority::1}: rate: 0
pAcommsHandler [2468-Apr-11 20:41:14.951220] {goby::acomms::queue::priority::1}: type: DATA
pAcommsHandler [2468-Apr-11 20:41:14.953520] {goby::acomms::queue::priority::1}: max_num_frames: 1
pAcommsHandler [2468-Apr-11 20:41:14.955730] {goby::acomms::queue::priority::1}: max_frame_bytes: 32
pAcommsHandler [2468-Apr-11 20:41:14.958280] {goby::acomms::queue::priority::1}: ack_requested: false
pAcommsHandler [2468-Apr-11 20:41:14.961000] {goby::acomms::queue::priority::1}: frame: "\020\003\\\006`Y\025\013BP\024\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\000"
pAcommsHandler [2468-Apr-11 20:41:14.963480] {goby::acomms::queue::priority::1}: D: Starting priority contest
pAcommsHandler [2468-Apr-11 20:41:14.965800] {goby::acomms::queue::priority::1}: Requesting 1 frame(s), have 32/32B
pAcommsHandler [2468-Apr-11 20:41:14.968070] {goby::acomms::queue::priority::1}: D: all other queues have no messages
pAcommsHandler [2468-Apr-11 20:41:14.970360] {goby::acomms::queue::priority::1}: D: ending priority contest
pAcommsHandler [2468-Apr-11 20:41:14.972590] {goby::acomms::queue::out::1}: D: No data found. sending empty message to modem driver.
pAcommsHandler [2468-Apr-11 20:41:14.978040] {goby::acomms::modemdriver::out::1}: D: $CCCYC,0,9,0,0,0,1*51
pAcommsHandler [2468-Apr-11 20:41:14.981710] {goby::acomms::modemdriver::out::1}: ^ Network Cycle Initialization Command
Thread 1 "pAcommsHandler" received signal SIGSEGV, Segmentation fault.
goby::acomms::ModemDriverBase::modem_write (this=this@entry=0x556bfa797e80, out=...) at include/goby/util/linebasedcomms/interface.h:56
Also, any idea on the bizarre time stamp dates? That was the next issue I was going to look at.
Scanning for log entry magic is incorrect
while(magic_read != magic_)
{
while(s->peek() != magic_[0])
{
++discarded;
s->get();
}
s->read(&magic_read[0], magic_.size());
}
The stream GGBY3 I think will be parsed incorrectly:
- Peek
G, break out of the inner loop - Read
GGBY, do not break out of the outer loop - Peek
3, do not break out of the inner loop - Raise EOF exception
Ensure that log reader skips corruption even if the size is corrupted
If a LogEntry fails CRC, we need to unwind the stream to just after the start of that message.
Race condition in goby_test_middleware6
It looks like router_context.reset() at line 240 deletes a ZMQ context that is still in use by the thread created by t10.reset(new std::thread([&] { router.run(); })). Note that t10 is joined after the context is destroyed. Imagine t10 were not scheduled until after reset() were called.
The correct order would be to join all the threads and then destroy the contexts, I believe.
25/46 Test #25: goby_test_middleware6 ......................***Failed 6.89 sec
Running test type (0 = interthread, 1 = interprocess): 1
Subscribed.
Start: 1550250786.564
Receive start: 1550250786.56523
Publish end: 1550250787.3197
End: 1550250790.80233
subscriber: all tests passed
==================
WARNING: ThreadSanitizer: data race (pid=5595)
Write of size 8 at 0x7b04000002d0 by main thread:
#0 operator delete(void*) ??:? (goby_test_middleware6+0x57b064)
#1 std::default_delete<zmq::context_t>::operator()(zmq::context_t*) const /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/unique_ptr.h:78 (goby_test_middleware6+0x606c2f)
#2 std::unique_ptr<zmq::context_t, std::default_delete<zmq::context_t> >::reset(zmq::context_t*) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/unique_ptr.h:376 (goby_test_middleware6+0x5845c4)
#3 main /root/cgsn-mooring/goby3/src/test/middleware/middleware6/test.cpp:240 (goby_test_middleware6+0x57ef5a)
Previous read of size 8 at 0x7b04000002d0 by thread T1:
[failed to restore the stack]
As if synchronized via sleep:
#0 sleep ??:? (goby_test_middleware6+0x501957)
#1 main /root/cgsn-mooring/goby3/src/test/middleware/middleware6/test.cpp:225 (goby_test_middleware6+0x57edaf)
Thread T1 (tid=5601, finished) created by main thread at:
#0 pthread_create ??:? (goby_test_middleware6+0x4e9376)
#1 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) ??:? (libstdc++.so.6+0xbd834)
#2 main /root/cgsn-mooring/goby3/src/test/middleware/middleware6/test.cpp:222 (goby_test_middleware6+0x57ecf0)
SUMMARY: ThreadSanitizer: data race ??:? in operator delete(void*)
==================
CMake cannot find MOOS if installed into system
I have created Alpine packages for MOOS-IVP. When these are installed into the system (/usr/lib and /usr/include) there is, of course, no source tree any more. Does Goby really need the source tree in order to compile, or is access to the includes and libs enough?
>> Could not find MOOS v10, trying to find MOOS pre-v10.
>> setting build_moos to OFF ... if you need this functionality: 1) install MOOS and libproj-dev; 2) run cmake -Dbuild_moos=ON
Proposal: Goby applications should block until the system is ready
LeakSanitizer reports leaks in several tests
I imagine that these have a common origin. Is it just the omission of a call to dccl::DynamicProtobufManager::protobuf_shutdown()?
e.g.,
goby_test_queue6.log
build/test-out//goby_test_queue4.log:==4835==ERROR: LeakSanitizer: detected memory leaks
build/test-out//goby_test_queue5.log:==4839==ERROR: LeakSanitizer: detected memory leaks
build/test-out//goby_test_queue6.log:==4843==ERROR: LeakSanitizer: detected memory leaks
build/test-out//goby_test_queue2.log:==4827==ERROR: LeakSanitizer: detected memory leaks
build/test-out//goby_test_queue3.log:==4831==ERROR: LeakSanitizer: detected memory leaks
build/test-out//goby_test_queue1.log:==4823==ERROR: LeakSanitizer: detected memory leaks
build/test-out//goby_test_middleware5.log:==4998==ERROR: LeakSanitizer: detected memory leaks
Escape '/' in group and type names for zeromq interprocess.
Can't transmit data with Micromodem 2.0.27087 - doesn't wait for CCCFQ,TOP to finish
Currently I have a application that connects to a deckbox via USB, configures the driver, configures the modem and then transmits some data. This works fine with a MM 1 but when I use a MM 2 it doesn't work any more. The number of CFG variables returned is much larger than MM1 and it tries to initiate data transfer before the CFG spam is complete. Perhaps it can wait until its finished before it pops the CFQ command from the queue? Also can query_all_cfg be made a configurable option?
Also, I receive a CAREV midway through the CFG barrage.
deprecated zmq send/recv calls
Seems as of ZMQ 4.3.1 some of these calls have become deprecated.
[140/228] Building CXX object src/zeromq/CMakeFiles/goby_zeromq.dir/transport/interprocess.cpp.o
../src/zeromq/transport/interprocess.cpp: In member function 'bool goby::zeromq::InterProcessPortalMainThread::recv(goby::zeromq::protobuf::InprocControl*, int)':
../src/zeromq/transport/interprocess.cpp:74:45: warning: 'bool zmq::detail::socket_base::recv(zmq::message_t*, int)' is deprecated: from 4.3.1, use recv taking a reference to message_t and recv_flags [-Wdeprecated-declarations]
if (control_socket_.recv(&zmq_msg, flags))
^
In file included from ../src/zeromq/transport/interprocess.h:27,
from ../src/zeromq/transport/interprocess.cpp:25:
/usr/include/zmq.hpp:1267:10: note: declared here
bool recv(message_t *msg_, int flags_ = 0)
^~~~
../src/zeromq/transport/interprocess.cpp: In member function 'void goby::zeromq::InterProcessPortalMainThread::publish(const string&, const char*, int)':
../src/zeromq/transport/interprocess.cpp:107:33: warning: 'bool zmq::detail::socket_base::send(zmq::message_t&, int)' is deprecated: from 4.3.1, use send taking message_t and send_flags [-Wdeprecated-declarations]
publish_socket_.send(msg);
^
In file included from ../src/zeromq/transport/interprocess.h:27,
from ../src/zeromq/transport/interprocess.cpp:25:
/usr/include/zmq.hpp:1191:10: note: declared here
bool send(message_t &msg_,
^~~~
Build failure since Alpha14 release
The command git rev-list --count 3.0.0_alpha14..HEAD fails early on in the topmost CMakeLists.txt. Did you forget to push a tag or something?
Does not build after installing dependencies, missing witty
In the cgsn-mooring Docker container:
# ./DEPENDENCIES ubuntu
...
# ./build.sh
...
[ 97%] Building CXX object src/apps/middleware/liaison/CMakeFiles/goby_liaison.dir/liaison.cpp.o
.../src/apps/middleware/liaison/liaison.cpp:25:10: fatal error: Wt/WText: No such file or directory
#include <Wt/WText>
^~~~~~~~~~
I installed the witty-dev package which seemed to resolve it.
boost 1.70 has removed get_io_service
[80/228] Building CXX object src/CMakeFiles/goby.dir/acomms/modemdriver/driver_base.cpp.o
FAILED: src/CMakeFiles/goby.dir/acomms/modemdriver/driver_base.cpp.o
/usr/bin/c++ -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DHAS_GMP -DSHARED_LIBRARY_SUFFIX=\".so\" -Dgoby_EXPORTS -Iinclude -Iinclude/goby/protobuf -Iinclude/goby/acomms/protobuf -Iinclude/goby/util/protobuf -Iinclude/goby/middleware/protobuf -I/usr/lib/cmake/MOOS/../../../include -Os -fomit-frame-pointer -O3 -DNDEBUG -fPIC -Wno-misleading-indentation -std=gnu++14 -MD -MT src/CMakeFiles/goby.dir/acomms/modemdriver/driver_base.cpp.o -MF src/CMakeFiles/goby.dir/acomms/modemdriver/driver_base.cpp.o.d -o src/CMakeFiles/goby.dir/acomms/modemdriver/driver_base.cpp.o -c ../src/acomms/modemdriver/driver_base.cpp
In file included from include/goby/util/linebasedcomms.h:34,
from ../src/acomms/modemdriver/driver_base.h:32,
from ../src/acomms/modemdriver/driver_base.cpp:28:
include/goby/util/linebasedcomms/tcp_server.h: In member function 'void goby::util::TCPConnection::start()':
include/goby/util/linebasedcomms/tcp_server.h:108:28: error: 'boost::asio::ip::tcp::socket' {aka 'class boost::asio::basic_stream_socket<boost::asio::ip::tcp>'} has no member named 'get_io_service'
108 | void start() { socket_.get_io_service().post(boost::bind(&TCPConnection::read_start, this)); }
| ^~~~~~~~~~~~~~
include/goby/util/linebasedcomms/tcp_server.h: In member function 'void goby::util::TCPConnection::write(const goby::util::protobuf::Datagram&)':
include/goby/util/linebasedcomms/tcp_server.h:112:17: error: 'boost::asio::ip::tcp::socket' {aka 'class boost::asio::basic_stream_socket<boost::asio::ip::tcp>'} has no member named 'get_io_service'
112 | socket_.get_io_service().post(boost::bind(&TCPConnection::socket_write, this, msg));
| ^~~~~~~~~~~~~~
include/goby/util/linebasedcomms/tcp_server.h: In member function 'void goby::util::TCPConnection::close(const boost::system::error_code&)':
include/goby/util/linebasedcomms/tcp_server.h:117:17: error: 'boost::asio::ip::tcp::socket' {aka 'class boost::asio::basic_stream_socket<boost::asio::ip::tcp>'} has no member named 'get_io_service'
117 | socket_.get_io_service().post(boost::bind(&TCPConnection::socket_close, this, error));
| ^~~~~~~~~~~~~~
According to boost asio changelog (https://www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/history.html)
Note: One potential source of breakage in existing user code is when reusing an I/O object's io_context for constructing another I/O object, as in:
asio::steady_timer my_timer(my_socket.get_executor().context());
and
The previously deprecated get_io_context and get_io_service member functions have now been removed.
Goby UDP IO doesn't work without a network connection other than localhost
The resolver fails if the computer has no connection other than loopback, e.g. in
https://github.com/GobySoft/goby3/blob/3.0/src/middleware/io/udp_point_to_point.h
Lots of noise from -Wdocumentation
I don't know where this flag gets set but it makes Clang generate a lot of noise from acomms/amac/mac_manager.h and acomms/queue/queue_manager.h which are included all over the place and make it difficult for me to see what warnings/errors are in my own code.
Most of the messages seem to be that it doesn't like when you are trying to use \param to document an argument of a function pointer type, like here:
/// \brief Forwards the data request to the application layer. This advanced feature is used when queue.encode_on_demand == true and allows for the application to provide data immediately before it is actually sent (for highly time sensitive data)
///
/// \param request_msg the details of the requested data. (protobuf::ModemDataRequest is defined in acomms_modem_message.proto)
/// \param data_msg pointer to store the supplied data. The message is of the type for this queue.
boost::signals2::signal<void(const protobuf::ModemTransmission& request_msg,
google::protobuf::Message* data_msg)>
signal_data_on_demand;
Doxygen does show this in the output even if it is not entirely valid.
For boolean command line flags, use presence/absence as indicator of true/false
Currently the Goby command line parser requires the field value for all protobufs. We should change booleans to be a special case, e.g.
Currently:
--is_foo true
Would be better as (for true)
--is_foo
and for false, omitting the parameter
Unsubscribe all subscriptions upon destruction of thread
At what level should this be handled?
poll() with no timeout ignores InnerTransporter::poll()
The current poll() design will never call the InnerTransporter::poll() if the current Transporter doesn't have any events. We need to decouple these events, possibly by switching to a fully file descriptor based event driven system, which we can then epoll();
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.