I am trying to use libdxf library. I have created a small program running which I am getting a segmentation fault. I have debugged my code using gdb and have located the code line causing the core to be dumped.
My code snippet is as written below:
#include<iostream>
#include<../src/dl_dxf.h>
#include<../src/dl_creationadapter.h>
using namespace std;
class Test:public DL_CreationAdapter {
public:
void write();
};
void Test::write(){
DL_Dxf *dxf = new DL_Dxf(); // fault here
DL_Codes::version exportVersion = DL_Codes::AC1015;
DL_WriterA* dw = dxf->out("myfile.dxf", exportVersion);
if (dw==NULL) {
printf("Cannot open file 'myfile.dxf' \
for writing.");
}
delete dxf;
}
int main(){
Test test;
test.write(); // fault here
return 0;
}
The source of segmentation fault is in 2 lines above with the comment //fault here.
How to handle this segmentation fault?
I wish you are working on Linux.
I compiled your code an ran succesfully just by replacing
#include<../src/dl_dxf.h>
#include<../src/dl_creationadapter.h>
with
#include<dxflib/dl_dxf.h>
#include<dxflib/dl_creationadapter.h>
I installed libdxflib-dev package via package manager on Ubuntu(And also libdxflib-2.5.0.0 that includes the libdxflib.so).
It created an empty 'myfile.dxf' and exited.
Since you include dxf headers from another directory I suspect that there is a compatibility problem (possibly between dxf headers and the shared object file)
If you are an Ubuntu user below lines to compile the program via using standart packages may be helpful to understand the root cause
sudo apt-get install libdxflib-dev libdxflib-2.5.0.0
replace inclusions with
#include<dxflib/dl_dxf.h>
#include<dxflib/dl_creationadapter.h>
then compile with command
g++ -Wall dxf.cpp -ldxflib -L/usr/lib/x86_64-linux-gnu/
and run a.out
Note that /usr/lib/x86_64-linux-gnu/ is where libdxflib.so stands. It may be different in your environment.
Related
I have recently started using std::filesystem, and I have faced an issue that I could not fix. I have a class with a function that periodically iterates over some directories and in case new files are found, it adds its name and size to a map container. But I constantly either received segmentation fault or std::bad_alloc. I therefore wrote a simple test to see if it works out of my relatively large and complex make file project. But I still receive segmentation fault.
I simply get the number of files in a directory this way:
int main(){
const fs::path Path = fs::current_path();
for (const auto& p:fs::directory_iterator(Path)){
count++;
}
return count;
}
the error is somehow connected to path object destructor. The debugger throws the following error:
Program received signal SIGSEGV, Segmentation fault.
0x0000555555556693 in std::vector<std::filesystem::__cxx11::path::_Cmpt, >std::allocatorstd::filesystem::__cxx11::path::_Cmpt >::~vector (this=0x20, >__in_chrg=) at /usr/include/c++/8/bits/stl_vector.h:567
567 std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
Program terminated with signal SIGSEGV, Segmentation fault.
Now, I've seen few posts about g++ issue with filesystem, like this one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050
I use g++ 8.4.0 on an Ubuntu 18.4 machine. I tried in my makefile project to add -lstdc++fs to linker flags, but it did not make a difference.
So the question is what is the root cause of this error? Is it really caused by g++?
thanks in advance for helping!
I have this simplified example,
int myf(void) {
int a = 1;
int b = 2;
return a + b;
}
int main(void) {
int sum = myf(); // <--- bp here
printf("Result: %d\n", sum);
return 0;
}
I have a breakpoint at int sum = myf() and I run the debugger. Gdb successfully stops at this point, but a step into command (into myf) leads to a segmentation fault. If I put a bp directly in myf and run the debugger, then the debugger stops there as expected, no problem. In a shared library, not even the breakpoints work. They are ignored completely. Stepping into shared library code leads to the same segmentation fault error.
Step over functionality is also "broken". Stepping over code sometimes jumps into random (I think) locations, like in a file named dl-minimal.c
The code behaves as expected if it's simply run and not debugged.
Other useful info that I get in the debugger console when I get the segmentation fault error:
No function contains specified address
Disassembler failed: Cannot access memory at address 0xe7f001dc
See the printscreen for the full dbg console output:
The error is reproducible only when using a crosstoolchain for an ARM board (i.MX6). I have no such problem when debugging locally, on a Linux machine. I am using qtCreator 5.15. My cross-toolchain is built with yocto and bitbake.
Any hints regarding possible causes?
Set the GDB search path - in Tools->Options->Debugger. In the Additional Startup Commands box. Place there the correct sysroot (corresponding to the platform you are running from), and follow with the full path of your shared libraries debug build, from the local machine.
Also, make sure to run as regular user (set in Tools->Options->Devices) - though you will need to switch to root user when you deploy.
I am new to C++ and want to print out a double value. It is not that I actually need to print that value, I just want to know what is going wrong here.
This is my code (HelloWorld.cpp):
#include <iostream>
int main() {
double i = 5.5;
std::cout << i << std::endl;
return 0;
}
Executing this with the debugger attached results in the following error:
Thread 1 hit Breakpoint 1, main () at src/HelloWorld.cpp:4
4 double i = 5.5;
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000000929ba260 in ?? ()
When I put a breakpoint in there, creating and assigning the variable is no problem. The error only occurs once the program is supposed to print that value. Executing the exe without the debugger results in no output at all. The same happens when I replace the double with a long double or float. Printing anything else works fine (Strings, char, int, short, etc.).
I am using Visual Studio Code and MinGW (x86_64-8.1.0-posix-seh-rt_v6-rev0). VS Code is using following files for compilation / debugging:
c_cpp_properties.json
launch.json
tasks.json
And here you can see the complete output, in case that helps.
Any Idea what I am doing wrong here? Thank you.
EDIT:
When compiling manually using g++ -g .\src\HelloWorld.cpp -std=c++11 -o HelloWorld.exe (or just g++ .\src\HelloWorld.cpp -o HelloWorld.exe) and running that from the console, the same happens (no output).
I installed MinGW from here using the following settings:
Version: 8.1.0
Architecture: x86_64
Threads: posix
Exception: seh
Build revision: 0
EDIT 2:
Found the problem. There was an old version of gcc lurking in my PATH (maybe from Visual Studio or MSSQL Server?). I just move the current gcc to the top of PATH and now it's working fine. Thank you all for your help!
As many pointed out, this should usually work. The problem was with my setup: I had an old version of gcc somewhere in my PATH variable (version 4.1). Moving the path of the newer version to the beginning of PATH resolves the issue. Thank you all for helping.
To check weather the same happens to you you can do the following: execute g++ --version in your project directory. Compare this with the output of g++.exe --version when you are in the directory where gcc is installed (for me, this was C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin).
I am working on Windows 8 with OpenCV 2.4.13 and MinGW 4.9.
I wrote a simple and small opencv program to check if everything was installed properly. Following is the code:
#include <opencv2/highgui/highgui.hpp>
int main () {
printf("in main\n");
for (int i = 0; i<10; i++) {
printf("here\n");
IplImage * image = cvLoadImage("C:/{...}/test.jpg");
cvReleaseImage(&image);
}
return 0;
}
I compiled it with the following command at the command prompt:
g++ -o test test.cpp -LC:\{...}\opencv\build\x64\vc11\lib -lopencv_core2413 -lopencv_highgui2413 -IC:\{...}\opencv\build\include
{...} is the path to the specified folder/file.
This command runs properly and compilation is successful without any errors. However, when I run it with:
test
in main and one here gets printed after which I get the error message as 'test.exe has stopped working. Windows is looking for a solution.'
What all I have tried:
For installation of OpenCV, ran the downloaded opencv executable file (which extracts all files) and added the system variable OPENCV_DIR and edited the system PATH for location of DLLs (which reside in %OPENCV_DIR%\bin) as per:
http://docs.opencv.org/2.4/doc/tutorials/introduction/windows_install/windows_install.html#installation-by-using-the-pre-built-libraries
Tried adding the required DLLs in the same directory as the .exe.
Tried doing the whole thing from vc12 directory.
After the error message appears, it gives an option of debugging. On pressing that, the Just In Time Debugger opens up and says 'An unhandled win32 exception occurred in test.exe'. I googled this and tried inspecting the registry key as directed here
https://support.microsoft.com/en-us/kb/811191
but it was already properly set. So, there was nothing for me to change in that.
Nothing is working for me at all. Please let me know if any more information is required. I'm desperately looking for a solution to this.
For those who might be encountering the same problem, I compiled the program with OpenCV dynamic (.dll) libraries instead of the .lib files and it ran just fine at runtime for some reason.
I'm trying to compile an run a very basic program given below (test.cpp) which calls the OpenNI class. You can see the files and dirs they're in here. Sorry that some characters screws up a little bit in the browser's encoding. I'm using the linux command: tree, if you know a better command tell me and I will update it.
File Structure
I'm following the guide here, see "GCC / GNU Make".
#include < stdio.h >
#include < OpenNI.h >
using namespace openni;
int
main ( void )
{
Status rc = OpenNI::initialize();
if (rc != STATUS_OK)
{
printf("\nInitialize failed\n%s\n", OpenNI::getExtendedError());
return 1;
}
printf("Hello, world!\n");
return 0;
}
Here is what I'm running in the command line to compile it (gcc 4.7.2):
gcc test.cpp -I../OpenNI-2.0.0/Include -L/home/evan/Code/OpenNi/Init -l OpenNI2 -o test
This works fine but when I run ./test I get the following error:
Initialize failed
DeviceDriver: library handle is invalid for file libOniFile.so
Couldn't understand file 'libOniFile.so' as a device driver
DeviceDriver: library handle is invalid for file libPS1080.so
Couldn't understand file 'libPS1080.so' as a device driver
Found no valid drivers in './OpenNI2/Drivers'
Thanks, any help would be much appreciated.
Instructions from your guide says, that
It is highly suggested to also add the "-Wl,-rpath ./" to your linkage command. Otherwise, the runtime linker will not find the libOpenNI.so file when you run your application. (default Linux behavior is to look for shared objects only in /lib and /usr/lib).
It seems you have exactly this problem -- it can not find some libraries. Try to add proper rpath (seems to be /home/evan/Code/OpenNi/Init/OpenNI2/Drivers in your case) to your compilation string.
I had the same issue after compiling this little "Hello World" with Eclipse and trying to run it in the command line.
The "Wl,-rpath=./" thing did not work for me.
As also discussed here it worked for me after setting some env. variables before execution:
export LD_LIBRARY_PATH="/path/to/OpenNI2:$LD_LIBRARY_PATH"
export OPENNI2_DRIVERS_PATH="/path/to/OpenNI2/Drivers"
export LD_LIBRARY_PATH="/path/to/OpenNI2/Drivers:$LD_LIBRARY_PATH"
Somewhere I got the info that the first two lines should be enough but it was the third line which is important. I does also work just with the third line.