Recently VS17 started giving me the "Incremental Linker has stopped working" a lot, and I mean A LOT. I did not update anything (OS or VS). It started out of a sudden for no apparent reason. Most of the time I managed to change my code so it wouldn't happen.
This is my current code (it's supposed to XOR a string and return hex escaped string):
__inline char* EncryptString(const char* String, const char* Key)
{
char* szEncrypted = new char[lstrlenA(String) + 1];
memcpy(szEncrypted, String, lstrlenA(String));
for (int32_t i = 0; i < lstrlenA(String); ++i)
szEncrypted[i] = String[i] ^ Key[i % (sizeof(Key) / sizeof(char))];
std::stringstream lpStream;
for (int32_t i = 0; i < lstrlenA(szEncrypted); ++i)
{
char cCharInd = szEncrypted[i];
int32_t nCharNum = static_cast<int32_t>(cCharInd);
lpStream << "\\x" << 2;
}
std::string sHexEscaped = lpStream.str();
lpStream.clear();
delete[] szEncrypted;
char* szReturn = new char[sHexEscaped.length() + 1];
memcpy(szReturn, sHexEscaped.c_str(), sHexEscaped.length() + 1);
return szReturn;
}
Is any hotfix coming? Or maybe you know what in my code caused this? (Yes, I am deleting the returned char*. Not that it has anything to do with the linker error but don't bully me because of it).
Or is anyone else experiencing this in VS17?
Thanks mate, it works. You can make it an answer if you want and I'll
accept it
It seems that it might be some sort of bug in VS2017. This kind of linker error happened to me even with relatively small code and something as simple as changing the output value of std::cout would trigger it for example. The solution seems to be to run Clean action on the code, which could be found in
Solution Explorer -> [Right Click on the project name] -> Clean
Related
I am trying to make a function that converts a TCHAR array to individual arrays, splitting it by a comma, then add a null terminator character (I think that is the name, it is '\0' in regEx). (Basically, the .split function in java, + a '\0'), but the code is only adding one value, then stops. It is very weird, as I believe this worked ~3-4 months ago, but not now for a reason unknown.
I would imagine it is an issue with my conceptual understanding of C++, as it is very much not my language of choice.
My apologies that this is basically asking someone to "fix my homework" (not actually homework, just a side project). However, I can't find the issue and have been unable to find the error for a few hours now, again probably due to me being dumb with C++.
Code Sample:
TCHAR** schemeValueToArray(TCHAR* buffer, DWORD size) {
TCHAR delim = ',';
TCHAR** out = new TCHAR*[CURSORS_AMOUNT];
int lastSeperator = 0;
for (int outOn = 0; outOn < CURSORS_AMOUNT-1; outOn++) {
// Get rest of section until end
TCHAR* temp = new TCHAR[size];
for (int i = 0; i < size; i++) {
if (buffer[i + lastSeperator] == ',') {
temp[i] = '\0';
out[outOn] = temp;
lastSeperator += i;
lastSeperator++;
break;
}
temp[i] = buffer[i + lastSeperator];
}
}
return out;
}
If you would like a bigger snippet, I can provide it.
Also, if it helps, this project once would change my mouse cursor theme when an app called AutoDarkMode requested. Making my cursor light theme during the day and dark theme at night. It would do this by copying the Registry theme value, splitting it, then putting the correct files in the correct registry spots. It was a small thing that I really liked, and now in explicitly, it has stopped.
Also, also, I am a lot more familiar with Java and Kotlin. If you are looking for ways to describe something and can relate it to something in those languages, I should be able to understand.
Thank you guys, appreciate any help!
If at all possible, I'd switch to using something like an std::vector<std::string> instead of pointers to pointers and such.
std::vector<std::string> schemeValueToArray(TCHAR* buffer) {
std::istringstream buf(buffer);
std::vector<std::string> ret;
std::string item;
while (std::getline(buf, item, ',')) {
ret.push_back(item);
}
return ret;
}
I'm currently struggling to debug the following code part. I'm using VS2015 community edition on windows 10.
[(BR)] is a breakpoint
The following is a (slimmed down) version of my code. I basically have nested for loops that extract all points (X&Y coordinates) from all gameObjects.
As you can see I set two breakpoints.
I hit the debug button and it stops at the first breakpoint - success. Important local variable counterVertices is zero. Great as well.
Then I hit continue. It goes TO THE SAME BREAKPOINT THREE TIMES.
Then I get to the second breakpoint. counterVertices shows zero. Why?
int counterVertices = 0;
int counterIndices = 0;
int beginningOfPolygon = 0;
//GetData
for (auto& it : this->gameObjects) { //Iterate over all gameObjects
beginningOfPolygon = counterIndices;
for (int i = 0; i < it->getOutline().getNumber(); i++) { //Iterate over all points of the gameObject
[(BR)]this->vertices[counterVertices] = it->getRenderPoint(i).x;
counterVertices++;
this->vertices[counterVertices] = it->getRenderPoint(i).y;
counterVertices++;
[(BR)]if (this->vertices[counterVertices-2] == this->vertices[counterVertices-1] && this->vertices[counterVertices-1] == 0.0f) {
cout << "A point on 0/0." << endl;
}
this->vertices[counterVertices] = 0.0f;
counterVertices++;
//Add Line to draw
this->indices[counterIndices * 2] = counterIndices;
this->indices[(counterIndices * 2) + 1] = counterIndices + 1;
counterIndices++;
}
this->indices[(counterIndices * 2) - 1] = beginningOfPolygon;
}
I'm completely lost as this isn't even the problem I wanted to solve in the first place but rather got stuck on trying to figure on my original issue.
Thanks already for your time
PS: I have screenshots of the whole thing and the process is recreatable. I can clean and rebuild the solution, restart and do a backflip. Debugging behaviour doesn't change.
PPS: The program behaves/works in a way that suggest that counterVertices is increased correctly but the debugger information contradicts that.
Make sure you have optimizations turned off. Optimizations can really make it hard to debug, as values will be held in registers and not stored until it needs to. And code flow can be very unintuitive.
As stated above my program works in Debug and Release without debug (ctrl + F5) however does not work in simply Release.
Just to clarify I have already checked to see if I have some uninitialized variables and I haven't (to the best of my knowledge anyway but I have spent quite some time looking).
I believe to have localized the issue and what I have come across is, in my opinion, very bizarre. First I set up the break points as shown in the picture below:
Then I run the program in release. And instantly the top break point moves:
I found this extremely odd. Now note the number 6302 assigned to 'n'. This number is correct and what I hoped to pass through. Now watch as I continue through the program.
We are still in good shape but then it turns for the worst.
'n' changes to 1178521344, which messes up the rest of my code.
Would someone be able to shed some light on the situation, and even better, offer a solution.
Thanks,
Kevin
Here is the rest of the function if it helps:
NofArr = n;
const int NA = n;
const int NAless = n-1;
double k_0 = (2*PI) / wavelength;
double *E = new double[NAless]; // array to hold the off-diagonal entries
double *D = new double[NA]; // array to hold the diagonal entries on input and eigenvalues on output
int sizeofeach = 0;
trisolver Eigen;
int* start; int* end;
vector< vector<complex <double>> > thebreakup = BreakUp(refidx, posandwidth, start, end);
for(int j = 0; j < (int)thebreakup.size(); j++){
// load the diagonal entries to D
for(int i =0; i < (int)thebreakup[j].size(); i++){
D[i] = -((double)2.0/(dx*dx)) + (k_0*k_0*thebreakup[j][i].real()*thebreakup[j][i].real());
}
// load the off diagonal
for(int i = 0; i < (int)thebreakup[j].size(); i++){
E[i] = (double)1.0 / (dx*dx);
}
sizeofeach = (int)thebreakup[j].size();
double *arr1= new double[sizeofeach];
arr1 = Eigen.EigenSolve(E, D, sizeofeach, mode);
complex <double> tmp( PhaseAndAmp[j][1]*cos(PhaseAndAmp[j][0]), PhaseAndAmp[j][1]*sin(PhaseAndAmp[j][0]));
// rebuild the break up with the mode
for(int i = 0; i < (int)thebreakup[j].size(); i++){
thebreakup[j][i] = (complex<double>(arr1[i],0.0)) * tmp ;
}
delete []arr1;
}
vector<complex<double>> sol = rebuild(thebreakup, start, end);
delete [] E;
delete [] D;
delete [] start;
delete [] end;
return sol;
I'm writing this as an answer, because it's way harder to write as a comment.
What strikes me immediately is the array "arr1"
First you allocate new memory and store a pointer to it in the variable arr1
double *arr1= new double[sizeofeach];
Then, immediately, you overwrite the address.
arr1 = Eigen.EigenSolve(E, D, sizeofeach, mode);
Later, you delete something. Is it safe?
delete []arr1;
It's not the double array you allocated, but something eigensolve returned. Are you sure you have the right to delete it? Try removing the delete here. Also, fix the memory leak too, by removing allocation in the first line I gave.
What worries me even more is that the "this" pointer changes. There is some nasty problem somewhere. At this point, your program has already been corrupted. Look for the issue somewhere else. Valgrind would be a GREAT tool if you can try to compile under linux.
It seems that there is some sort of code optimization going on in your program. It is not always easy to debug optimized code step-by-step since the optimization may reorder instructions.
I cannot see why the fact that 'n' changes to an apparently uninitialized value would be the root cause of the problem, since 'n' is anyways no longer used in your function. Seems like the memory is simply been released as part of the optimization.
I have discovered my mistake. Earlier in the program I was comparing pointers, not what they were pointing at. A stupid mistake but one I wouldn't have spotted without a long debugging session. My boss explained that the information given at the bottom of Visual Studio whilst in release mode cannot be trusted. So to "debug" I had to use std::cout and check variables that way.
So here is the mistake in the code:
if(start > end){
int tmp = start[i];
start[i] = end[i];
end[i] = tmp;
}
Where start and end were defined earlier as:
int* start = new int[NofStacks];
int* end = new int[NofStacks];
And initialized.
Thanks to all those who helped and I feel I must apologise for the stupid error.
The Fix being:
if(start[i] > end[i]){
int tmp = start[i];
start[i] = end[i];
end[i] = tmp;
}
I have a chunk of code:
void split(std::vector<std::string> * v,const char* s,const char* x) {
size_t len = strlen(s);
size_t slen = strlen(x); //slen = Search Length
if(len==0||slen==0)
return;
v->clear();
char* f = new char[len];
memset(f,0,len);
int * counter =new int;
(*counter)=0;
for(unsigned int i = 0; i<len; i++) {
if(isNext((s+(i*sizeof(char*))),x)) {
f[i]=1;
counter++;
}
}
if((*counter)==0) {
delete [] f;
delete counter;
v->clear();
return;
}
...
However when I am debugging it with gdb (on cygwin) or the visual studio debugger I get this error (from the cygwin console)
(gdb) step
36 if(len==0||slen==0)
(gdb) step
38 v->clear();
(gdb) step
std::vector<std::string, std::allocator<std::string> >::clear (
this=0x60003a3e0)
at /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/bits/stl_vector.h:1126
1126 { _M_erase_at_end(this->_M_impl._M_start); }
(gdb)
No matter where I compile it I get the same error! When I check the values of all the variables within gdb everything is correct (values are exactly what they should be). The vector does work because I intialize it in main(), use it and then delete it and reallocate it (all without issue). Am I missing some big thing here? Googling and debugging for hours didn't seem to bring up anything. Any help is appreciated!
There's a lot here that can be simplified, but as far as major problems there is this:
int * counter =new int;
(*counter)=0;
counter++;
The counter++ is incrementing the pointer not the value pointed to. I don't see any reason why this needs to be a pointer and should probably be avoided as it just adds complexity to this.
What does isNext do? There definitely a lot you can do to simply this and when that's done it will likely reduce problems.
What are you passing to split? If the vector is uninitialized the call to ->clear() could cause an access violation.
EDIT: Well...that's very interesting. I made settings into a pointer and passed that. Worked beautifully. So, this is solved. I'll leave it open for anyone curious to the answer.
I'm having an issue creating a sound in FMod from a memory stream. I looked at the loadfrommemory example shipped with FMod and followed that. First, the code I'm using...
CSFX::CSFX(CFileData *fileData)
{
FMOD_RESULT result;
FMOD_CREATESOUNDEXINFO settings;
settings.cbsize = sizeof(FMOD_CREATESOUNDEXINFO);
settings.length = fileData->getSize();
_Sound = 0;
std::string temp = "";
for (int i = 0; i < fileData->getSize(); i++)
temp += fileData->getData()[i];
result = tempSys->createSound(temp.c_str(), FMOD_SOFTWARE | FMOD_OPENMEMORY, &settings, &_Sound);
}
As it is like this, I get an access violation on tempSys->createSound(). I've confirmed that tempSys is valid as it works when creating sounds from a file. I've also confirmed the char * with my data is valid by writing the contents to a file, which I was then able to open in Media Player. I have a feeling there's a problem with settings. If I change that parameter to 0, the program doesn't blow up and I end up with result = FMOD_ERR_INVALID_HANDLE (which makes sense considering the 3rd parameter is 0). Any idea what I'm doing wrong?
Also, please disregard the use of std::string, I was using it for some testing purposes.
Solved by turning settings into a pointer. See code below:
CSFX::CSFX(CFileData *fileData)
{
FMOD_RESULT result;
FMOD_CREATESOUNDEXINFO * settings;
_Sound = 0;
std::string temp = "";
for (int i = 0; i < fileData->getSize(); i++)
temp += fileData->getData()[i];
settings = new FMOD_CREATESOUNDEXINFO();
settings->cbsize = sizeof(FMOD_CREATESOUNDEXINFO);
settings->length = fileData->getSize();
result = tempSys->createSound(temp.c_str(), FMOD_SOFTWARE | FMOD_OPENMEMORY, settings, &_Sound);
delete settings;
settings = 0;
}
You need to memset settings before using it.
memset(&settings, 0, sizeof(FMOD_CREATESOUNDEXINFO);
Otherwise it will contain garbage and potentially crash.