|
From: Oliver G. <ol...@gm...> - 2007-12-12 21:34:14
Attachments:
invalid_ref.C
|
Hello, attached is a C++ example where an int reference is used which points to freed memory. When starting that program with parameter "x", it will access this (invalid) reference, and Valgrind will show an "Invalid read of size 4" error. However, when starting the program without any parameter, the reference will not be accessed - yet the actual error is still there, waiting for some poor fool like me who starts the program with that tiny little parameter that triggers the error :-( I'm wondering if there's a way to find this invalid reference with Valgrind. Even though it is not dereferenced, it still silently points to an invalid memory location, and it might be used some day. Do you know if there is a way to detect this? Thanks, Oliver Gerlich |
|
From: Ivan S. <isj...@i1...> - 2007-12-13 08:07:33
|
On Wednesday 12 December 2007 22:07:26 Oliver Gerlich wrote: > ... However, when starting the program without any > parameter, the reference will not be accessed - yet the actual error is > still there ... No, valgrind cannot do that. Valgrind is a dynamic analysis tool that can only detect accesses that happen. At the other end of the scale we have static analysis tools that can detect accesses that potentially can happen. Dynamic analysis can only show actually errors and not potential errors. Dynamic analysis can show potential errors but will generate false positives. Regards, Ivan |
|
From: Paul F. <pa...@fr...> - 2007-12-13 09:18:46
|
Quoting Oliver Gerlich <ol...@gm...>: > Hello, > > attached is a C++ example where an int reference is used which points to > freed memory. When starting that program with parameter "x", it will > access this (invalid) reference, and Valgrind will show an "Invalid read > of size 4" error. However, when starting the program without any > parameter, the reference will not be accessed - yet the actual error is > still there, waiting for some poor fool like me who starts the > program with that tiny little parameter that triggers the error :-( > > I'm wondering if there's a way to find this invalid reference with > Valgrind. Even though it is not dereferenced, it still silently points > to an invalid memory location, and it might be used some day. Do you > know if there is a way to detect this? Hi This sort of problem is in the domain of static analysis tools (for instance, Coverity and Klocwork, I don't know of any free ones), rather than dynamic analysis. If you want your dynamic analysis tool (Valgrind) to detect this kind of error, then you need to generate inputs that drive all code paths and conditions. Unit test harnesses can help with this (my experience with functional tests is that it's hard to get much over 50% coverage, let alone decent condition coverage). A+ Paul |
|
From: Robert C. <r.c...@gs...> - 2007-12-13 11:12:01
|
Paul Floyd wrote: > Quoting Oliver Gerlich <ol...@gm...>: > >> Hello, >> >> attached is a C++ example where an int reference is used which points to >> freed memory. When starting that program with parameter "x", it will >> access this (invalid) reference, and Valgrind will show an "Invalid read >> of size 4" error. However, when starting the program without any >> parameter, the reference will not be accessed - yet the actual error is >> still there, waiting for some poor fool like me who starts the >> program with that tiny little parameter that triggers the error :-( >> >> I'm wondering if there's a way to find this invalid reference with >> Valgrind. Even though it is not dereferenced, it still silently points >> to an invalid memory location, and it might be used some day. Do you >> know if there is a way to detect this? > > Hi > > This sort of problem is in the domain of static analysis tools (for instance, > Coverity and Klocwork, I don't know of any free ones) One that someone on this list recommended, but I have not personally tried is "Flawfinder" http://www.dwheeler.com/flawfinder/ Cheers, Rob. |
|
From: Dan K. <da...@ke...> - 2007-12-13 12:16:44
|
On Dec 13, 2007 3:11 AM, Robert Cussons <r.c...@gs...> wrote: > > This sort of problem is in the domain of static analysis tools (for instance, > > Coverity and Klocwork, I don't know of any free ones) > > One that someone on this list recommended, but I have not personally > tried is "Flawfinder" http://www.dwheeler.com/flawfinder/ MS ships one that handles C and C++, * PREfast - http://msdn2.microsoft.com/en-us/library/ms933794.aspx A couple others (list stolen from http://devresources.linux-foundation.org/dev/nfsv4/site/documentation/testing_approach.php ) * lint - old free tool, used to come with portable C compiler * gimpel lint - nonfree, http://www.gimpel.com/ * splint - http://www.splint.org/ * SMATCH - http://freshmeat.net/projects/smatch/ * Sparse - http://www.kernel.org/pub/software/devel/sparse/ Of these, I think only gimpel lint handles c++. |
|
From: Paul F. <pa...@fr...> - 2007-12-14 18:37:48
|
Robert Cussons wrote: > > One that someone on this list recommended, but I have not personally > tried is "Flawfinder" http://www.dwheeler.com/flawfinder/ Hi Thanks (and to the others) for the pointers. I'll take a look for dabbling at home. At work, we're just starting to use Coverity, which seems quite impressive (though admin-heavy). But with a 5 digit price tag, it's not a toy. A+ Paul |
|
From: DINOT S. <seb...@c-...> - 2007-12-13 12:40:03
|
Hi, Quoting Paul Floyd <pa...@fr...>: > This sort of problem is in the domain of static analysis tools (for instan= ce, > Coverity and Klocwork, I don't know of any free ones) I tried three tools in the past: - Splint (http://www.splint.org/) - Flawfinder (http://www.dwheeler.com/flawfinder/) - Rats (http://www.fortifysoftware.com/security-resources/rats.jsp) From my point of view, Splint is the most advanced and powerful free =20 tool. But if you use it on a huge piece of new code (without special =20 annotations for helping Splint), you will obtain 90% of false positive =20 warnings. But if the reliabily of the code is essential to you, you should use a =20 tool like Splint. Sebastien --=20 S=E9bastien Dinot <seb...@c-...> +33 (0)5 61 17 65 84 ---------------------------------------------------------------- Ce message electronique et tous les fichiers joints qu'il contient =20 (ci-apres "le message") sont confidentiels et destines exclusivement a =20 l'usage des destinataires indiques ou des personnes dument habilitees =20 a les recevoir a leur place. Si vous recevez ce message par erreur, merci de bien vouloir le =20 detruire et d'en avertir l'emetteur. Toute utilisation de ce message non conforme a sa destination, toute =20 diffusion ou toute publication totale ou partielle est interdite sauf =20 autorisation expresse de l'emetteur. Les idees et opinions exprimees dans ce message sont celles de son =20 auteur et ne representent pas necessairement celles de CS =20 Communication & Systemes ou de ses filiales. Malgre toutes les dispositions prises par CS Communication & Systemes =20 et ses filiales pour minimiser les risques de virus, les fichiers =20 joints a ce message peuvent contenir des virus qui pourraient =20 endommager votre systeme informatique. Il vous appartient d'effectuer =20 vos propres controles anti-virus avant d'ouvrir les fichiers joints. =20 CS Communication & Systemes et ses filiales declinent toute =20 responsabilite pour toute perte ou dommage resultant de l'utilisation =20 de ce message et/ou des fichiers joints. This e-mail and any file attached hereto (hereinafter 'the e-mail') =20 are confidential and intended solely for the use of the adressees =20 indicated below or the persons duly entitled to receive them in their =20 place. If you receive this e-mail in error, please delete it and notify the sender. Any use of this e-mail not in accordance with its purpose, any =20 dissemination or disclosure, either whole or partial, is prohibited, =20 unless formally approved by the sender. The ideas or opinions expressed in this e-mail are solely those of its =20 author and do not necessarily represent those of CS Communication & =20 Systeme or its affiliates. Despite all the measures taken by CS Communication & Systeme and its =20 affiliates in order to minimize the risks of virus, the files attached =20 to this e-mail may contain virus which could damage your information =20 system. You are responsible for processing your own anti-virus =20 checking before opening any file attached hereto. Neither CS =20 Communication & Systemes, nor its affiliates, shall be held liable for =20 any loss or damage due to the use of this e-mail or any file attached =20 hereto. |
|
From: Ashley P. <api...@co...> - 2007-12-13 12:48:23
|
On Thu, 2007-12-13 at 13:39 +0100, DINOT Sebastien wrote: > Hi, > > Quoting Paul Floyd <pa...@fr...>: > > This sort of problem is in the domain of static analysis tools (for instance, > > Coverity and Klocwork, I don't know of any free ones) > > I tried three tools in the past: > > - Splint (http://www.splint.org/) > - Flawfinder (http://www.dwheeler.com/flawfinder/) > - Rats (http://www.fortifysoftware.com/security-resources/rats.jsp) > > From my point of view, Splint is the most advanced and powerful free > tool. But if you use it on a huge piece of new code (without special > annotations for helping Splint), you will obtain 90% of false positive > warnings. A lot of the things splint warns about are coding style or fairly minor violations (signed/unsigned compares), once you find the correct command line options for turning all these off then the remaining 10% of real problems becomes apparent. It's worth putting the effort in to get the results, we added splint as a make target due to the complexity and were then able to drive this from our nightly testing. Ashley, |