I just installed dlib and I created one project with the cpu introduction example and another one with the gpu introduction example. the first one is compiled and executed on my computer and the second one is compiled and executed on a linux server to use the Nvidia GC. For the cpu example I can compile and execute without any problem. For the gpu example, I can compile without any problem but when I execute it, the initialization is ok but when the network is training I have the first epoch done properly and then I have a segmentation fault. The method used is trainer.train_one_step(mini_batch_samples, mini_batch_labels);
I also tried to train a network using the cpu and then to import it to the gpu example using the deserialize method but I also have a segmentation fault when it tried to do the prediction. The method used for the prediction is std::vector<unsigned long> predicted_labels = tnet(training_images);
I have this problem even without changing anything in the example code so I don't understand why I have this segfault. If someone can help me I will be very grateful.
I apologize for this question but just in case this really stupid mistake happens to someone, I didn't installed the latest version of dlib and this was causing troubles. After installing the latest version it's working properly...
Related
I am developing a computational geometry application in c++. This runs in parallel using threads and openmp. So, I get some geometrical values (such as nodes, edges, etc) and produce an output. This is working almost always perfect. However, there are cases like 1% that I get this messed up result. The application doesn't crash but I get really bad results, such as my output has random memory values. But even if I run on the same data twice, the second time it's gonna run fine. I used valgrind and helgrind but they didn't detect any related error. So, I am starting to run out of ideas how to trace it. Is there any other tool to try that detects possible thread errors better than helgrind? Or is there any idea on how to replicate such a problem and how to record the exact state that led to that bug?
Disclaimer: I have not used the approach below using OpenMP but based on what I just looked up it seems to be possible.
I have had a similar bug I needed to reproduce in GDB. This post helped me to run the application indefinitely until a segmentation fault occured.
We could adapt this answer to answer your question by adding a conditional break point that hits when the output value is not as expected.
set pagination off
break exit
commands
run
end
break file.cpp:123 if some_condition_holds
Now, if you would run the above with GDB it would run indefinitely until the bad result occurs (some_condition_holds is true). Then we can switch to the correct thread by using the inferior commands:
info inferiors
inferior inferior_num
Question Intro
I'm running an opencv project in Visual Studios 2010 and have implemented cuda support (refer to my previous question for precise info on my set-up). All cuda-functionalities are working fine - to the best of my knowledge - and are indeed improving speed on the image processing.
However, I now also wanted to attemp to speed up the video-writing function in this project by replacing the current cv::VideoWriter with the gpu::VideoWriter_GPU function. The reason for this is that the cv::VideoWriter seems to somehow cause processes running outside of the scope in which the VideoWriter is called to be slowed down, resulting in images available at the DirectShow driver being dropped by the VideoCapture-function, hence messing up an algorithm I've implemented.
Problem
To attempt to solve this issue, I've now replaced the VideoWriter-calls with VideoWriter_GPU-functionality (and corresponding syntax), but when I run my project (Compile & Run in Debug-mode), I get the following error-message (directly originating atthe calling of gpu::VideoWriter_GPU):
OpenCv Error: The function/feature is not implemented (The called functionality
is disabled for current build or platform) in unknown function, file
c:slave\builds\wininstallermegapack\opencv\modules\gpu\src\precomp.hpp, line 131.
and the program then ends with
code -529697949 (0xe06d7363)
I've purposely currently not included any of my code because the error-message originates so clearly from the call to the gpu::VideoWriter_GPU, which is making me think it's not a coding or syntax problem. (Please comment if you feel my code is necessary for answering this question.
My steps so far
I miss the natural gift of understanding what precisely this message means or how to interpret it. Does my opencv v2.4.4 simply not support what I want...? Does this function simply not work on my windows 7, 64bit system...?
I've checked out as many available google-hits I could find (relating to this error message and combinations of searchterms like "opencv, gpu, VideoWriter_GPU, disabled for current build") but have not understood what the problem is or how to solve it.
Corresponding header-file and error message can also be found here.
This post and this post suggest the error message is trying to tell me that opencv simply does not provide the option of using the function or functionality I am aiming to use. Or maybe even that cuda is not at all supported.. But that's all against my experience as every single opencv gpu-function I've tried to use has seemed to work fine.
Question
Could someone please explain to me why this is not working for me, and more importantly share with me what I should do to make the VideoWriter_GPU work?
Many thanks!
Maybe this link can give you a little idea of what the problem is: VideoReader_GPU not available, but built with NVCUVID?.
It seems to be that the problem is the CUDA_DISABLER var.
i'm working with Opencv, trying to copy some frame that captured from web camera. when copying the frame, i'm getting segmentation fault in __memcpy_ssse3(), line 160 or 1675.
gdb shows:
0 __memmove_ssse3 () at
../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:1675
1 0xb75ec6d0 in cv::Mat::copyTo (this=0xbfca3450, _dst=...) at
/home/david/opencv/OpenCV-2.4.2/modules/core/src/copy.cpp:181
2 0xb75984f6 in cv::Mat::Mat (this=0xbfca358c, img=0xb1300c90,
copyData=true) at
/home/david/opencv/OpenCV-2.4.2/modules/core/src/matrix.cpp:510
The function that calls it is cv::MAt::Mat(IplImg *I, bool copy).
When I'm opening USB camera or file, everything is perfect, but when trying to read the video stream from webcam, via IP, it crashes after a minute.
I'v try to build ffmpeg and opencv without ssse3 support, and my application compiled with -mno-seee3 flag too.
Opencv vesion is 2.4.2, but the problem exists in 2.3.1 too.
ffmpeg version is 11.1, same problem in 8.X.
gcc version is 4.6.3, Ubuntu's branch.
The processor is Intel core2.
Any hints?
Segmentation faults in SSE operations are due to misaligned memory. Try passing -mpreferred-stack-boundary=4 -mstackrealign to see if that clears it up. If it does then you need to examine your stack to find out which code is misaligning it.
Thank you all, solved.
There was a mistake in locking between threads, and somehow the memory was override or freed in other thread. After fixing the lock dependencies the problem of segfault solved.
I am trying to compile a rather big application on Solaris. Compiling it on AIX caused a problem that the command line buffer was too small (ARG_MAX).
On Solaris it compiles most of application successfullym but then it just hangs and without any error hangs an do nothing for at least an hour.
I am running it on SunOS 5.10 Sparc 32 bit.
Any ideas on how to find out what's going on or what might be causing such behavior?
I can't tell if the compilation is hanging, or your app itself.
If the app is hanging just follow the usual debugging steps: Either run it in your debugger and watch when it dies, or add print statements.
If the compiler dies, does it always die on the same file? If you compile that file by itself does it still hang? If so, try trussing the compiler when you try to build the file that hangs. You may find that it's blocking on I/O waiting for some nonexistant file or something similar.
What you may have to do is:
Comment out or delete 99% of the code and compile that
Add around 5% of the code back in and compile that
if the last thing you added caused the hour hang then split it up
Back to step 2
Just for those who encounter this in future.
The problem was optimization flag causes it to take a REALLY long time to compile. I am talking 1+ hour for one cpp file.
This is big project.
In addition there was an issue with Sys Admin on SUN box not giving me enough CPU share.
Increasing that solved this problem, well made it quicker and within reasonable time bounds.
I hope this helps
I have an application that is built against OpenSceneGraph (2.6.1) and therefore indirectly OpenGL. The application initializes and begins to run, but then I get the following exception "attempt was made to execute an invalid lock sequence" in OpenGL32.dll. When I re-run it, I sometimes get this exception, and sometimes an exception about a "privileged instruction". The call stack looks like it is corrupted, so I can't really tell exactly where the exception is being thrown from. I ran the app quite a bit a couple of days ago and never saw this behavior. Since then I have added an else clause to a couple of ifs, and that is all. My app is a console application, is built with Visual Studio 2008, and it sets OpenScenGraph to SingleThreaded mode. Anybody seen this before? Any debugging tips?
Can you reproduce it with one of the standard examples?
Can you create a minimal app that causes this?
Do you have a machine with a different brand video card you can test it on (eg Nvidia vs. ATI) there are some issues with openscenegraph and bad OpenGL drivers.
Have you tried posting to osg-users#lists.openscenegraph.org
The problem turned out to be our app was picking up an incorrect version of the OpenGL DLL , instead of the one installed in System32.