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?
Related
I am using VS 2022 Community Edition (v17.3.3) to build wxWidgets application (v3.2.0) using C++ (v14.3 - Features from Latest C++). The windows SDK is using the latest installed (10.0.22621). The project is also using C++ modules.
The Debug build succeeds but when I run the project's exe file at random it throws the exception (Access violation reading 0xFFFFFF (ucrtbased.dll)) in exe_common.inl at the following line:
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
After a few more compilations (by just making minor changes to trigger a compilation) it succeeds and the exe runs correctly.
I wonder if there is any settings that might be causing this random error. Btw, I am using Win11 but same thing happens on Win10 as well.
Thanks in advance.
EDIT 1:
The project is using boost libraries and at startup boost/json (boost/json is used in other parts of the project as well). Debugger shows that after the following line the above error happens:
static allocator_arg_t allocator_arg = BOOST_CONTAINER_DOC1ST(unspecified, *std_allocator_arg_holder<>::dummy);
There were a few things needed attention:
Discontinued use of wxSQLite (the library was not maintained for over a decade),
The main frame was a singleton data structure, not anymore, and not deriving from wxMDIFrame anymore.
All unnecessary (a chain of them) #include removed.
Inclusion of <boost/json.hpp> in a few files were removed and now using #include <boost/json/src.hpp> only in one .cpp file. However, the project still uses inclusion of <boost/json/value.hpp> in multiple .h files.
All uninitialized pointer variables and others were initialized.
#1 and #4 were especially pointed by the debugger. It has now been more than a few days and haven't had the problem since then.
Environment: Windows10, cpp17, visual studio 2019, debug version static library
Recently I tried to use Cesium-Native to read 3DTiles files in my project, but there was a confusing problem that some member variables are not initialized correctly.
As following codes show, Tileset() use initializer list to initialize its member variables, but some of them like_loadsInProgress,_previousFrameNumber are initialized to random value which shoule have been 0. However some of them are initialize correctly like _url, _options, and it works well in Release Library and the same code in its original project. What a strange bug!
Tileset::Tileset(
const TilesetExternals& externals,
const std::string& url,
const TilesetOptions& options)
: _externals(externals),
_asyncSystem(externals.asyncSystem),
_userCredit(
(options.credit && externals.pCreditSystem)
? std::optional<Credit>(externals.pCreditSystem->createCredit(
options.credit.value(),
options.showCreditsOnScreen))
: std::nullopt),
_url(url),
_isRefreshingIonToken(false),
_options(options),
_pRootTile(),
_previousFrameNumber(0),
_loadsInProgress(0),
_subtreeLoadsInProgress(0),
_overlays(*this),
_tileDataBytes(0),
_supportsRasterOverlays(false),
_gltfUpAxis(CesiumGeometry::Axis::Y),
_distancesStack(),
_nextDistancesVector(0) {
if (!url.empty()) {
CESIUM_TRACE_USE_TRACK_SET(this->_loadingSlots);
this->notifyTileStartLoading(nullptr);
LoadTilesetDotJson::start(*this, url).thenInMainThread([this]() {
this->notifyTileDoneLoading(nullptr);
});
}
}
Through debugging, I found that _loadsInProgress was 0 at first, and it changes when a vector construct function is called. Maybe it's because generation of debug static lib?
Any suggestions will be appreciated!
The problem solved by carefully checking all setting in running correctly original project and my project. And try to clean Visual Studio Cache and rebuild project and lib may be helpful for the problem.
At first I used the different library version for inlucde and lib files, then I found that, I change the same version library include files to my project. But due to VS cache and the same file name(I guess), the change failed to apply to my project actually.
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.
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 am getting run time crash in the following piece of code and not able to debug also. Please review and let me know what's going on.
// CppConsole.cpp : Defines the entry point for the console application.
//#include "stdafx.h"#include <iostream>#include <assert.h>
class Test : public std::tr1::enable_shared_from_this<Test>
{
public:
Test():x(0),y(0),z(0){};
int x;
float y;
double z;
};
int _tmain(int argc, _TCHAR* argv[])
{
std::tr1::shared_ptr<Test> t1(new Test);
std::tr1::shared_ptr<Test> t2 = t1->shared_from_this();
return 0;
}
I have include all the headers and the program is compiling fine. This is the error i am getting:
CppConsole.exe - Entry Point Not Found The procedure entry point
?_Xweak#tr1#std##YAXXZ could not be located in the dynamic link
library MSVCP90D.dll
If I comment out this line
std::tr1::shared_ptr t2 = t1->shared_from_this();
the program runs without crashing.
Update: Question can be closed for now. I will try to install VS feature pack and see weather the program executes without any crashes.
Googled it (The procedure entry point ?_Xweak),found this : http://blog.nilretain.org/
EDIT : I Build and Run it successfully on my msvc 2008 on xp-sp3 ,which has later version of msvcp90d.dll.
Maybe you can download and install the latest redist-version of msvc90 and rebuild.
EDIT: your dependencies says something is missing. check this out :
http://answers.yahoo.com/question/index?qid=20090623140325AAInugo
You need a template argument:
std::tr1::shared_ptr<Test> t1(new Test);
std::tr1::shared_ptr<Test> t2 = t1->shared_from_this();
The compiler should report an error if it is not present. (Visual C++ 2010 does)
It appears that your compiler is not linking against a DLL with the needed runtime functions. For instance, if you added the headers to your include path, but don't link to the latest version of the C++ runtime (check your project's settings), or installing the Visual C++ 2008 feature pack didn't work, or you installed the feature pack but then tried to compile from Visual Studio 2005, etc.
Basically the "process the source code (including headers)" step is working fine, but the "link all the DLLs" step is failing. And it's failing because the runtime you're linking against doesn't have the needed functions for shared_ptrs or weak_ptrs.
I had this problem when developing under M$ Windows SP3 with M$ Visual Studio 2008. I tried and combined many hints that I could find on the web. To no avail. The solution was simple, I had to install SP1 pack for M$ Visual Studio 2008!
The thing is that my external DLLs used C++ TR1 functions that I was not aware of. The M$ Visual Studio 2008 without SP does not have the right runtime DLLs.
So, just make sure you have that SP1 for your M$ Visual Studio 2008 first before trying any other solution.