ReferenceCountManager::dereference accesses uninitialized memory

[David Nolden]

Am Samstag 02 Mai 2009 14:01:24 schrieb Peter Oberndorfer:
> On Freitag 01 Mai 2009, Peter Oberndorfer wrote:
> > Hi,
> >
> > i updated kdevelop sometimes see the Q_ASSERT(ref) in
> > ReferenceCountManager::dereference fire. For debugging i ran kdevelop
> > under valgrind, which reported the trace attached.
> >
> > In the example i added debugging output, which shows a reference count of
> > 1528522103, which is a bit high IMO.
> > Addrefing such a high invalid value does not result in a immediate
> > obvious crash, but dereferencing a value of 0 causes the assert.
> >
> > This happens also when removing .kdevduchain and then starting KDevelop.
> > Kdevelop loads some files from the last session and during parsing of
> > them the error is reported by valgrind.
> >
> > Greetings Peter
>
> Ok i came up with another valgrind backtrace (attached).
> And a workaround for the problem, which is sureley the wrong solution
> but allows me to use kdevelop.
>
> I guess the problem is that
> emptyConstantIdentifierPrivateIndex() allocates a index in the repository,
> but never initializes the memory fo this index?
> At least i do not know where...
>
> Greetings Peter

Do you automatically load multiple projects on kdevelop startup? If yes, try 
disabling that.

Also, please uncomment the #define at referencecounting.h:28, recompile 
kdevelop, and see if you have a more useful assertion.

Your fix does not work, it can only hide the problem in valgrind.

The memory for an index in the repository is allocated in the moment the index 
is acquired if a fitting index doesn't exist yet, by the request object given 
to the index() function. This hints that there are some bogus indices 
involved, that point to not yet initialized memory, and thus were not acquired 
correctly through the index() function. The strange thing is that the indices 
are still valid in some way, since they point into an existing bucket.

Please also try removing all the open files from your session, and then 
loading them one-by-one.

Ah yeah, you did try wiping your build-directories and rebuilding kdevplatform 
and kdevelop completely, did you?

And please try finding out exactly which of these steps helped, if one helped, 
so we can maybe solve this problem cleanly.

Greetings, David