I made a program that was based off of the demo program on the affdex git page found here. It is the demo called 'opencv-webcam-demo'. I was running Ubuntu 14.04 at the time and it worked fine. I then upgraded to Ubuntu 16.04 and now the demo (even without my changes) does not run properly. I tried to install the latest versions of opencv and boost and confirmed that they were installed correctly but I still get the same issue.
Here is the output when I run the program in Ubuntu 16.04:
ethan#ethan-HP-Pavilion-dv6-Notebook-PC:~/leepsProgram/build/opencv-webcam-demo$ ./opencv-webcam-demo --help
Hit ESCAPE key to exit app..
Encountered an exception std::exception*** Error in `./opencv-webcam-demo': free(): invalid pointer: 0x0000000001c71ca8 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f0ce2798725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f0ce27a0f4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f0ce27a4abc]
./opencv-webcam-demo(_ZN5boost10filesystem4pathD1Ev+0x18)[0x469c86]
/lib/x86_64-linux-gnu/libc.so.6(__cxa_finalize+0x9a)[0x7f0ce275b35a]
/home/ethan/libraries/affdex-sdk/lib/libaffdex-native.so(+0x5273a3)[0x7f0ce642a3a3]
There was also a Memory Map so if that helps then let me know and I can paste that in here too.
So far I have tried to figure out what part of the code works and what part does not work and found that if you remove boost from the program it will reach up until the point were Affdex has to specify a path to the data folder, at which point it throws an Affdex Exception saying that the data path must be non-null. However it should not be null because I set it at the start.
affdex::path DATA_FOLDER = "<path to data folder>";
...
frameDetector->setClassifierPath(DATA_FOLDER);
Still, removing boost is not ideal since it is already coded for me. But if I have to remove boost then I must solve this issue as well.
Libraries and their versions / OS version:
Boost 1.59.0
OpenCV 3.1.0
Affdex 3.1-396
Ubuntu 16.04
Are these libraries compatible with Ubuntu 16.04?
Thanks for any help. It is greatly appreciated.
I think the problem is that you are mixing libraries with compiled with incompatible versions of libstdc++ .. What is the compiler version you are using?
The current version of the linux SDK was compiled with GCC 4.8
UPDATED: I have solved this problem by updating SDK version to the newest version (https://download.affectiva.com/linux/gcc-5.4/affdex-cpp-sdk-4.0-75-ubuntu-xenial-xerus-x86_64bit.tar.gz).
The tutorial provided the old version:
wget https://download.affectiva.com/linux/affdex-cpp-sdk-3.2-20-ubuntu-xenial-xerus-64bit.tar.gz
I have similar problem, with similar error log. Please consider to upgrade or find a better way to the C++ samples version. Many people try to use the same C++ code for testing. I wasted a lot of time to figure out why?
Debugging starts
Hit ESCAPE key to exit app..
Initializing Affdex FrameDetector
*** Error in `/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo': munmap_chunk(): invalid pointer: 0x0000000000856e10 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff582c7e5]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x1a8)[0x7ffff5839698]
/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo(_ZN5boost10filesystem4pathD1Ev+0x18)[0x467948]
/home/aiq/Desktop/aiq_workspace/affdex-sdk/lib/libaffdex-native.so(_ZN6affdex12DetectorBase17setClassifierPathERKSs+0xc6)[0x7ffff6f5061a]
/home/aiq/Desktop/aiq_workspace/affdex-sdk/lib/libaffdex-native.so(_ZN6affdex8Detector17setClassifierPathERKSs+0x2f)[0x7ffff6f4abb1]
/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo(main+0xaed)[0x466110]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff57d5830]
/home/aiq/Desktop/aiq_workspace/cpp-sdk-samples/build/opencv-webcam-demo/opencv-webcam-demo(_start+0x29)[0x465209]
Please look into the issue. Comments not taking long answer, so I post as an answer here.
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 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.
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 am trying to run the Woden Physics Example inside Pharo which involves getting Bullet properly compiled and the smalltalk bindings properly installed in Pharo.
I am using Linux Mint 17 x64.
But NativeBoost seems unable to load the compiled libraries. I have been using the sources provided here:
https://github.com/ronsaldo/bullet-pharo
https://github.com/ronsaldo/swig
I built the modified version of swig as well as the bullet libraries and bindings with the provided build scripts.
I also have doublechecked that the bullet libraries are 32 bit.
Opening up the Woden physics example returns this error:
failed to get a symbol address:
PharoNB_new_BTDefaultCollisionConfiguration__SWIG_1
When examining the call stack in the debugger, it turns out that the module handle is 0.
I verified this by executing the same message as
BulletCInterface nbLibraryNameOrHandle
executes:
NativeBoost forCurrentPlatform loadModule: 'BulletPharo'
This message returns 0. I tried to specify the full path to libPharoBullet.so in the workspace, like:
NativeBoost forCurrentPlatform loadModule:
'/home/martin/.local/share/Pharo/bullet-pharo/libBulletPharo.so'
with the same result. I also verified it with a 32 bit system library of mine (liblzma) and there NativeBoost was able to load it, as it returned a non-zero handle.
So i suspect something during compilation went wrong...
I also did
readelf -h libPharoBullet.so
and its ABI was "UNIX - GNU" while the ABI of pharo-vm is "UNIX - System V"
Could this be the problem here ?
How can i force the ABI to be System V when compiling ? I use gcc 4.8.2
Or what steps could i otherwise perform ?
I have successfully installed QuabtLib for my windows box, and wanted to port it to Linux Ubuntu. The Boost install was successful, and I was able to run ./configure from the swig directory. However when I run the make file, the system freezes at the following point:
QuantLib/quantlib_wrap.cpp: In function ‘void* _p_TestSurfacePtrTo_p_boost__shared_ptrT_Surface_t(void*, int*)’:
QuantLib/quantlib_wrap.cpp:253496:41: warning: ‘Surface’ is deprecated (declared at /usr/include/ql/math/surface.hpp:47) [-Wdeprecated-declarations]
return (void *)((boost::shared_ptr< Surface > *) ((TestSurfacePtr *) x));
Would be great if someone knew the fix.
Environment info: Boost 1.56
QuantLib 1.4
QuantLibSwig 1.4
Python2.7.6
Ubuntu 14
Thanks,
Here's my comment above, posted as an answer for future reference.
The warning is expected. The Surface class was marked as deprecated in QuantLib 1.4, we're wrapping it anyway, and the compiler is warning us about that.
The freeze is probably caused (was definitely caused, in the case of the original poster) by the exhaustion of the available memory. The wrappers are huge, weighing at about 10 MBytes, and compiling them requires quite a few resources. If you're using a virtual machine, try adding more memory. If you're using a physical machine and you can't, try disabling optimizations to make the compilation process less demanding. You can do this by passing CXXFLAGS=-O0 to either ./configure or make.