One more time, I want to ask for your help after long and unfruitful researches.
I have developped an app using OpenCV which works very well is Visual Studio in debug and release mode.
I tried to deploy it, but i get a fatal error when I start the .exe. By using a log file and doing tests, I figured out the problem was in function cv::resize in the following code :
Mat logo = imread("lena.png");
cv::resize(logo, logo, Size(), 0.55, 0.55, INTER_CUBIC);
I found very weird that i can call cv::imread (and cv::Mat) without throwing exception but not resize.
If I try to run the .exe created by the compilation in release mode, i get the following errod code : 0xc000007b.
I read it could be a problem of compatibility between 32/64-bits dll, without being able to solve it. I try to build a 64-bits appplication. The path for opencv lib is define like this : C:\opencv\build\x64\vc14\lib
Thank you for your help,
Valentin B
Upon adding SDL_ttf (2.0.10), DrMemory refuses to work anymore. The console went from printing out the messages to outputting nothing and sending the following to stdout:
~~Dr.M~~ WARNING: unable to locate results file: can't open D:\DrMemory
\drmemory\logs/resfile.6188 (code=2). Dr. Memory failed to start the
target application, perhaps due to interference from invasive security
software. Try disabling other software or running in a virtual machine.
Is there any way around this with some command line flag for Dr Memory or will I have to forego using Dr Memory?
Note: It works perfectly fine with other SDL stuff until I add the TTF Library and add a TTF_Font *font somewhere. The code I have works fine and there is no loading errors or anything wrong with it, it's at a very primitive level and fresh/new. I just cannot get Dr Memory to work as soon as any TTF element is added to the source code.
It works with a 32-bit build, but not a 64-bit build... so I switched to using 32-bits.
Since this is not a full answer as to why. However if anyone finds it breaking for them, try 32-bit.
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 a multi-threaded C++ windows project in Visual Studio 2010 which uses Qt (5.1.1) and OpenCV (2.4.8). When I build it in Debug mode everything runs fine, but when I build it in Release mode the program crashes. Both configurations are almost identical (just in Release I have Multi-threaded DLL /MD and in Debug Multi-threaded Debug DLL /MDd), I disabled optimizations for the Release, and even enabled debug to catch the error. What's most weird is that the same piece of code that crashes, runs just fine in another console project.
The error is internal to OpenCV's code, it's not related to my code, my code is just:
void MyProject::findEllipses(QImage &frame, vector<RotatedRect> &ellipses)
{
Mat image = Mat(frame.height(), frame.width(), CV_8UC4, frame.scanLine(0));
cvtColor(image, image, CV_RGB2GRAY);
GaussianBlur(image, image, Size(3, 3), 0, 0, 4);
threshold(image, image, treshVal, 255, THRESH_BINARY);
vector<vector<Point> > contours;
Mat contoursImage = image.clone();
findContours(contoursImage, contours, CV_RETR_LIST, CV_CHAIN_APPROX_NONE, Point(0, 0));
// ....Mode Code
As I said in Debug the code runs without a problem, findContours calls _contours.create(total, 1, 0, -1, true); (in line 1720 of OpenCV's contours.cpp) and moves on that method....BUT in Release, when I step into _contours.create(total, 1, 0, -1, true), instead of executing that method, the program jumps to void _OutputArray::clear() const (line 1674 of matrix.cpp) and get's trapped in there, because it calls int k = kind(); in it's first line, which, instead of calling cv::kind(), calls:
int _InputArray::type(int i) const
{
int k = kind();
Which calls againg kind() which again calls type() (instead of kind()as it should), making an infinite recursive loop, bringing a stack overflow.
I tried to make a new Visual Studio 2010 project to see if this is a project creation problem but the problem persisted.
My guess is that the function adresses are wrong in release mode so when it tries to call create(), it instead calls another address, making a mess in the stack, but that's just my guess. At first I will blame OpenCV release dlls, but, as I said, in another console project that only runs that particular code, the code runs fine in bot build modes. I don't see how my other threads and code can trigger this behavior, since the error goes down to a wrong function call in OpenCV.
This is way beyond my knowledge and I have no idea how to fix this, I appreciate all the help I can get on this problem, because I already exausted all my ideas to fix it....
EDIT :
I made a small project so anyone can see what's happening.
The files are in:
https://app.box.com/s/3owljl44emv57erinrf8
In order to run it, you have to have OpenCV 2.4.8 and Qt 5.1.1 and configure the Visual Studio 2010 project to get the include files from the right places. In the resources folder there is a image that will be loaded, and in the SaraVisualControl.cpp line 20, you have to place the right path to the image, sorry I didnt made this automatic, but I was in a hurry to pack this in a small project. Any other questions about how to run it, please let me know.
EDIT 2
I found this old thread: http://code.opencv.org/issues/2218 the user appears to have the same problem as I have, and just running CMake with OPENCV_CAN_BREAK_BINARY_COMPATIBILITY turned off appears to solve it. But this option is no longer present in the new versions of OpenCV, as stated here http://code.opencv.org/issues/2358. Does anyone knows the implications of this and how it may be related?
I encountered similar symptoms in the past, when mixing VC runtime versions. If you're working in VC2010 and OpenCV 2.4.8 was built on 2012 or even 2013, your ABI does not match. E.g., the layout in memory of std::vector is different, maybe the order of some methods in a vtable somewhere changed, etc.
An easy way to test this is to inspect the 'Modules' window while debugging and look for runtime dll's of a later version. Yours is msvcr100d.dll, if you see msvcr110d or 120d - this might be the source.
(assuming both you and OpenCV link dynamically to the CRT - which I cannot tell).
The debug and release are different in memory allocations. Usually in Debug mode that allocs are bigger.
May be you abuse some openCV call, but you don't aware of it.
I would do next actions:
Validate that the frame is ok. May be it is too big, or width or height are not initiated;
Validate that after next line the image var is OK
Mat image = Mat(frame.height(), frame.width(), CV_8UC4, rame.scanLine(0));
Is it OK to call cvtColor while the 1st and 2nd param are the same (may be you abuse the CV here)
Is it OK to call GaussianBlur while the 1st and 2nd param are the same? Try to put different 2nd param
The same is with threshold function call
Check that after image.clone call, the countoursImage is a valid matrix.
I'm guessing: In addition to checking that the libraries are all correct themselves, check that you specify all libraries in the same order (in all builds). Otherwise, the linker might bind function names to different implementations during the final linker stage.
I had the same issue.I was using Qt 5.1.1 and opencv248 and my application was crashing after returning from findcontours. Turns out I was using the vc10 libs in the pro file and the corresponding dlls whereas the Qt compiler being used was msvc2013. Switching to the vc12 folder in opencv 248 solved the problem for me.
Have you checked your opencv libraries for Release version.
Opencv has different set of libraries for Release and Debug version. if you have accedently included debug libraries in the release mode. your code will compile with no error but will throw excecption when executed.
To check your libraries goto
Project->Properties->Configuration Properties->linker->Input->Additional Dependencies.
make sure none of your Opencv libraries ends with "d" for release mode.
library for Release : 'opencv_core248.lib'
library for Debug : 'opencv_core248d.lib'
notice the d at the end for debug mode.
I hope this would be helpful.
My goal is to create a package in R with C++ code: So my questions is how?
I am following the tutorial http://www.stat.columbia.edu/~gelman/stuff_for_blog/AlanRPackageTutorial.pdf on creating an R package containing C++ code. The specific code Im trying to compile and package is exactly as described in the tutorial.
R CMD SHLIB seems to be working creating .dll file.
I can load in R using dyn.load() and test it on simulated data (as described in tutorial)
R CMD INSTALL is where the problem begins. I have done two things encountering two different errors supposedly related:
1) The tutorial says the NAMESPACE file is supposed to contain the code:
useDynLib(XDemo)
export(XDemoAutoC)
When it does R CMD INSTALL fail resulting in error:
Error in inDL(x,as.logical(local), as.logical(now),...): unable to
load shared object 'C:/.../libs/i386/XDemo.dll': Loadlibrary failure:
1% is not a valid Win32-program
2) Removing the above mentioned lines in NAMESPACE file will result in installation of package. I can succesfully load it in R but when I try to use the R function that makes a .C() call to the C++ written function I another error:
library(newpackage)
ls(package:newpackage)
[[1]] "XDemoAutoC"
Warning message:
In ls(package:newpackage) :
‘package:newpackage’ converted to character string
XDemoAutoC(c(1,2,3,4))
Error in .C("DemoAutoCor", OutVec = as.double(vector("numeric", OutLength)), :
C symbol name "DemoAutoCor" not in load table
Im running version R2.15.2 on windows 64-bit and using R64 bit.
I read the following post with a similar problem:
http://r.789695.n4.nabble.com/Include-C-DLL-error-in-C-symbol-name-not-in-load-table-td3464021.html
Except they mention nothing about the NAMESPACE-matter.
Also I read this post:
Problem with loading compiled c code in R x64 using dyn.load
So I am thinking: that based on the fact that I am able to use dyn.load() in Rx64 means that I have succesfully created x64 .dll. Assuming that the NAMESPACE file is supposed to be left as in the tutorial - hopefully fixing the >>not in load table<< error - this would mean I should focus on fixing problem one. This problem seems to be caused by something related to 32-bit. I have used Dependency Walker on the .dll file but I am not sure how to interpret the results
I really don't have any ideas on how to fix this problem so any suggestion on what to do would be welcome?
I think you are doing it wrong. Two quick suggestions:
Read the Writing R Extensions manual written to explain just this: writing R extensions including those with compiled code
Have a look at Rcpp which makes R and C++ extensions, including package building so much easier. Or so we think. Writing a package is as easy as calling Rcpp.package.skeleton(). The documentation in 1) still help.
That said, if R CMD INSTALL fails you may have some mixup in your $PATH. Never ever mix MinGW and Cygwin. Make sure no Cygwin DLLs are found when you build or call R. Path order matters greatly. See the manual for details.