Have you ever run into issue where function in SFML 2 to get availiable modes returns you:
availiableVideoModes [3]({width=3131961357 height=3131961357 bitsPerPixel=3131961357 },{width=3131961357 height=3131961357 bitsPerPixel=3131961357 },{width=3131961357 height=3131961357 bitsPerPixel=3131961357 }) std::vector >
max int values in vector? Interesting is why 3? I tried quick debugging without luck so in parallel I thought to raise question here.
code:
std::vector<sf::VideoMode> availiableVideoModes;
availiableVideoModes = sf::VideoMode::getFullscreenModes();
interesting is that
desktopVideoMode = sf::VideoMode::getDesktopMode();
returns correct value.
The issue was in libraries link, I have linked 32bits one instead of 64bits.
Related
After installing the 1.1.92.1 VulkanSDK xmemory0 and vector errors popped up and the project does not compile any more, bellow are the output errors from Visual Studio 2017. Going back to the previous 1.1.85.0 sdk version thought, it works again. Any idea what happens? Thanks.
Edit
<https://pastebin.com/94x8Lerq>
the error list is too big to include here, i m using this link
Edit2
It seems the way to enumerate stuff (at least the way i did it), has changed a bit, thus it explains those vector error i was getting.
Old way:
uint32_t gpuCount = 0;
vulkan.instance.enumeratePhysicalDevices(&gpuCount, nullptr);
std::vector<vk::PhysicalDevice> gpuList(gpuCount);
vulkan.instance.enumeratePhysicalDevices(&gpuCount, gpuList.data());
New way:
std::vector<vk::PhysicalDevice> gpuList = vulkan.instance.enumeratePhysicalDevices().value;
Since you are using vulkan.hpp, you could ask about this on their GitHub site. You could also diff vulkan.hpp between the two SDKs and note that there are differences in the file where enumeratePhysicalDevices is concerned.
I am facing some strange behaviour appearing only on some notebook.
I am developing in c++ using msvc 2012 and the qt framework.
I will try to sum up the problem and i am hoping that someone has any idea what the problem could be or what i could try to find out..
Generally it's the following problem:
void myclass::foo()
{
const double value1 = 100.0;
double value2;
value2 = some_function_returning_double();
if(value1 > value2)
{
//__ do something
}
}
The problem is that the condition fails as the local variable gets overwritten.
If I do some debug output i can see that variable value1 is not 100.0 anymore but some random value .. so that the comparison randomly fails ..
One thing i figured out is that everything just works fine if i don't use local variables. If i set up value1 and value2 as member variables of my class everything works without problems, but that can't be the solution.
Now the strange thing is that this error does only occur on some notebook (some mobile i5 cpu).
On my machine (i5) and on many other notebooks (even other mobile i5) everything just works fine.
I know that you won't be able to solve my problem with this little information i can offer here, but maybe some of you has any hint what the problem could be and what i could try to solve this.
Many thanks in advance.
In visual studio 2012, add a data breakpoint (debug->new breakpoint->new data breakpoint) on the address of the variable that gets overwritten.
First, break at the start of the function.
Then set the data breakpoint: just type &value1 in the "New breakpoint` the input box.
Then it should break just after the value has been modified, and you should see the culprit.
Data breakpoints are a very powerful tool, that helped me found nasty bugs very quickly.
I am new to using GDAL, and am having trouble creating a GDALDataset using the GDALDriver::Create() method. In this case, I am using C++. Ultimately I am trying to create a raster and write values from an array to the raster. A minimal working example of the code that generates the problem of creating a dataset is given here:
#include <iostream>
#include </usr/include/gdal/gdal_priv.h>
int main(){
std::cout << "starting GDAL business\n";
const char *raster_format = "GTiff";
GDALDriver *g_driver;
g_driver = GetGDALDriverManager()->GetDriverByName(raster_format);
GDALDataset *g_dataset;
const char *test_file = "test_file.tif";
char **raster_creation_options = NULL;
std::cout << "raster options created\n";
g_dataset = g_driver->Create(test_file,
100,200,1,GDT_Float32,
raster_creation_options); //<--- seg faults
std::cout << "dataset created\n";
}
The resulting console looks like:
starting GDAL business
raster options created
Segmentation fault (core dumped)
I am just following the basic API tutorial (Link), but am encountering this problem. I am on Ubuntu 14.04, using the repository's libgdal packages.
Can anyone shed some light on this problem?
I know this is an old question and the issue has probably long since been resolved, but I figured I would throw my answer into the ring. After all, I was directed here when I had this problem and it seems like the question has a fair amount of views.
If your code is not working, and you are having trouble loading the driver, I would suggest adding the line GDALAllRegister();. I was following the same tutorial as you, and they mention adding this line at the top of the tutorial, but if you're like my and rushed right to the part you needed, the Create part of the tutorial, you probably overlooked that step.
Hopefully this answer helps someone, if not the original author of the question.
I'm writing program on c++ that needs to generate graphs and calculate some measures.I'm working with Visual Studio 2013 and Igraph C library. At this point I can create graphs from custom info and calculate some metrics like betweennes and closeness centrality, but when i try to calculate eigenvector centrality, the program crash and show me this message:
"Run-Time Check Failure #3 - The variable 'tgetv0' is being used without being initialized."
The tgetv0 variable is used inside of dgetv.c from Igraph source.
Here is my code:
void GraphObject::calcEigen()
{
igraph_arpack_options_t options;
igraph_real_t value;
igraph_vector_t weights;
igraph_vector_init(&weights, igraph_ecount(&cGraph)); //cGraph is already created.
igraph_vector_init(&eigenRes, igraph_vcount(&cGraph)); //All ..Res igraph_vector_t are declarated in header
igraph_vector_init(&betweennesRes, 0);
igraph_vector_init(&closenessRes, 0);
igraph_arpack_options_init(&options);
igraph_betweenness(&cGraph, &betweennesRes, igraph_vss_all(), 0, 0, 1);
igraph_closeness(&cGraph, &closenessRes, igraph_vss_all(), IGRAPH_ALL, 0, 1);
igraph_eigenvector_centrality(&cGraph, &eigenRes, &value, 0, 1, &weights, &options);
}
The closeness and betwenness are correctly calculated an "couted" but crash on eigenvector function.
After lot of research on documentation, internet and the debugger i cant't figure which is the problem, especially when I tryed the example code in the documentation http://igraph.org/c/doc/igraph-Structural.html#igraph_eigenvector_centrality (copy/paste) and makes the same. Is this a library or example issue, I a'm missing something?
When I init the weights vector and then I call igraph_null(&weights), it works but the result of all eigenvalues is 1, and this is incorrect result. What I'm doing wrong?
Let us assume that Visual Studio is right and we indeed have a variable named tgetv0 that is being used uninitialized. I scanned igraph's source code and it looks like there are two places where it could indeed be the case. One of them is in src/lapack/dnaupd.c, the other one is in src/lapack/dsaupd.c. Both of these files were converted from Fortran using f2c so it is hard to tell whether the issue was present in the original Fortran code or whether this was introduced during the conversion. Either way, you can probably fix this easily by looking up the lines where tgetv0 is declared in src/lapack/dnaupd.c and src/lapack/dsaupd.c and initializing it to a value of 0. In my version, the lines to change are line 486 in src/lapack/dnaupd.c and line 482 in src/lapack/dsaupd.c.
Please add a comment to confirm whether the solution works for you or not - if it works, I'll commit a patch to the igraph source tree.
I do some image processing work in C++. For this i use CImg.h library which i feel is good for my work.
Here is small piece of code written by me which just reads an image and displays it.
#include "../CImg.h"
#include "iostream"
using namespace std;
using namespace cimg_library;
int main(int argc,char**argv)
{
CImg<unsigned char> img(argv[1]);
img.display();
return 0;
}
When i give lena.pgm as input this code it displays the image. Where as if i give some other image, for example ddnl.pgm which i present in the same directory i get "Segmentation Fault".
When i ran the code using gdb i get the output as follows:
Program received signal SIGSEGV, Segmentation fault.
0x009823a3 in strlen () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.9-2.i686 libX11-1.1.4-5.fc10.i386 libXau-1.0.4-1.fc10.i386 libXdmcp-1.0.2-6.fc10.i386 libgcc-4.3.2-7.i386 libstdc++-4.3.2-7.i386 libxcb-1.1.91-5.fc10.i386
Can some one please tell me what the problem is? and how to solve it.
Thank you all
Segfault comes when you are trying to access memrory which you are not allowed to access.
So please check that out in the code.
The code itself looks just fine. I can suggest some ways to go ahead with debugging -
Try removing the display() call. Does the problem still occur? (I'd assume it does).
Try finding out where in the CImg code is the strlen() that causes the segmentation fault (by using a debugger). This may give additional hints.
If it is in the PGM file processing, maybe the provided PGM file is invalid in some way, and the library doesn't do error detection - try opening it in some other viewer, and saving it again (as PGM). If the new one works, comparing the two may reveal something.
Once you have more information, more can be said.
EDIT -
Looking at the extra information you provided, and consulting the code itself, it appears that CImg is failing when trying to check what kind of file you are opening.
The relevant line of code is -
if (!cimg::strcmp(ftype,"pnm")) load_pnm(filename);
This is the first time 'ftype' is used, which brings me to the conclusion that it has an invalid value.
'ftype' is being given a value just a few lines above -
const char *const ftype = cimg::file_type(0,filename);
The file_type() function itself tries to guess what file to open based on its header, probably because opening it based on the extension - failed. There is only one sane way for it to return an invalid value, which would later cause strcmp() to fail - when it fails to identify the file as anything it is familiar with, it returns NULL (0, actually).
So, I reiterate my suggestion that you try to verify that this is indeed a valid file. I can't point you at any tools that are capable of opening/saving PGM files, but I'm guessing a simple Google search would help. Try to open the file and re-save it as PGM.
Another "fun to track down" cause of segmentation faults is compilier mismatches between libraries - this is especially prevalent when using C++ libraries.
Things to check are:
Are you compiling with the same compiler as was used to compile the CImg library?
Are you using the same compiler flags?
Were there any defines that were set when compiling the library that you're not setting now?
Each of these has bitten me in subtle ways before.