kdevelop crashes after consuming only 200M memory

[Patrick Spendrin]

Am 15.06.2012 11:00, schrieb Andreas Pakulat:
> Hi,
> 
> On Wed, Jun 13, 2012 at 6:01 PM, Ralf Habacker
> <ralf.habacker at googlemail.com <mailto:ralf.habacker at googlemail.com>> wrote:
> 
>     Am 13.06.2012 13:49, schrieb Andreas Pakulat:
> 
>         Hi,
> 
>         I've started to build and try to use kdevelop on windows.
>         Unfortunately it crashes soon after having opened my project or
>         upon startup. The backtrace suggests a QVector::reserve() call
>         in the C++ parser, which in turn hints towards exhausting of
>         memory (it throws a qBadAlloc exception).
> 
>         However according to my process-monitor I still have plenty of
>         standby memory available (free is indeed only about 200M). Since
>         I'm not an expert in this stuff, does anybody know of a possible
>         reason why the memory-allocation would fail even if there's tons
>         of standby-memory?
> 
>     One reason may be heap memory corruption.
> 
> 
> Can you elaborate on that? I couldn't really find anything
> understandable via google on limits in windows regarding heap memory -
> other than I should be able to have apps use up to 2G of it on a 4G RAM
> system.
> 
> It almost seems as if windows is unwilling or unable to provide the
> process memory from the standby area, however other processes don't have
> that problem (I can run eclipse just fine for weeks and it'll consume
> quite a bit more than 200M over the time).
> 
> Any pointers to understandable documentation of what a normal C++
> programmer needs to know about memory usage of its app on windows would
> be appreciated.

I doubt that this is a memory issue in itself given that kdevelop works
over here.
It is much more likely that this comes from other error sources:
- mixing release and debug runtimes: you can't run cmake
-DCMAKE_BUILD_TYPE=Debug against the KDE stack (thats the point we have
emerge for). You must use RelWithDebInfo.

- different dlls in the path that are used instead of the KDE dlls:
make sure that C:\KDE is always first in the path, check with the
dependencywalker that dlls all come from C:\kde\bin. KDE itself normally
works without setting the path simply because the local path is the
first Windows looks into for dlls. This will break if you have other
programs in the path that provide the same dlls we use.

- maybe: mixing different ways how strings are handled, e.g. -Zwchar_t-
(that is normally hard coded in KDE code, but I am not sure this is
really the case)
- forgetting to run post install steps, update-mime-database (already
done by the installer) and kbuildsycoca4 (after each update of plugins).

I hope this helps.
regards,
Patrick