Help needed

Hi,

The reason for the following valgrind-detected issue eludes
me. It seems that 
the expression visitor uses a URL which has also been used
by the 
ClassBrowser, but I don't see how/why it's been freed... any
ideas?

==17036== Thread 3:
==17036== Invalid read of size 1
==17036==    at 0x4EEEFB7: _char(char**, char, ErrorInfo*)
(qurl.cpp:284)
==17036==    by 0x4EEF09C: _pctEncoded(char**, char*,
ErrorInfo*) 
(qurl.cpp:311)
==17036==    by 0x4EF15DC: _regName(char**, QByteArray*,
ErrorInfo*) 
(qurl.cpp:746)
==17036==    by 0x4EF3842: _host(char**, QByteArray*,
ErrorInfo*) 
(qurl.cpp:760)
==17036==    by 0x4EF38D6: _authority(char**, QByteArray*,
QByteArray*, int*, 
ErrorInfo*) (qurl.cpp:822)
==17036==    by 0x4EF3A2C: _hierPart(char**, QByteArray*,
QByteArray*, int*, 
QByteArray*, ErrorInfo*) (qurl.c
pp:1018)
==17036==    by 0x4EF4AEB:
QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
(qurl.cpp:3363)
==17036==    by 0x4EF863F: QUrlPrivate::validate() const
(qurl.cpp:3304)
==17036==    by 0x4EF8987: QUrl::isValid() const
(qurl.cpp:3657)
==17036==    by 0x62B6FB8: KUrl::equals(KUrl const&, 
QFlags<KUrl::EqualsOption> const&) const
(kurl.cpp:517)
==17036==    by 0x2097384A:
Cpp::ExpressionVisitor::visitName(NameAST*) 
(expressionvisitor.cpp:467)
==17036==    by 0x20DE375D: Visitor::visit(AST*)
(visitor.cpp:109)
==17036==  Address 0x279ED007 is 31 bytes inside a block of
size 128 free'd
==17036==    at 0x4C2182B: free (vg_replace_malloc.c:233)
==17036==    by 0x4E72B30: qFree(void*) (qglobal.cpp:1967)
==17036==    by 0x4E7D56E: QByteArray::operator=(QByteArray
const&) 
(qbytearray.cpp:811)
==17036==    by 0x4EF8622: QUrlPrivate::validate() const
(qurl.cpp:3303)
==17036==    by 0x4EF8987: QUrl::isValid() const
(qurl.cpp:3657)
==17036==    by 0x62B6FB8: KUrl::equals(KUrl const&, 
QFlags<KUrl::EqualsOption> const&) const
(kurl.cpp:517)
==17036==    by 0x62B73D9: KUrl::isParentOf(KUrl const&)
const (kurl.cpp:1693)
==17036==    by 0x66452D2:
KDevelop::Project::fileForUrl(KUrl const&) const 
(project.cpp:339)
==17036==    by 0x6644A13: KDevelop::Project::inProject(KUrl
const&) const 
(project.cpp:303)
==17036==    by 0x663E8D5:
KDevelop::ProjectController::findProjectForUrl(KUrl 
const&) const (projectcontroll
er.cpp:483)
==17036==    by 0x164ABE90:
ClassModel::filterObject(KDevelop:UChainBa
se*) 
const (classmodel.cpp:114)
==17036==    by 0x164AC9FF:
ClassModel::contextAdded(ClassModel::Node*, 
KDevelop:UContext
*) (classmodel.cpp
:386)

Cheers,
Hamish

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> Hi,
>
> The reason for the following valgrind-detected issue
eludes
> me. It seems that
> the expression visitor uses a URL which has also been
used by the
> ClassBrowser, but I don't see how/why it's been
freed... any ideas?

Problem 1: QUrlPrivate::validate claims to be const, but
it's not (seems to be common in Qt code).  It modifies the
member "encodedOriginal" by setting it equal to
another QByteArray (see implementation of
QByteArray::operator=(const QByteArray&) - this is were
the free is happening).

Problem 2: QUrlPrivate seems to be working with the internal
data of "encodedOriginal".  If this data changes
on one thread while another thread is working with the data
- boom.

The call to "free" is not the problem.  Is this
valgrind output supposed to be some sort of stack trace, or
is it another type of output?

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Fri, 9 Nov 2007 12:58:01 am Kris Wong wrote:
> > Hi,
> >
> > The reason for the following valgrind-detected
issue eludes
> > me. It seems that
> > the expression visitor uses a URL which has also
been used by the
> > ClassBrowser, but I don't see how/why it's been
freed... any ideas?
>
> Problem 1: QUrlPrivate::validate claims to be const,
but it's not (seems to
> be common in Qt code).  It modifies the member
"encodedOriginal" by setting
> it equal to another QByteArray (see implementation of
> QByteArray::operator=(const QByteArray&) - this is
were the free is
> happening).
>
> Problem 2: QUrlPrivate seems to be working with the
internal data of
> "encodedOriginal".  If this data changes on
one thread while another thread
> is working with the data - boom.
>
> The call to "free" is not the problem.  Is
this valgrind output supposed to
> be some sort of stack trace, or is it another type of
output?

Yes, it's a stack trace of an invalid read, and where the
data was free'd.

It seems that the problem is QUrl is only reentrant, not
thread-safe.  So, 
even though we have a lock, it doesn't prevent multiple
reads, and the const 
function fiddles with the object -> boom, as you said.

So, we need to guard our access to QUrls - bother.

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel