I am trying to run the autoecho program that uses boost::asio and boost::fiber. I am using the following:
Ubuntu 16
cmake 3.9.1
boost 1_65_0
That program depends on a local copy of round_robin.hpp, yield.hpp and detail/yield.hpp. I have downloaded all of those and the program builds successfully. When I run the code, I get a segmentation fault at the line in main that does:
io_svc->run();
Does anyone know if I am doing something wrong, or if the code has an error in it?
I received an email from Oliver Kowalke #boost:
unfortunately, some fixes did not permission to merged into 1.65 (no permission because too late) - you could use branch develop (github) or you need to wait till 1.66is released.
So, until boost 1.66 is released, this code will not work unless you want to use the develop branch.
Related
I have an OCaml program that worked fine on Ubuntu 16 but when recompiled and run on Ubuntu 20 I get the following error:-
$ ocamldebug ./linearizer
OCaml Debugger version 4.08.1
(ocd) r
Loading program... done.
Time: 89534
Program end.
Uncaught exception: Sys_error "Illegal seek"
(ocd) b
Time: 89533 - pc: 624888 - module Netaccel_link
No source file for Netaccel_link.
I thought this was due to missing dev libraries but:-
$ sudo apt install libocamlnet-ocaml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libocamlnet-ocaml-dev is already the newest version (4.1.6-1build6).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
What setup step am I missing on Ubuntu 20?
This looks like a regression bug in libocamlnet and you should report an issue there or, I am a bit pessimistic that you will get any response, you can try to debug the issue yourself.
The problem that you are facing has nothing to do with missing libraries (they will be reported during installation or, if the package is broken, end up in linker errors). It may result, however, from some misconfiguration of the system. If that is true, then you're lucky as you can fix it yourself.
I will give you some advice that might help you in debugging this issue. For more, please try using discuss.ocaml.org as a more suitable media (SO doesn't favor this kind of a discussion and we might get deleted by admins).
The illegal seek exception is thrown when the seek operation is applied on a non-regular file, aka ESPIPE Unix error. So check your inputs. It could be that what was previously regarded as a file in Ubuntu is now a pipe or a socket.
Try to use ltrace or strace to pinpoint the culprit e.g.,
ltrace ./linearizer
or, if it overwhelms you, try strace
strace ./linearizer
Instead of using ocamldebug you can use plain gdb. You can use gdb's interfaces to provide the path to the source code (though most likely it won't work since ocamlnet is not compiled with debug information). I believe that it will give you a more meaningful backtrace.
Instead of using the system installation try using opam. Install your dependencies with opam and try older versions as well as newer versions of the OCaml compiler. Also, try different versions of ocamlnet. Ideally, try to reproduce the environment that used to work for you.
When nothing else works, you can use objdump -d and look at the disassembly of your binary. OCaml is using a pretty readable and intuitive name mangling scheme (<module_name>__<function_name>_<uid>), so you can easily find the source code (search for <module_name>.ml file and look for the <function_name> there)
Finally, just use docker or any other container to run your application. Consider switching from ocamlnet to something more modern and supported.
I am currently installing the HDF5 library, more precisely the hdf5-1.10.0-patch1, on Cygwin, as I want to use it with Fortran. Following the instructions from the hdfgroup website
(here is the link), I did the following:
./configure --enable-fortran
make > "out1_check.txt" 2> "warn1_check.txt" &
make check > "out2_check.txt" 2> "warn2_check.txt" &
The execution of the last command (make check) proceeds as it should, until it gets stuck. The process does not stop and something is happening (8-12% CPU are in use by sh.exe, already 39 hours of CPU time) but "out2_check.txt" looks like
Making check in src
...
[many successful checks]
...
============================
No need to test testlinks_env.sh again.
============================
============================
Testing testswmr.sh
Unfortunately, I do not have the output file from the first run of make check, but it did not contain more information on Testing testswmr.sh. There was never any error message.
So, what is this testswmr.sh, why does it get stuck and how can I finalize the installation process? Maybe I can skip the remaining checks and just proceed to make install?
Important note: an older version of HDF5 is already installed from the Cygwin repo. It does not seem to support Fortran however, so I decided to install the current version myself.
Available (and used) compilers are gcc and gfortran.
As far as I can tell, only Intel Fortran is supported on Windows. There is no Cygwin download here https://support.hdfgroup.org/HDF5/release/obtain518.html and I have never come across a report of experience for Cygwin/Fortran/HDF5.
Your options:
Use Intel Fortran
Use Linux or Mac
Sorry
I have built the latest Alljoyn sdk (version 16.04a) on Raspbian and generated the liballjoyn.so and liballjoyn.a without any errors or issues. Scons cmd: scons OS=linux CPU=arm OE_BASE=/usr BINDINGS=cpp BR=on BT=off ICE=off WS=off SERVICES="about" CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-
So in my program, which is a really simple one and just has several lines to create a busattachment.
When I started debugging, it threw a "Segmentation Fault" in a STL class.
I ran Valgrind to see what actually the problem is, and the result is something about "invalid read size of 4".
Any ideas? Did I miss anything during the building process? Or do I need to do anything with my codes?
Thanks a lot!
this is really a silly one... it ends up with I did not initialize Alljoyn correctly: I missed the AllJoynInit() method.
I am Mac OS 10.11 (El Capitan) user. I used 4.6 and when I tried to build some simulation I always get "Simulation terminated with exit code: 139" and couldn’t do nothing at all with that. I thought that when I install 5.0 then everything will be fine, but now I get something like that:
Simulation terminated with exit code: 132
Working directory: /Users/JL_Data/omnetpp-5.0/samples/tictoc
Command line: tictoc -r 0 --debug-on-errors=false omnetpp.ini
Environment variables:
PATH=/Users/JL_Data/omnetpp-5.0/bin::/usr/bin:/bin:/usr/sbin:/sbin
DYLD_LIBRARY_PATH=/Users/JL_Data/omnetpp-5.0/lib::
OMNETPP_IMAGE_PATH=/Users/JL_Data/omnetpp-5.0/images
And when I tried open some simulation in terminal I get:
Illegal instruction: 4
Do you have some idea what can I do with that problem? I tried to find something on the internet, but after one day I do not get any idea.
If you need some more information, please let me know.
As it is right now, your question is not completely clear, since it requires one to be familiar with omnet++ and probably some experience installing and setting it up. However, let me make a couple guesses.
First, Illegal instruction. This usually occurs when the binary was built for an architecture different than the one it's being run on; e.g. when then SSE2 or AVX instructions are present in the binary code, but are missing on the CPU.
See, for example, this SO question:
Find which assembly instruction caused an Illegal Instruction error without debugging
There is also a question that discusses exactly your problem, namely, "Illegal instruction: 4" on OS X:
What is the "Illegal Instruction: 4" error and why does "-mmacosx-version-min=10.x" fix it?
Now, since omnet++ appears to be an open source project, I expect it to have a mailing list and / or an IRC channel. Indeed, here is the communications page on the official website that links to a Google Groups-based mailing list:
https://omnetpp.org/get-involved
https://groups.google.com/forum/#!forum/omnetpp
I advise you to get in touch with the developers with a thorough description of your problem, since the chances of them knowing the solution are significantly higher compared to the chances of there being a user on SO who has faced similar problems when installing an identical version of omnet++ on an identical version of Mac OS X.
I am getting a segmentation fault in a program that uses the C++ mongodb client driver.
Attempting to isolate the problem I found this: there is some heap object of class X.
When commenting out all the mongo code the program runs fine.
But if I add a member variable of type BSONObjBuilder to X (just declare without using it),
then after about 200K iterations where X objects are allocated and deallocated the fault occurs.
Gdb bt shows it's in the destructor of X, which is actually {}, so it only disposes of the BSONObjBuilder.
It looks like the free memory list is getting corrupted.
Having a BSONObjBuilder as a local variable on the stack works though, over millions of iterations.
I have found this related question https://groups.google.com/forum/#!topic/mongodb-user/Ngxh4IOcSPA
which suggests there is a linkage problem. So I rebuilt the mongo C++ driver as indicated, but the
problem persists. There is also this question on the matter
MongoDB C++ Segmentation Fault
with similar rebuild recommendations but for older mongo versions.
Not being an expert, I would appreciate some help in finding out exactly what library mismatch may cause this and how to reinstall/rebuild/fix it properly.
Some details:
I have ubuntu 14.04.1 LTS
dpkg -S /usr/include/boost/version.hpp shows libboost1.54-dev
mongod 2.6 running, although after commenting out I'm not even connecting to it.
downloaded the legacy mongo C++ driver git clone https://github.com/mongodb/mongo-cxx-driver.git
built scons driver and scons install, which uses g++, compiled fine, generated libmongoclient.a
my code in Eclipse also uses g++, everything compiled with -pthread (there are multiple threads)
a single additional include path to mongo-cxx-driver/build/include for the mongo driver stuff
libraries linked as follows (in order): mongoclient, pthread, boost_thread, boost_system, boost_regex
tried with pthread the last library, no help
calling mongo::client::initialize first thing in main, status returned ok
I have some BSONObj members in X, they work fine until I also add the BSONObjBuilder member
Tried calling done() or abandon() on the BSONObjBuilder in the destructor, also no help.