Possible thread-safety issue in cmakemanager ?

Sandro Andrade sandro.andrade at gmail.com
Thu Apr 22 17:11:48 UTC 2010


Hi all,

Any hint about how to solve this issue ?

Apparently, background parser tries to access KConfig:

extragear/sdk/kdevplatform/language/backgroundparser/backgroundparser.cpp:247:
KConfigGroup config(KGlobal::config(), "Background Parser");

while controlflowgraph plugin could also (indirectly, via
cmakemanager) attempt to access KConfig.
Any possible solution besides disable graph generation while parser is running ?

TIA,
Sandro

On Mon, Apr 19, 2010 at 11:02 AM, Sandro Andrade
<sandro.andrade at gmail.com> wrote:
> On Mon, Apr 19, 2010 at 3:44 AM, Andreas Pakulat <apaku at gmx.de> wrote:
>>
>> On 18.04.10 23:58:54, Sandro Andrade wrote:
>> > I was running some problems in controlflowgraph plugin regarding
>> > cmakeutils
>> > and kconfig thread-safety stuff. Basically when I had
>> >
>> > multiple threads generating graphs occasionally I got the crash display
>> > below. After including a QMutex in duchaincontrolflow.cpp:500 crashes
>> > were
>> > solved, multiple graph generation threads can now live together.
>> > However,
>> > the same crash (and backtrace) is occasionally produced when generating
>> > a
>> > lot of graphs while background parsing is running.
>> >
>> >
>> > Apparently some thread from background parser or cmakemanager stuff
>> > running
>> > along with controlflowgraph thread is causing
>> >
>> > the creash. IIRC, that would be a case for the foreground lock but,
>> > while it
>> > isn't already fully usable, how should I address this issue by now ? I
>> > wouldn't like to disable graph generation while parser is running since
>> > that
>> > might make graphs unavailable for a long time.
>>
>> You're not by any chance running libc 2.10.0 or 2.10.1? It had a bug in
>> its malloc_printerr implementation causing race conditions which would
>> result in such backtraces.
>
> Hi Andreas, I'm currently using glibc 2.11.1.
>
> Sandro
>
>>
>> If thats not the problem it would be interesting to see where the other
>> threads are, i.e. if the problem is that two threads access kconfig or
>> kstandarddirs or inside the cmake support...
>>
>> Andreas
>>
>> --
>> You will be recognized and honored as a community leader.
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>




More information about the KDevelop-devel mailing list