Review request: control flow graph plugin

Andreas Pakulat apaku at gmx.de
Mon Nov 9 22:53:58 UTC 2009


On 09.11.09 21:47:49, Esben Mose Hansen wrote:
> On Monday 09 November 2009 16:15:41 Andreas Pakulat wrote:
> > Right, you can't fix that only Sandro can.
> 
> On the other hand, we just need a license and an OK from him, no? 

IANAL and everything, but yes. If he said changing it to either LGPL or
GPL in an earlier mail is ok with him, then we can fix the license text.
We could even fix it if it would be clear which license he meant, but as
it is right now thats not the case (IIRC). Right now half of the files
are mixing both licenses and half are ok....
 
> > > The code is unstable, though, with some memory corruption. Stil working
> > > on this. From valgrind, I suspect that this is the problematic code:
> > >
> > > QString DUChainControlFlow::globalNamespaceOrFolderNames(Declaration
> > > *declaration)
> > > {
> > >     IBuildSystemManager *buildSystemManager;
> > >     if (m_useFolderName && m_currentProject && (buildSystemManager =
> > > m_currentProject->buildSystemManager()))
> > >     {
> > >         if (KDevelop::ProjectBaseItem *project_item = m_currentProject-
> > >
> > > >projectItem())
> > >
> > >         {
> > >             KUrl::List list = buildSystemManager->includeDirectories(
> > > project_item );
> > >             int minLength = std::numeric_limits<int>::max();
> > 
> > Where is m_currentProject coming from? I guess this is somehow calculated
> > based on the currently open file? If m_currentProject is always a proper
> > project reference (one needs to monitor the signals from the project
> > controller!) then the code shouldn't crash.
> 
> See, this is interesting. Whenever the cursor is moved, the current project is 
> determined  (l.188)
> 
>     m_currentProject = ICore::self()->projectController()-
> >findProjectForUrl(view->document()->url());
> 
> and then this and several other member variables are used in another thread, 
> run via. ThreadWeaver..

Is there a mutex/lock in the code that protects the above assignment and
the usage in the separate threads? If not that might be the reason, no
code besides stuff in duchain is thread-safe in kdevelop. So it could
very well be that the above assignment isn't done yet while another
thread tries to access the variable.

Andreas

-- 
Your lucky color has faded.




More information about the KDevelop-devel mailing list