I have the following program to read a file that exists:
const char *path = "C:\\Users\\myname\\AppData\\Roaming\\Technology\\plus\\fs\\D\\TECH\\CUSTOM\\LOG.XML";
struct _stat lInfo;
int err = _stat(path, &lInfo);
if (err == 0) {
return (lInfo.st_mode & _S_IFDIR) != 0;
} else {
_get_errno(&err);
printf("Error: %d\n", err);
}
On this particular file I am getting err == 132 where _stat, according to the documentation, can only return ENOENT (2) and EINVAL (22). Error code 132 is EOVERFLOW. If I copy the file exactly and rename it LOG2.xml and replace this line accordingly:
const char *path = "C:\\Users\\myname\\AppData\\Roaming\\Technology\\plus\\fs\\D\\TECH\\CUSTOM\\LOG2.XML";
Then everything works just fine. (ie. errno is 0 and i get the file information). If I just rename the original file (From LOG.XML to LOG2.XML) then i get the same error which leads me to believe its a permissions or ownership problem.
What could be the cause of this error?
I encountered this exact problem while upgrading from Visual Studio 2010 SP1Rel to Visual Studio 2015 Update 2. My file has a modified date of Sunday, May 13, 1601, 5:53:31 PM, and it appears stat no longer works with dates before 1970.
Debugging through the vc14 ucrt, I believe the following lines of code are relevant:
corecrt_internal_time.h
#define _BASE_YEAR 70 // The epoch year (1970)
loctotime.cpp:common_loctotime_t()
yr -= 1900;
_VALIDATE_RETURN_NOEXC(yr >= _BASE_YEAR && yr <= time_traits::max_year, EINVAL, invalid_time)
Running touch on the file fixed the issue.
On the one hand, it does seem pretty unreasonable to have file timestamps that predate 1970, but on the other hand it is possible to do (artificially) and somehow it occasionally happens by accident. Feels like a regression in Visual Studio.
The link where you looked for the error actually contains the Windows API error codes, which are not the same as the C standard library's.
The header you need is <errno.h> which shows that 132 corresponds to EOVERFLOW.
VS includes the source code of the C runtime library (in a path like C:\Program Files (x86)\Microsoft Visual Studio VERSIONID\VC\crt\src), so you should step into it with the debugger to find out what's going on in your case.
A quick look on the CRT source code in my VS version suggests that can happen when a file size is too big to be represented in a 32 bit integer. From what you describe, I'm not sure that might your problem (unless the original path is something special, symbolic link, ...?) but you should try your debugger.
Related
we've been using RocksDB for years, building from source on Windows through Visual Studio and stuff.
Today, I felt lazy and thought to myself, hey, there's VCPKG right..haven't updated RocksDB for like a year or so..
After getting my VCPKG to work with Visual Studio 2022 which was sort of an unexpected pain in the ass, building RocksDB was a walk in the park (of course).
I was handed with debug and release builds almost right away. Great right?
So I deleted all the internal RocksDB-related headers, copied over the VCPKG-baked static lib and... crash. Tried both debug and release mode. Here's the call stack:
> Rocksdb::Comparator::timestamp_size() Line 110 C++
rocksdb::InternalKeyComparator::InternalKeyComparator(const rocksdb::Comparator * c, bool named) Line 242 C++
rocksdb::ImmutableCFOptions::ImmutableCFOptions(const rocksdb::ColumnFamilyOptions & cf_options) Line 835 C++
rocksdb::ImmutableCFOptions::ImmutableCFOptions() Line 829 C++
rocksdb::`dynamic initializer for 'dummy_cf_options''() Line 43 C++
It crashed at the library loading stage, control is not even passed to my main() yet.
It basically calls InternalKeyOperator on NULLPTR
right over here
explicit InternalKeyComparator(const Comparator* c, bool named = true)
: Comparator(c->timestamp_size()), user_comparator_(c) {
if (named) {
name_ = "rocksdb.InternalKeyComparator:" +
std::string(user_comparator_.Name());
}
}
above 'c' is nullptr.
Ideas?
I have C++ code in a project which behaves differently with Visual Studio 2010 and VS 2015.
if(return_val != 0)
{
ACE_OS::set_errno_to_last_error ();
result->set_error(errno);
}
return_val is the the return value of a prior function which has failed. So the next step is to capture error value.
In VS 2010
When result->set_error(errno) is called, while debugging, the control goes to the function _errno() , defined in source \VC\crt\src\dosmap.c.
In VS 2015
The source dosmap.c is not found.
The macro expansion for errno must be in a different place I suppose. But the behaviour should be same
Do I need to make any change in the VS settings for 2015?
Any help would be useful.
I think you have not installed the source files for the library. This would explain why it can't find the file.
errno is a strange variable, and is thread-local, and macro'ed in both platforms. What is happening in ACE_OS::set_errno_to_last_error ();?
If the function is not setting the errno value, that would explain the behavior differences.
I am trying to build a DLL from source-code from the Crysis Wars SDK, and have successfully done so in the past on previous versions of Visual Studio (namely 2005, 2008, and 2010).
My specific problem is this:
Error 4 error LNK2019: unresolved external symbol "struct CTypeInfo const & __cdecl
TypeInfo<char>(char *)" (??$TypeInfo#D##YAABUCTypeInfo##PAD#Z) referenced in function
"void __cdecl SwapEndian<char>(char *,unsigned int)" (??$SwapEndian#D##YAXPADI#Z)
G:\Noctis\Mods\Noctis\Code\GameCVars.obj GameDll
I have attempted to clean the code in Visual Studio and rebuild it on the off-chance this'll work, but this has not changed anything.
Am I missing something here, or has something changed from C++03 to C++11 that means that this code is no longer compilable without reverting to an older version of C++?
I have successfully compiled this code on Visual Studio 2010 in both 64 bit and 32 bit, so it must be some issue related to migrating the project to Visual Studio 2015.
Compilation on 2012, 2013, and 2015 versions of Visual Studio reproduce this error but not 2010, so it seems that the change to trigger this problem was introduced in C++11.
What am I doing wrong?
Reading the answer to mem-fun is not a member of std, it could just be that I need to include a standard library that I didn't need to include in earlier versions of Visual Studio.
If this is true, which library would I need to #include?
I have also created a GitHub repository containing only the original unmodified code provided from the SDK, for testing purposes (in the event I myself made a typo, which doesn't seem to be the case here but I've put the link here as it may be helpful).
If it matters, I'm using Visual Studio 2015 Enterprise edition on Windows 10 Professional x64.
What does the error mean?
The error message hints towards a classic "declared but not defined" scenario.
TypeInfo<char>(char*) is declared in TypeInfo.h (through some macros) and declared in AutoTypeInfo.cpp in project CryCommon.
Usually you would just make sure the CryCommon project is built correctly and linked into your final GameDll project properly and that's it.
But it turns out here that the CryCommon project has not been built for a long time - it references many other Crytek libraries etc. So the problem must be that something now needs these TypeInfo<> definitions and previously it did not.
What is referencing the TypeInfo<> code?
In your project it's function CmdHelp() in Aurora/Code/GameCVars.cpp, precisely this line:
nRead = gEnv->pCryPak->FRead( buf, BUFSZ, f );
The implementation of the FRead() method is in CryCommon/ICryPak.h:
template<class T>
size_t FRead(T *data, size_t elems, FILE *handle, bool bSwap = true)
{
size_t count = FReadRaw(data, sizeof(T), elems, handle);
if (bSwap)
SwapEndian(data, count);
return count;
}
As you can see, if bSwap is true (the default), SwapEndian() is invoked there.
Why hasn't this manifested before?
Perhaps the compiler was indeed behaving differently.
Or, more likely, you have been always compiling the project as Release before. The whole byte-swapping functionality is enabled only on big-endian systems (and your target is most probably not one of those) or during debug - then the bytes are actually swapped twice to test the related code (see CryCommon/Endian.h).
What can be done to fix it?
You have several options now:
Keep compiling as release only (probably as before). Perhaps you will never be debugging the code in a debugger anyway.
Just comment the swap call in FRead() code out. You are using it to load a text file anyway, no point in swapping the characters around.
...
FWIW, other things I had to do to make your code compile:
Check out the earlier commit before "Broken"
Load Mods\Aurora\Code\Aurora.sln
Remove non-existing .vcprojx projects
Add all 3 .vcproj files again, let them be converted to VS2015 ones
For GameDll project, add preprocessor definition _SILENCE_STDEXT_HASH_DEPRECATION_WARNING
For GameDll project, set enabled C++ exception handling /EHsc
Comment out the code above
I'm writing with visual c++ and when I compile this error occures:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): error MSB6006: "CL.exe" terminato con il codice 2.
Does anyone know why?
Thanks in advance!
You can actually see the proper error messages instead of Microsoft's arbitrary error codes. But since the error list is always forcibly made visible when there are errors, it isn't quite so obvious. Next to the tab Error List is another tab Output, which shows the raw error output. I'm not sure if that tab exists in all versions since I'm using 2019, but there might be something very similar in older versions anyways. Differently named perhaps, or an entirely separate window instead of grouped with Error List.
In the case of another answerer here that exact tab would've shown: error C4700: uninitialized local variable 'm' used
Which would have saved him from having to dig through all his code. =]
And if you forget a return value for a function that requires it, you'll see: error C4716: 'foo': must return a value
This happened me for a variety of different reasons:
1) I forgot to add a return statement to a non-void function.
2) I tried to use an uninitialized pointer.
3) I wrote a loop like for(int i=i;...) instead of for(int i=0;...)
You can check your code for these and it may help.
I got the same error when I forgot the return statement in the following method:
char SpiRAM::write_byte(int address, char data_byte)
{
assert(address >= 0);
assert(address < SRAM_SIZE);
_sram[address] = data_byte;
return data_byte;
}
I get this bug in v110 (Visual studio 2012)-Compiler with the following code, which contains a wrong for-based loop.
class A
{
int b;
};
int main(int argc, char* argv[])
{
A inst;
for (auto &i : inst)
{
}
return 0;
}
PS: v140 (Visual Studio 2015) shows the correct error:
error C3312: no callable 'begin' function found for type 'A'
error C3312: no callable 'end' function found for type 'A'
This error occured to me with C++ code with visual studio 2019 because I did not initialize my for-loop correctly.
I did:
for (int m; m < bytewidths + 1; m++) {}
rather than
for (int m=0; m < bytewidths + 1; m++) {}
I think that the way to fix this problem is to solve your recent code manually
Could also be an actually deleted header or source file, still listed in your project. Just check for such files.
I deleted a Header and Source file using the system explorer. VS apparently doesn't recognize the absence of deleted files and tries to compile them, till you reload your project.
Reloading the project worked for me.
Just wanted to add another case where this happens with Visual C++ 2019 (16.1.4):
...
char *s;
for(int i = 0; i < n; ++i)
{
if(i == 4) // we know n is going to be >= 4 but Visual C++ doesn't
s = getStringPointerFromSomewhere();
}
puts(s);
Visual C++ will print a message in the Output: potentially uninitialized local pointer variable 's' used, but crash instead of reporting it as a normal error or warning (arguably this should be a warning, since it's perfectly legal C code).
The solution for this one is to just assign s to NULL after declared:
char *s = NULL;
(So... just use the probably good habit of initializing pointers and other variables when declared I guess.)
I got this error because I had misspelled a filename when I save it.* Incidentally, this save was after having inserted a few for loops, which sent me on a wild goose chase because those can be a source of this error as well.
Sahbi's tip to look at the Output tab instead of just the general Error Code tab was very useful to me! I used the View menu to find and display the Output tab. It read the following:
1>------ Build started: Project: C867 Performative Assessment, Configuration: Debug x64 ------
1>Security_Student.cpp
1>c1xx: fatal error C1083: Cannot open source file: 'Security_Student.cpp': No such file or directory
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(429,5): error MSB6006: "CL.exe" exited with code 2.
1>Done building project "C867 Performative Assessment.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I had saved the file as 'Securtiy_Student.cpp'.*
I'd comment and upvote, but I don't have the rep yet.
*This wouldn't have been a problem if the correctly spelled file had not also been deleted, because the compiler would have just ignored the misspelled file and used the previous version that was spelled correctly. However, I'm also getting a weird bug with Visual Studio where it will occasionally decide that one of my files is new when I try to save it and must "Save as..." But, then when I accept that action, it says the file already exists, but if I try to replace it with the save, it says you can't replace it because it's being used. So, the solution has been to paste the file into a text file, decline to save the file in the Visual Studio solution, erase the solution file, create a new file, paste the text into it, and save into the solution again. Anyway, I will post this problem elsewhere, but I wanted to give context for a sneaky way one could get the error in this thread from a misspelled filename.
You should check your your source files; it's probable that the compiler can't find the source file maybe you typed the wrong name. eg writing #include <isotream> instead of #include <iostream> will cause the problem.
I threw the lodePNG sample files into a blank project in Visual C++ 2008 Express, along with a 7kb PNG file I made, but I'm getting this memory allocation error during runtime:
Invalid allocation size: 429967295 bytes.
After breaking on the error & backtracking through stack frames, I think it's being caused by a null argument being passed to the resize function in std::vector. This project was recently updated (April 2012), and is pretty thoroughly documented, so it's possible that I'm doing something wrong (or don't have the right compilation options). Would someone please take a look at my project?
Here's a ZIP file of the project folder: http://www.mediafire.com/file/791b9z9ld74n3eu/TestLodePNG.zip
You most likely have the png file in the wrong place. By default, the working directory is where the project file is, not where the solution file is when running in the debugger. When I moved the file to the project file directory it worked fine.
You might consider adding some error checking to the the file opening code, like this:
void load_file(std::vector<unsigned char>& buffer, const std::string& filename)
{
std::ifstream file(filename.c_str(), std::ios::in|std::ios::binary|std::ios::ate);
if(!file)
{
//Do something about the error and don't crash
}
...