[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-bugs
Subject:    [Bug 208750] Abort signaled from context browser
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2009-09-29 7:35:37
Message-ID: 20090929073537.0329221F18 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=208750


Andreas Pakulat <apaku@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.nolden.kde@art-master
                   |                            |.de
          Component|general                     |util
            Product|kdevelop                    |kdevplatform




--- Comment #3 from Andreas Pakulat <apaku gmx de>  2009-09-29 09:35:32 ---
(In reply to comment #2)
> Crash reproduced with MALLOC_CHECK_=0.
> Although this time it manifests itself as a segfault since malloc-check isn't
> catching it and aborting, but the trace is essentially the same.

Its not the same, its a lot more helpful as now we know its the same problem as
in other cases.

> I would be
> inclined to think that anything that gets dug up by the check is a bug anyway,

From the backtraces I've seen so far it rather seems that the new checks in
glibc2.10 are overly strict. There are backtraces reaching deep into Qt code
and while they might even point to potential problems, so far I've never seen a
crash with such backtrace that was still reproduceable after setting
MALLOC_CHECK_.

> the check just catches invalid memory operations before they escalate into
> something worse, does it not? I don't think the solution is to disable
> something that is being strict about correct program operation in an attempt to
> sweep a bug under the rug (scuse the expression).

Its not about sweeping a bug under the rug, as I said this is the first time
where malloc_check really was right and its also the first time we might be
able to do something about it. All other instances of this reported here have
been deep in Qt code, which we won't track here.

> Application: KDevelop (kdevelop), signal: Segmentation fault
> [KCrash Handler]
> #5  0x00007f7ba065e251 in free () from /lib/libc.so.6
> #6  0x00007f7b9ed12fd0 in ~KDevVarLengthArray (this=<value optimized out>,
> __in_chrg=<value optimized out>) at
> /usr/src/kdevplatform/util/kdevvarlengtharray.h:120

Hmm, looking at the code, this is partly a copy of QVarLengthArray, in
particular the destructor. I'll ask the author why we have a copy of that code
instead of using the Qt version.

Also I can't see anything wrong in the code, if ptr is allocated using qMalloc
its also qFree'd. If its just assigned to the tip of the statically-allocated
array then its not qFree'd.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

_______________________________________________
KDevelop-bugs mailing list
KDevelop-bugs@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-bugs
[prev in list] [next in list] [prev in thread] [next in thread]