OGDF segfault on any GraphAttributes function call - c++

I am just starting with OGDF and try to get a hang of it by running some of the examples that are on the OGDF webpage under How-Tos.
My Code compiles, but it segfaults when I try to call a GraphAttributes function on a node.
Here my Code:
ogdf::Graph G;
ogdf::GraphAttributes GA(G);
if (!ogdf::GraphIO::readGML(G, "sierpinski_04.gml") ) {
std::cerr << "Could not load sierpinski_04.gml" << std::endl;
return 1;
}
ogdf::node v;
GA.setAllHeight(10.0);
GA.setAllWidth(10.0);
ogdf::FMMMLayout fmmm;
fmmm.useHighLevelOptions(true);
fmmm.unitEdgeLength(15.0);
fmmm.newInitialPlacement(true);
//fmmm.qualityVersusSpeed(ogdf::FMMMLayout::qvsGorgeousAndEfficient);
fmmm.call(GA);
ogdf::GraphIO::writeGML(GA, "sierpinski_04-layout.gml");
for(v=G.firstNode(); v; v=v->succ()) {
std::cout << v << std::endl;
//the following line causes the segfault
double xCoord = GA.x(v);
}
If I comment out the line that I mention in the comment is causing the segfault the program runs fine without a segfault.
If I then look into the written out .gml file the nodes have x- and y- Coordinates.
I am getting the following message:
MT: /home/work/lib/OGDF-snapshot/include/ogdf/basic/NodeArray.h:174: T& ogdf::NodeArray<T>::operator[](ogdf::node) [with T = double; ogdf::node = ogdf::NodeElement*]: Assertion `v->graphOf() == m_pGraph' failed.
It also happens when I call a different function on GraphAttributes, as for example .idNode(v).
Can someone point me in the right direction why this is happening? I do absolutly not understand where this is coming from by now, and OGDF is to big to just walk through the code and understand it. (At least for me)
Thank you very much in advance!

Unfortunatelly, your problem is not easy to reproduce.
My intuition would be to initialize the GraphAttributes after loading the Graph from the file.
ogdf::Graph G;
if (!ogdf::GraphIO::readGML(G, "sierpinski_04.gml") ) {
std::cerr << "Could not load sierpinski_04.gml" << std::endl;
return 1;
}
ogdf::GraphAttributes GA(G, ogdf::GraphAttributes::nodeGraphics |
ogdf::GraphAttributes::nodeStyle |
ogdf::GraphAttributes::edgeGraphics );
Or to call the initAttributes after loading the graph.
ogdf::Graph G;
ogdf::GraphAttributes GA(G);
if (!ogdf::GraphIO::readGML(G, "sierpinski_04.gml") ) {
std::cerr << "Could not load sierpinski_04.gml" << std::endl;
return 1;
}
GA.initAttributes(ogdf::GraphAttributes::nodeGraphics |
ogdf::GraphAttributes::nodeStyle |
ogdf::GraphAttributes::edgeGraphics);
Hopefully, that's helping.

For me, building without -DOGDF_DEBUG worked.
The assertion (which accidentally fails) is only checked in debug mode.
In Graph_d.h:168:
#ifdef OGDF_DEBUG
// we store the graph containing this node for debugging purposes
const Graph *m_pGraph; //!< The graph containg this node (**debug only**).
#endif

Related

Access violation while initializing matlab-compiler dll / lib in c++ only during debugging

what I'm trying to do is integrate a MATLAB-Compiler dll/lib to an new c++ project.
I followed this instruction: How do I integrate my C++ shared Library generated from MATLAB which seams working good (no build errors and intelisense is working good, so it seams all required information are there).
I'm using a very simple mathlab code / function for testing:
function output = extest( arg1,arg2 )
output = arg1+arg2;
end
And the "default" c++ code for matlab functions:
#include "extest.h"
#include <cstdlib>
#include <stdio.h>
int main(int argc, char** argv){
mclmcrInitialize();
if (!mclInitializeApplication(NULL,0)){
std::cerr << "could not initialize the application properly" << std::endl;
return -1;
}
if(!extestInitialize()){
std::cerr << "could not initialize the library properly" << std::endl;
return -1;
}
else{
try{
//code itself (not jet reached therefore removed)
}catch(const mwException& e){
std::cerr << e.what() << std::endl;
return -2;
}
catch(...){
std::cerr << "Unexpected error thrown" << std::endl;
return -3;
}
extestTerminate();
}
mclTerminateApplication();
return 0;
}
After e few moments after the debugger tries to run the line if(!extestInitialize()) the following error gets thrown.
Exception thrown at 0x000002BF72E0EE55 in DllTestingCpp.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
I can hit visual studios continue > button and it is continued after lets say 20x click on it. Starting the code by ctrl + F5 (without debugging) everything is working good.
Any ideas why this happens in debug mode? Or better how I can get rid of this error?
PS: extest is my lib name and using Matlab R2017a 64bit and Visual Studio 2017 (debugging with x64),
The same problem (Matlab2017 + VS 2015) for me.
Probably there is some conflict with java used by MATLAB.
I've fixed it by
const char *args[] = {"-nojvm"};
const int count = sizeof(args) / sizeof(args[0]);
mclInitializeApplication(args, count))
instead of
mclInitializeApplication(NULL,0)
I had the same issue(using VS2019) and I found the following answer here:
https://uk.mathworks.com/matlabcentral/answers/182851-how-do-i-integrate-my-c-shared-library-generated-from-matlab-r2013b-in-visual-studio-2013
I encountered this same issue and reported it to Mathworks. They responded that for VS2013 and later, the debugger is set to break when 0xc0000005 occurs, even though in this case it is handled by the JVM.
The fix is to go to Debug>Windows>Exception Settings>Win32 and uncheck '0xc0000005 Access Violation'. In VS2012, this setting is unchecked by default.
This seems to work o.k.

SDL2 Wrapper class complains `Invalid Renderer`

I'm trying to write a C++ wrapper class around some SDL2 classes.
Now I have this working code, which displays a red screen for 5 seconds (as you can see, my wrapper classes are in namespace sdl2cc):
int main(void)
{
if (SDL_Init(SDL_INIT_VIDEO) < 0) return 1;
sdl2cc::Window window{"SDL_RenderClear"s, sdl2cc::Rect{sdl2cc::Point{SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED}, sdl2cc::Dimension{512, 512}}, {}};
sdl2cc::Renderer renderer{window, {}};
renderer.draw_color(sdl2cc::Color{sdl2cc::RGB{255,0,0}, sdl2cc::Alpha{255}});
SDL_RenderClear(renderer.data());
// renderer.clear();
SDL_RenderPresent(renderer.data());
// renderer.present();
SDL_Delay(5000);
SDL_Quit();
}
In the wrapper class of SDL2's SDL_Renderer I have a std::unique_ptr data member renderer_ pointing to an actual SDL_Renderer.
renderer.data() exposes this pointer (return this->renderer_.get();).
I want to get the member functions renderer.clear() and renderer.present() to work. Sadly neither do. This is how they look:
void sdl2cc::Renderer::clear(void)
{
if (SDL_RenderClear(this->data()) < 0)
{
std::cerr << "Couldn't clear rendering target with drawing color:" << ' ' << SDL_GetError() << '\n';
}
}
void sdl2cc::Renderer::present(void)
{
SDL_RenderPresent(this->data());
}
If I just use renderer.clear(), it will print my error message + Invalid renderer.
If I just use renderer.present(), it will show a black screen.
What is wrong?
Why are my own functions and the SDL functions not equivalent?
The problem seems to lie in the function call:
SDL_RenderClear(renderer.data()); // works
// somewhere else:
void sdl2cc::Renderer::clear(SDL_Renderer* r)
{
if (SDL_RenderClear(r) < 0)
{
std::cerr << "Couldn't clear rendering target with drawing color:" << ' ' << SDL_GetError() << '\n';
}
}
renderer.clear(renderer.data()); // doesn't work: Invalid Renderer
But I still don't understand where the problem lies. To me it seems to accomplish the same thing, but somehow one throws an error, the other doesn't.
EDIT:
Another interesting thing, trying to step in at renderer.clear() with lldb goes directly to the next line, without actually stepping in... I don't even.
The problem had to do with multiply linked libraries.
I compiled my own library with the SDL2 libraries and then compiled my executable with my library and the SDL2 libraries.

PCL Visualizer example: Cannot acquire keyboard and mouse events

I'm following this tutorial in the official PCL documentation for the class PCLVisualizer:
http://pointclouds.org/documentation/tutorials/pcl_visualizer.php
and I'm having troubles with the keyboard acquisition: when I select the render window, where the pointcloud is displayed, and try to press "r" or "q", nothing happens and when I try to press the mouse left button, the following text is displayed:
Left mouse button released at position (413, 475)
and the following error is raised (at runtime):
Assertion failed: (px != 0), function operator->, file /usr/local/include/boost/smart_ptr/shared_ptr.hpp, line 687.
Abort trap: 6
I saw that this kind of error happens when you don't initialize the boost::shared_ptr in the declaration of the variable. But in the code listed in the documentation the variable is well defined, so I suppose that the problem concerns the shared_ptr.hpp library, or it isn't?
I've searched over the Internet for a solution, but I haven't found nothing that could solve the issue.
Is there someone that is capable of acquiring keystrokes in the pointcloud's render window by running it on OS X?
If the question is not clear, please let me know.
Thanks a lot for any help or information!
You do not show any code so it's hard to tell what's wrong in your program.
Here is a working example, tested on Ubuntu 14.04 with PCL latest trunk (VTK trunk):
#include <iostream>
#include <pcl/visualization/pcl_visualizer.h>
void keyboardEventOccurred(const pcl::visualization::KeyboardEvent &event, void* viewer_void)
{
boost::shared_ptr<pcl::visualization::PCLVisualizer> viewer = *static_cast<boost::shared_ptr<pcl::visualization::PCLVisualizer> *>(viewer_void);
if (event.getKeySym() == "r" && event.keyDown())
std::cout << "'r' was pressed" << std::endl;
if (event.getKeySym() == "h" && event.keyDown())
std::cout << "'h' was pressed" << std::endl;
}
void mouseEventOccurred(const pcl::visualization::MouseEvent &event, void* viewer_void)
{
boost::shared_ptr<pcl::visualization::PCLVisualizer> viewer = *static_cast<boost::shared_ptr<pcl::visualization::PCLVisualizer> *>(viewer_void);
if (event.getButton() == pcl::visualization::MouseEvent::LeftButton &&
event.getType() == pcl::visualization::MouseEvent::MouseButtonRelease)
std::cout << "Left mouse button released at position (" << event.getX() << ", " << event.getY() << ")" << std::endl;
}
int main()
{
pcl::visualization::PCLVisualizer::Ptr viewer(new pcl::visualization::PCLVisualizer);
viewer->addCoordinateSystem();
viewer->registerKeyboardCallback(keyboardEventOccurred, (void*)&viewer);
viewer->registerMouseCallback(mouseEventOccurred, (void*)&viewer);
viewer->spin();
}
Note that some key-strokes are already used by the PCL visualizer for some actions (press h for more details), but it does not prevent you from using them as well.

C++, debugging symbols and GDB

We developed a dynamic library L.so and an executable X which uses it. Both compiled with debugging info. While running gdb X:
Reading symbols from X...Segmentation fault (core dumped)
The X contains from 4 objects and I found out which one causes the crash. Lets say, if S.cpp is compiled, it crashes in gdb. S.cpp:
class Service {
private:
...
private:
...
LongTaskService longTaskService_; // Implementation is in L.so
If I remove this method from S.cpp, the crash disappears:
bool Service::downloadFile(const string &mapName, int &taskId) {
Properties dProps;
if(!config_.get("downloadService", dProps)) {
LOGG(Logger::ERROR) << "Failed to get config props for downloadService" << Logger::FLUSH;
return false;
}
string url = dProps.get("downloadUrl");
if(url == "") {
LOGG(Logger::ERROR) << "Failed to get url for downloadService" << Logger::FLUSH;
return false;
}
if(url[url.size()-1] != "/")
url += "/";
LOGG(Logger::DEBUG) << "Initializing download from "<< url << mapName << Logger::FLUSH;
URL dUrl(url+mapName);
vector<string> outPath = {workDir_, mapName};
URL outFile(FsUtil::makePath(outPath));
taskId = longTaskService_.submit(DownloadTask::run, dUrl, outFile); // This line causes problems
return true;
}
I wonder why is it like this and can I avoid the crash while debugging?
The usual thing to do here is run "gdb gdb" and then file a bug report with the stack trace.
Another possibility is that you could try updating to a newer version of gdb. That might help.
Anyway it is just a bug. Very new versions of gdb have a bit of protection against some crashes of this sort; but protecting against all crashes is hard.

Boost thread_interrupted exception terminate()s with MinGW gcc 4.4.0, OK with 3.4.5

I've been "playing around with" boost threads today as a learning exercise, and I've got a working example I built quite a few months ago (before I was interrupted and had to drop multi-threading for a while) that's showing unusual behaviour.
When I initially wrote it I was using MingW gcc 3.4.5, and it worked. Now I'm using 4.4.0 and it doesn't - incidentally, I've tried again using 3.4.5 (I kept that version it a separate folder when I installed 4.4.0) and it's still working.
The code is at the end of the question; in summary what it does is start two Counter objects off in two child threads (these objects simply increment a variable then sleep for a bit and repeat ad infinitum - they count), the main thread waits for the user via a cin.get() and then interrupts both threads, waits for them to join, then outputs the result of both counters.
Complied with 3.4.5 it runs as expected.
Complied with 4.4.0 it runs until the user input, then dies with a message like the below - it seems the the interrupt exceptions are killing the entire process?
terminate called after throwing an instance of '
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
boost::thread_interrupted'
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
From what I read, I think that any (?) uncaught exception that is allowed to propagate out of a child thread will kill the process? But, I'm catching the interrupts here, aren't I? At least I seem to be when using 3.4.5.
So, firstly, have I understood how interrupting works?
And, any suggestions as to what is happening and how to fix?
Code:
#include <iostream>
#include <boost/thread/thread.hpp>
#include <boost/date_time.hpp>
//fixes a linker error for boost threads in 4.4.0 (not needed for 3.4.5)
//found via Google, so not sure on validity - but does fix the link error.
extern "C" void tss_cleanup_implemented() { }
class CCounter
{
private:
int& numberRef;
int step;
public:
CCounter(int& number,int setStep) : numberRef(number) ,step(setStep) { }
void operator()()
{
try
{
while( true )
{
boost::posix_time::milliseconds pauseTime(50);
numberRef += step;
boost::this_thread::sleep(pauseTime);
}
}
catch( boost::thread_interrupted const& e )
{
return;
}
}
};
int main( int argc , char *argv[] )
{
try
{
std::cout << "Starting counters in secondary threads.\n";
int number0 = 0,
number1 = 0;
CCounter counter0(number0,1);
CCounter counter1(number1,-1);
boost::thread threadObj0(counter0);
boost::thread threadObj1(counter1);
std::cout << "Press enter to stop the counters:\n";
std::cin.get();
threadObj0.interrupt();
threadObj1.interrupt();
threadObj0.join();
threadObj1.join();
std::cout << "Counter stopped. Values:\n"
<< number0 << '\n'
<< number1 << '\n';
}
catch( boost::thread_interrupted& e )
{
std::cout << "\nThread Interrupted Exception caught.\n";
}
catch( std::exception& e )
{
std::cout << "\nstd::exception thrown.\n";
}
catch(...)
{
std::cout << "\nUnexpected exception thrown.\n"
}
return EXIT_SUCCESS;
}
Solved.
It turns out adding the complier flag -static-libgcc removes the problem with 4.4.0 (and has no apparent affect with 3.4.5) - or at least in this case the program returns the expected results.