kdevelop crashes after consuming only 200M memory

[Andreas Pakulat]

Hi,

On Fri, Jun 15, 2012 at 11:17 AM, Patrick Spendrin <ps_ml at gmx.de> wrote:

> 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.
>

You're also using binary packages from kdewin-installer? Or emerge?


> 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.
>

Yeap, all build with RelWithDebInfo here.


> - 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.
>

C:\KDE\bin and C:\KDE\local\kdevelop\bin are first in PATH, I do have Git
and its unix-tools in PATH but nothing else that would be originating from
a unix background.


> - 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)
>

Check, nothing like that in KDevelops buildsystems


> - forgetting to run post install steps, update-mime-database (already
> done by the installer) and kbuildsycoca4 (after each update of plugins).
>

KDevelop runs kbuildsycoca4 itself, but also no change after running it
manually.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20120615/b44d6125/attachment.html>