[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic