I have produced a program that works perfectly fine on Linux Mint and now i have to make it work on a IBM computer running on linux red hat. For the libraries i have put them into modules (i had to recompile SFML for red hat) but when i start my program, it provokes a segfault, here is what valgrind told me about that failure :
Process terminating with default action of signal 11 (SIGSEGV)
==30230== Access not within mapped region at address 0xE0
==30230== at 0x55B5974: sf::priv::GlxContext::GlxContext(sf::priv::GlxContext*) (in /workfs/dev/libs/SFML-2-2.1/build/lib/libsfml-window.so.2.1)
Just before the segfault i have this strange error : xrandr cannot load extension for display.
This error still occurs when i try to start SFML examples
Here is the code which provokes the segfault :
//segfault ;
this->window = new sf::RenderWindow(sf::VideoMode(this->width, this->height), this->title,sf::Style::Close, settings);
It looks like SFML cant create an OpenGL content because xrandr is whining, does someone have an idea ? Could someone bring me light upon my problem :D ?
Related
I've got a c++ code of a kernel (just starting with it. So right now, it should just display "Hello, world!") with an array pointing to 0xB8000 (VGA color text mode and CGA-compatible graphics mode). When running it, it says "segmentation fault (core dumped)", which clearly means the display RAM is clearly not accessible by the user (note - I'm in ubuntu). Is there a simulator for running such sort of programs?
(My program is similar to this one -
https://www.codeproject.com/Articles/1225196/Create-Your-Own-Kernel-In-C-2
all except for that I've written everthing from my understanding, and it successfully compiles)
Cocos2d-x v4.0 crashing in all iPhone Simulator. In device no crash
glslopt_shader* glslShader = glslopt_optimize(ctx, shaderType, source.c_str(), 0);
For above line everytime crashing. Not using any shader. Above line called by Sprite creation.
auto background = Sprite::create(TEX_MM_BG);
How to fix this crash for simulator ?
With that little info we can't help much.
But if I try to interpret the posted image corretly you receive a "EXC_BAD_ACCESS" Exception.
This means more or less that you access a freed memory region or in general you try dereference a pointer pointing to an invalid memory address.
The only argument which could cause such an error is source.c_str().
So you should check the code path of source.
In release builds you don't see always "access-after-free" because memory is not immediately released to the OS (which triggers such errors) it is just marked as "free" to allow faster allocations.
I already searched the web for a while but it appears my problem is very rare:
I'm programming a Audio Unit Plugin with JUCE in C++.
When I run it in a host, the host crashes. When I attach the XCode debugger to the hoist before loading my plugin, it points me to the following:
error: address doesn't contain a section that points to a section in a object file
If I type "bt" into the debug console, it says:
* thread #1: tid = 0x1f03, 0x00000000, stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
frame #0: 0x00000000
I don't get a stack trace, making it impossible to find the source of the bug. It would help a lot to see, what was executed right before the bad access happened, but I can't figure out how.
I can set a breakpoint somewhere in the program and from there slowly make my way through the code until I reach the crash. I did this and eventually the execution leaves my source code and I get the assembly lines. I can see it jumping out of a lot of calls with the "ret" command. Eventually on one "ret" command, the crash occurs.
The assembly code is from the host that runs my plugin. But the crash appears on different types of host so I'm pretty sure, its a fault on my side. Any ideas?
Thank you!
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.
Well. that´s the question. Just that.
I got an app made with SDL and OpenGL. SDL opens an extra window (which is the console) additional to the graphical one. When i execute i´m getting a 3 output error, the console tells me. And it gets closed (the graphical one).
But i know this happens when a SIGSEGV signal is received (don´t know how to capture it) and it appears in my IDE (Code::blocks) while debugging. But this time nothing appears, and everything works all right. But when executing it crashes..
What the...
What kind of error can i expect?. Sometimes it gets closed, sometimes it doesn´t. How to know what kind of problem i got?.
SIGSEGV is a segmentation fault, you're trying to access memory that isn't accessible to your process.
Assuming you're on a UNIXy system, you should be able to get the program to core dump and then look at the core dump in a debugger; alternatively, use a memory debugger like Valgrind to pinpoint the memory management issue that's causing this problem.