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

List:       kde-bugs-dist
Subject:    [Bug 243234] ptrcheck doesnt handle sscanf properly
From:       Julian Seward <jseward () acm ! org>
Date:       2010-06-30 10:29:44
Message-ID: 20100630102944.1E56047BA4 () immanuel ! kde ! org
[Download RAW message or body]

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





--- Comment #4 from Julian Seward <jseward acm org>  2010-06-30 12:29:41 ---
(In reply to comment #2)
> I have not really looked at the sscanf implementation (and my doctor says I
> should not as it won't be good for my heart), but if the pointer jumps from one
> arg to the other, shouldn't ptrcheck somehow get that it has been
> re-initialized from a new input parameter then?

The problem is ..

The basic assumption is: if a memory referencing insn accesses a stack
or global array, then it will continue to access that same array until
the containing stack frame exits.  See

http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks

So .. how, in this case, can it know that the insn which copies data
into %s destinations is switching between destination arrays?  I don't
see a way to do this.


> Now that I think of it, the almost 100 suppressions that I wrote for our
> software seem to be of a similar kind. We have a ptr variable that is always
> re-used for pointing to an element determine within the looping.

Yes.  See bullet point 5 of
http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations


> It would really be nice if there could be a fix for this since it is a really
> tedious thing to always write suppressions, since for every new case you have
> to determine whether it is not maybe a bug, and

Maybe it could be improved with better heuristics, but I couldn't
think of any during development.  If you have any ideas ...


> with our old legacy code here
> we find quite some bugs with ptrcheck that no other tool shows us...

Wow.  This is the first time I heard that Ptrcheck finds real bugs.
That's great.

Are these from the stack/global array checking only?  I have
(uncommitted) a cut-down version which just does stack/global checks,
and omits the heap checks, since Memcheck does those faster.

In fact, looking at the stack/global array checking code, I think I
did a pretty stupid implementation.  It could be redone to be much
faster, but until now I never put much effort into improving it
because I assumed the tool as a whole is not very useful (didn't find
many bugs in the testing I did.)

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]