Version: trunk (using KDE 4.2.4) Compiler: msvc 9.0 KDE was emerge-d and compiled in Debug. KDevelop & KDevplatform were svn-ed from trunk and compiled in Debug. OS: MS Windows Installed from: Compiled From Sources I emerge-d KDE 4.2 and compiled it with CMAKE_BUILD_TYPE=Debug. I svn-ed KDevelop & KDevplatform from trunk and compiled (in Debug as well). In order to compile it I had to change DUChainRef's first virtual functions into pure virtual (otherwise you would get unresolved external errors from the linker). When you run it in the debugger, you get "The application failed to initialize properly" twice. If you click on "Continue" it will then crash with "Access Violation". I suspect the problem might start in KDevplatform since the former messages happen before even reaching KDevelop's main. It's worth mentioning that I tried running other applications (kate.exe, systemsettings.exe) and they all ran perfectly well. Everything was compiled with MSVC 9.0 Express Edition.
Sounds like the initialization in kdevplatform is broken, those virtual could be related. Instead of making them pure virtuals, provide empty implementations. Without a backtrace its pretty much useless though until I get time to try it out myself.
I tried changing to implementation that return NULL (you have to return a value, but setting breakpoints show that this code is never reached) and unfortunately it didn't help. The first two error messages occur somewhere after initializing the global identifier (in kdevplatform\language\duchain\ducontext.cpp). Here's the stach at the crash after the first two error messages: > QtCored4.dll!QMetaObject::indexOfSignal(const char *signal=0x02a5b2f1) Line 581 + 0xf bytes C++ QtCored4.dll!QObject::connect(const QObject * sender=0x03f0b468, const char * signal=0x02a5b2f1, const QObject * receiver=0x05760e20, const char * method=0x02a5b358, Qt::ConnectionType type=AutoConnection) Line 2475 + 0xc bytes C++ kdevplatformshell.dll!KDevelop::WorkingSetController::initializeController(KDevelop::UiController * controller=0x03f0b468) Line 259 + 0x42 bytes C++ kdevplatformshell.dll!KDevelop::UiControllerPrivate::UiControllerPrivate(KDevelop::UiController * controller=0x03f0b468) Line 63 C++ kdevplatformshell.dll!KDevelop::UiController::UiController(KDevelop::Core * core=0x0575dc78) Line 178 + 0xab bytes C++ kdevplatformshell.dll!KDevelop::CorePrivate::initialize(KDevelop::Core::Setup mode=Default) Line 101 + 0x29 bytes C++ kdevplatformshell.dll!KDevelop::Core::initialize(KDevelop::Core::Setup mode=Default) Line 218 C++ kdevelop.exe!main(int argc=1, char * * argv=0x03e79fe0) Line 136 + 0xa bytes C++ kdevelop.exe!WinMain(HINSTANCE__ * instance=0x00400000, HINSTANCE__ * prevInstance=0x00000000, char * __formal=0x00051f10, int cmdShow=1) Line 136 + 0x12 bytes C++ kdevelop.exe!__tmainCRTStartup() Line 578 + 0x35 bytes C kdevelop.exe!WinMainCRTStartup() Line 403 C kernel32.dll!7c817077() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
hmm, this looks like there might actually be a problem with using KDE4.2 with kdevelop. I suggest to try KDE4.3 instead, I won't have KDE4.2 available before next week.
I also tried it with KDE 4.3 and the same scenario happens.
I can reproduce a crash on startup, it seems to happen during initialization of the language library which loads the duchain repository. Not sure yet what changed in that area since June 1st (thats when I last test kdev4/win32).
One reason seems to be the order of initialization of global variables: instantiationInformationRepository (line 116 in kdevplatform/language/duchain/instantiationinformation.cpp) calls typeRepositoryManager() which in turn returns a pointer to typeRepository (line 85 in kdevplatform/language/duchain/repositories/typrepository.cpp) which hasn't been initialized. Immediately after this pointer is being used in RepositoryManager::createRepository() but as noted, it hasn't been initialized.
Adding David as Yaron just told me on IRC he got it working and will post a clean patch later on.
I've just applied and comitted the patches from Yaron, unfortunately KDevelop still crashes on startup when loading kdevplatformlanguage, so it seems there's still a problem with the order of initialization of global objects somewhere.