|
From: Ildar I. <ii...@is...> - 2010-05-25 16:07:31
Attachments:
bugs.txt
|
Hello, I'm Ildar Isaev, a researcher and software developer at Institute for System Programming (http://www.ispras.ru/en/), Russia, Moscow. In the last fifteen months I was working on a research project, which main goal was to investigate the possibility of using dynamic analysis in order to generate 'inputs of death' - such a values of input data that cause some critical bug in the analyzed program to happen. As a result of this research, I developed a tool (it is named Avalanche), that successfully found a number of bugs in the open source projects (see the attachment for their list) and generated input data that reproduces these bugs. Most of these bugs are confirmed and fixed by the developers. Speaking in very brief, Avalanche consists of a Valgrind plugin (it is also developed by me), which tracks the flow of tainted data in the analyzed program and emits special constraints, and a third party constraint solver that checks the satisfiability of the emitted constraints. Some of the constraints are emitted to achieve automatic path alternation, the rest are emitted to check for the possible bugs in the certain situations. The number of bugs discovered by Avalanche lets me hope that Avalanche can become really valuable as a defect detection tool. So now I'm thinking about releasing it "into the wild". Are you interested in such a tool? If so, I may give a more detailed description or provide a preprint for the article that is going to be published in "Programming and Computer Software" journal (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. Can Avalanche probably become one of the Valgrind tools one day? Best regards, Ildar |
|
From: Ildar I. <ii...@is...> - 2010-05-25 18:51:12
|
Yes, setting up a standalone repository is surely the most obvious way. This is may be a good thing for a start, but I suppose it won't give Avalanche that many users. So joining the main Valgrind branch is a desired thing.) Is it really possible and what should be done for that? Should I probably start with standalone repository and try to get some feedback from the users? If this feedback is positive, it may be another good reason for joining the main Valgrind branch. And, if I see an answer from David Molnar, then I think I should say that my research and Avalanche as its result were inspired by SAGE. Avalanche is a kind of SAGE implemented on a basis of Valgrind. It just dynamically instruments Valgrind IR instead of analyzing native traces as it is done in SAGE. It also has some modifications - Avalanche has some support for sockets as sources of symbolic data, it generates special constraints for purposeful reproduction of divisions by zero and segmentation faults on a current trace, etc. > The easiest thing to do for a start is put a full fork of valgrind + > Avalanche up on a repository somewhere. That way at least people can > see and use it while you decide if you want to take the support hit of > keeping up with the main Valgrind branch. > > On Tue, May 25, 2010 at 8:45 AM, Ildar Isaev <ii...@is...> wrote: > >> Hello, >> >> I'm Ildar Isaev, a researcher and software developer at Institute for System >> Programming (http://www.ispras.ru/en/), Russia, Moscow. >> >> In the last fifteen months I was working on a research project, which main >> goal was to investigate the possibility of using dynamic analysis in order >> to generate 'inputs of death' - such a values of input data that cause some >> critical bug in the analyzed program to happen. As a result of this >> research, I developed a tool (it is named Avalanche), that successfully >> found a number of bugs in the open source projects (see the attachment for >> their list) and generated input data that reproduces these bugs. Most of >> these bugs are confirmed and fixed by the developers. >> >> Speaking in very brief, Avalanche consists of a Valgrind plugin (it is also >> developed by me), which tracks the flow of tainted data in the analyzed >> program and emits special constraints, and a third party constraint solver >> that checks the satisfiability of the emitted constraints. Some of the >> constraints are emitted to achieve automatic path alternation, the rest are >> emitted to check for the possible bugs in the certain situations. >> >> The number of bugs discovered by Avalanche lets me hope that Avalanche can >> become really valuable as a defect detection tool. So now I'm thinking about >> releasing it "into the wild". >> >> Are you interested in such a tool? If so, I may give a more detailed >> description or provide a preprint for the article that is going to be >> published in "Programming and Computer Software" journal >> (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. Can >> Avalanche probably become one of the Valgrind tools one day? >> >> Best regards, >> Ildar >> >> wget-1.12 (NPD) >> >> mencoder (NPD) >> >> libquicktime-1.1.3 (3xNPD, infinite loop) >> >> gnash-0.8.6 (uncaught exception) >> >> libjpeg-7 (division by zero) >> >> avifile (NPD) >> >> swftools-0.9.0 (2xNPD) >> >> libmpeg2-0.5.1 (division by zero) >> >> audiofile-0.2.6 (infinite loop) >> >> sndfile-tools-1.02 (division by zero) >> >> vorbis-tools-1.4.0 (infinite loop) >> >> libmpeg3-1.8 (2xNPD) >> >> libwmf-0.2.8.4 (NPD) >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> |
|
From: Julian S. <js...@ac...> - 2010-05-25 22:56:47
|
> > The easiest thing to do for a start is put a full fork of valgrind + > > Avalanche up on a repository somewhere. That way at least people can > > see and use it while you decide if you want to take the support hit of > > keeping up with the main Valgrind branch. Did the message that the above text came from, get sent to the list? I don't see it. J |
|
From: David M. <dm...@gm...> - 2010-05-26 00:37:09
|
On Tue, May 25, 2010 at 4:19 PM, Julian Seward <js...@ac...> wrote: > >> > The easiest thing to do for a start is put a full fork of valgrind + >> > Avalanche up on a repository somewhere. That way at least people can >> > see and use it while you decide if you want to take the support hit of >> > keeping up with the main Valgrind branch. > > Did the message that the above text came from, get sent to the list? > I don't see it. No, I do not think that message from me to Ildar was sent to the mailing list. I meant that as a quick e-mail to Ildar alone. Perhaps something happened with my sending to cause the reply-to: to remain the entire mailing list... I took that route myself for a similar project: http://sourceforge.net/projects/catchconv/ Such a tool would also be useful, of course in the main Valgrind distribution. At the time I wanted to make sure people had a chance to see my code without needing to commit to updating it for new Valgrind versions. (Although I am grateful for all the hard work done on Valgrind, of course!) David Molnar |
|
From: Julian S. <js...@ac...> - 2010-05-25 22:58:18
|
It sounds interesting. I would like to read more about it and perhaps try it out, to get some idea of its effectiveness on large programs (ability to find bugs, false error rate, speed and memory use). > provide a preprint for the article that is going to be > published in "Programming and Computer Software" journal > (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. I would be interested to read that. J |
|
From: Dallman, J. <joh...@si...> - 2010-05-26 09:21:51
|
Julian Seward wrote: > It sounds interesting. I would like to read more about it and > perhaps try it out, to get some idea of its effectiveness on > large programs (ability to find bugs, false error rate, speed > and memory use). Same here. I have a fairly basic question: in what terms does Avalanche express its "inputs of death". Particular arguments to particular functions, for example? thanks, -- John Dallman Parasolid Porting Engineer Siemens Product Lifecycle Management Software Industry Sector 46 Regent Street, Cambridge, CB2 1DP United Kingdom Tel: +44-1223-371554 joh...@si... www.siemens.com/plm |
|
From: Ildar I. <ii...@is...> - 2010-05-26 14:04:15
|
Avalanche analyzes an entire application at once. I suppose the same approach may be applied to analyzing separate functions, but currently it just analyzes the whole application. So what is "input of death"? At first i focused on analyzing applications that get their input data from some input file. In this case, Avalanche just generates input files, that cause the analyzed program to crash if the program is run with them. For example, there is a tool 'cjpeg' that comes with libjpeg. It just converts the specified bmp file to jpeg format. So for that tool Avalanche generated an input file that caused 'cjpeg' to crash with floating point exception due to the division by zero. Then i added some basic support for sockets as sources of input data (this is not described in the preprint - it was done just recently). In this case Avalanche also generates "inputs of death" as files in special format. Reproducing the actual bug with input data coming from sockets is a bit harder - I had to create a special plugin for that. With this support of the sockets I managed to find crashes in 'wget' and 'mencoder'. The brief list of the bugs detected by Avalanche was attached to my first message in this thread. > I have a fairly basic question: in what terms does > Avalanche express its "inputs of death". Particular arguments > to particular functions, for example? > > thanks, > > -- > John Dallman > Parasolid Porting Engineer > > Siemens Product Lifecycle Management Software > Industry Sector > 46 Regent Street, Cambridge, CB2 1DP > United Kingdom > Tel: +44-1223-371554 > joh...@si... > www.siemens.com/plm > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Ildar I. <ii...@is...> - 2010-05-26 12:43:16
|
So here is the preprint. http://docs.google.com/uc?export=download&id=0B8tMFqXJ6Zw0MjJlNmJmMTYtMjNiYS00OGUyLTg3ODMtMjQ3NmQyMDRiMjU3 Page 4 is may be a bit malformed (I haven't received the corrected version from the publishing yet), so please feel free to ask any questions if anything is not clear. > It sounds interesting. I would like to read more about it and > perhaps try it out, to get some idea of its effectiveness on > large programs (ability to find bugs, false error rate, speed > and memory use). > > >> provide a preprint for the article that is going to be >> published in "Programming and Computer Software" journal >> (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. >> > > I would be interested to read that. > > J > |
|
From: Dallman, J. <joh...@si...> - 2010-05-26 13:00:04
|
I'm not clear where the restriction of files to 712 bytes comes from; is that an arbitrary limit to ensure that analysis takes a sane length of time? thanks, -- John Dallman Parasolid Porting Engineer Siemens Product Lifecycle Management Software Industry Sector 46 Regent Street, Cambridge, CB2 1DP United Kingdom Tel: +44-1223-371554 joh...@si... www.siemens.com/plm From: Ildar Isaev [mailto:ii...@is...] Sent: Wednesday, May 26, 2010 1:43 PM To: val...@li... Subject: Re: [Valgrind-users] Valgrind tool for generating 'inputs of death' So here is the preprint. http://docs.google.com/uc?export=download&id=0B8tMFqXJ6Zw0MjJlNmJmMTYtMjNiYS00OGUyLTg3ODMtMjQ3NmQyMDRiMjU3 Page 4 is may be a bit malformed (I haven't received the corrected version from the publishing yet), so please feel free to ask any questions if anything is not clear. It sounds interesting. I would like to read more about it and perhaps try it out, to get some idea of its effectiveness on large programs (ability to find bugs, false error rate, speed and memory use). provide a preprint for the article that is going to be published in "Programming and Computer Software" journal (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. I would be interested to read that. J |
|
From: Ildar I. <ii...@is...> - 2010-05-26 13:12:24
|
Well, there is no such a definite limit - I just used files of this length for testing. But, obviously, the greater the size of the input file, the more chance there is that the analysis will take quite a long time. Because if the file is big, the constraints that need to be checked will contain many variables, and SAT-solving is not very fast. So if one wants to find a bug with Avalanche, one should be better take shorter files. There's just more chance to detect anything. > I'm not clear where the restriction of files to 712 bytes comes from; > is that an arbitrary limit to ensure that analysis takes a sane length > of time? > > thanks, > > -- > John Dallman > Parasolid Porting Engineer > > Siemens Product Lifecycle Management Software > Industry Sector > 46 Regent Street, Cambridge, CB2 1DP > United Kingdom > Tel: +44-1223-371554 > joh...@si... > www.siemens.com/plm > > From: Ildar Isaev [mailto:ii...@is...] > Sent: Wednesday, May 26, 2010 1:43 PM > To: val...@li... > Subject: Re: [Valgrind-users] Valgrind tool for generating 'inputs of death' > > So here is the preprint. > > http://docs.google.com/uc?export=download&id=0B8tMFqXJ6Zw0MjJlNmJmMTYtMjNiYS00OGUyLTg3ODMtMjQ3NmQyMDRiMjU3 > > Page 4 is may be a bit malformed (I haven't received the corrected version from the publishing yet), so please feel free to ask any questions if anything is not clear. > > > > It sounds interesting. I would like to read more about it and > perhaps try it out, to get some idea of its effectiveness on > large programs (ability to find bugs, false error rate, speed > and memory use). > > > provide a preprint for the article that is going to be > published in "Programming and Computer Software" journal > (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. > > > I would be interested to read that. > > J > > > |
|
From: Dallman, J. <joh...@si...> - 2010-05-26 14:34:48
|
> So if one wants to find a bug with Avalanche, one should be > better take shorter files. There's just more chance to detect > anything. This is fine with some kinds of data. One can make a smaller bitmap, or a shorter sound clip. But with what I do - accurate 3D shape representation - one can't get anything meaningful into 1KB or so. I just took a look at our directory of synthetic test parts, and there are some under 1KB, but they are mostly null cases. You start to get non-trivial data at 10KB or so sizes. This doesn't make Avalanche useless, but it does limit it fairly seriously. best, -- John Dallman Parasolid Porting Engineer Siemens Product Lifecycle Management Software Industry Sector 46 Regent Street, Cambridge, CB2 1DP United Kingdom Tel: +44-1223-371554 joh...@si... www.siemens.com/plm > -----Original Message----- > From: Ildar Isaev [mailto:ii...@is...] > Sent: Wednesday, May 26, 2010 2:13 PM > To: val...@li... > Subject: Re: [Valgrind-users] Valgrind tool for generating 'inputs of > death' > > Well, there is no such a definite limit - I just used files of this > length for testing. > > But, obviously, the greater the size of the input file, the more chance > there is that the analysis will take quite a long time. Because if the > file is big, the constraints that need to be checked will contain many > variables, and SAT-solving is not very fast. > > So if one wants to find a bug with Avalanche, one should be better take > shorter files. There's just more chance to detect anything. > > > I'm not clear where the restriction of files to 712 bytes comes from; > > is that an arbitrary limit to ensure that analysis takes a sane length > > of time? > > > > thanks, > > > > -- > > John Dallman > > Parasolid Porting Engineer > > > > Siemens Product Lifecycle Management Software > > Industry Sector > > 46 Regent Street, Cambridge, CB2 1DP > > United Kingdom > > Tel: +44-1223-371554 > > joh...@si... > > www.siemens.com/plm > > > > From: Ildar Isaev [mailto:ii...@is...] > > Sent: Wednesday, May 26, 2010 1:43 PM > > To: val...@li... > > Subject: Re: [Valgrind-users] Valgrind tool for generating 'inputs of > death' > > > > So here is the preprint. > > > > > http://docs.google.com/uc?export=download&id=0B8tMFqXJ6Zw0MjJlNmJmMTYtMj > NiYS00OGUyLTg3ODMtMjQ3NmQyMDRiMjU3 > > > > Page 4 is may be a bit malformed (I haven't received the corrected > version from the publishing yet), so please feel free to ask any > questions if anything is not clear. > > > > > > > > It sounds interesting. I would like to read more about it and > > perhaps try it out, to get some idea of its effectiveness on > > large programs (ability to find bugs, false error rate, speed > > and memory use). > > > > > > provide a preprint for the article that is going to be > > published in "Programming and Computer Software" journal > > (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) > soon. > > > > > > I would be interested to read that. > > > > J > > > > > > > > > ------------------------------------------------------------------------ > ------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2010-05-26 15:06:31
|
On Wednesday 26 May 2010, Dallman, John wrote: > This is fine with some kinds of data. One can make a smaller bitmap, > or a shorter sound clip. But with what I do - accurate 3D shape > representation - one can't get anything meaningful into 1KB or so. > I just took a look at our directory of synthetic test parts, and > there are some under 1KB, but they are mostly null cases. You > start to get non-trivial data at 10KB or so sizes. This doesn't > make Avalanche useless, but it does limit it fairly seriously. Similarly, it's hard to imagine a meaningful video clip fitting into 1k. Ildar, is there a way for Avalanche to sample the search space, so that it can deal with files (eg) 10k long instead of (eg) 1k ? J |
|
From: Ildar I. <ii...@is...> - 2010-05-26 15:08:09
|
1) 10 Kb is not that terribly big either - it still makes sense trying to run the analysis and examine the results 2) Avalanche is good in discovering errors on 'sad paths' - i. e. when the program is run on some kind of malformed input. And one can usually stick quite enough malformation even into short files:) 3) Don't be very strict to Avalanche - it is just a research, which results greatly exceeded my expectations. So now I'm just thinking about better ways of sharing my work and getting some feedback. Of course, there's still a room for improvement. > This is fine with some kinds of data. One can make a smaller bitmap, > or a shorter sound clip. But with what I do - accurate 3D shape > representation - one can't get anything meaningful into 1KB or so. > I just took a look at our directory of synthetic test parts, and > there are some under 1KB, but they are mostly null cases. You > start to get non-trivial data at 10KB or so sizes. This doesn't > make Avalanche useless, but it does limit it fairly seriously. > > best, > > -- > John Dallman > Parasolid Porting Engineer > |
|
From: Dallman, J. <joh...@si...> - 2010-05-26 15:20:34
|
> 2) Avalanche is good in discovering errors on 'sad paths' - i. e. when > the program is run on some kind of malformed input. And one can usually > stick quite enough malformation even into short files:) That's going to explore the problems in input parsing fairly well, but layers of processing that lie behind that are another matter. For the stuff I work on, a very large percentage of all the possible input byte sequences of any particular length will be invalid input, and a large fraction of those will be recognised as invalid by the input parser. As far as I understand your preprint, Avalanche seems more likely to discover the input sequences that result in errors after very little processing than those that produce errors after more processing time? best, -- John Dallman Parasolid Porting Engineer Siemens Product Lifecycle Management Software Industry Sector 46 Regent Street, Cambridge, CB2 1DP United Kingdom Tel: +44-1223-371554 joh...@si... www.siemens.com/plm > -----Original Message----- > From: Ildar Isaev [mailto:ii...@is...] > Sent: Wednesday, May 26, 2010 4:08 PM > To: Dallman, John > Cc: val...@li... > Subject: Re: [Valgrind-users] Valgrind tool for generating 'inputs of > death' > > 1) 10 Kb is not that terribly big either - it still makes sense trying > to run the analysis and examine the results > > 2) Avalanche is good in discovering errors on 'sad paths' - i. e. when > the program is run on some kind of malformed input. And one can usually > stick quite enough malformation even into short files:) > > 3) Don't be very strict to Avalanche - it is just a research, which > results greatly exceeded my expectations. So now I'm just thinking about > better ways of sharing my work and getting some feedback. Of course, > there's still a room for improvement. > > > This is fine with some kinds of data. One can make a smaller bitmap, > > or a shorter sound clip. But with what I do - accurate 3D shape > > representation - one can't get anything meaningful into 1KB or so. > > I just took a look at our directory of synthetic test parts, and > > there are some under 1KB, but they are mostly null cases. You > > start to get non-trivial data at 10KB or so sizes. This doesn't > > make Avalanche useless, but it does limit it fairly seriously. > > > > best, > > > > -- > > John Dallman > > Parasolid Porting Engineer > > |
|
From: Ildar I. <ii...@is...> - 2010-05-26 17:40:55
|
Yes, your understanding is absolutely correct. I should say I'm pleased to receive such a good questions, because it proves that I express my ideas and describe Avalanche quite clearly.) Avalanche is more likely to find a bug if it is close to the program entry point. Finding deep errors is also possible, but it is probably more a kind of a luck, than a purposeful search. However, I have some ideas that may help to overcome this limitation. I believe that the Avalanche approach (constraints checking for path alternation and bug detection) is very powerful, and so it is worth trying to apply it, for example, for a separate function analysis. But currently it is plans and thoughts, it is not yet implemented. As I have already said, there is still enough questions for research and improvement. > As far as I understand your preprint, Avalanche seems more likely to > discover the input sequences that result in errors after very little > processing than those that produce errors after more processing time? > > best, > > -- > John Dallman > Parasolid Porting Engineer > > Siemens Product Lifecycle Management Software > Industry Sector > 46 Regent Street, Cambridge, CB2 1DP > United Kingdom > Tel: +44-1223-371554 > joh...@si... > www.siemens.com/plm > |
|
From: Peter B. <bo...@gm...> - 2010-05-26 07:10:29
|
On Tue, May 25, 2010 at 5:45 PM, Ildar Isaev <ii...@is...> wrote: > Speaking in very brief, Avalanche consists of a Valgrind plugin (it is also > developed by me), which tracks the flow of tainted data in the analyzed > program and emits special constraints, and a third party constraint solver > that checks the satisfiability of the emitted constraints. Some of the > constraints are emitted to achieve automatic path alternation, the rest are > emitted to check for the possible bugs in the certain situations. > Are you interested in such a tool? If so, I may give a more detailed > description or provide a preprint for the article that is going to be > published in "Programming and Computer Software" journal > (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. Can > Avalanche probably become one of the Valgrind tools one day? I can't speak for the Valgrind developers, but as a user that sounds immensely useful. And fun. -- Peter Bortas |
|
From: Ildar I. <ii...@is...> - 2010-06-23 15:37:16
|
OK, so i released Avalanche on Google Code: http://code.google.com/p/avalanche/ I hope it will be useful (at least for somebody). Any feedback is welcome. Best regards, Ildar > Hello, > > I'm Ildar Isaev, a researcher and software developer at Institute for > System Programming (http://www.ispras.ru/en/), Russia, Moscow. > > In the last fifteen months I was working on a research project, which > main goal was to investigate the possibility of using dynamic analysis > in order to generate 'inputs of death' - such a values of input data > that cause some critical bug in the analyzed program to happen. As a > result of this research, I developed a tool (it is named Avalanche), > that successfully found a number of bugs in the open source projects > (see the attachment for their list) and generated input data that > reproduces these bugs. Most of these bugs are confirmed and fixed by > the developers. > > Speaking in very brief, Avalanche consists of a Valgrind plugin (it is > also developed by me), which tracks the flow of tainted data in the > analyzed program and emits special constraints, and a third party > constraint solver that checks the satisfiability of the emitted > constraints. Some of the constraints are emitted to achieve automatic > path alternation, the rest are emitted to check for the possible bugs > in the certain situations. > > The number of bugs discovered by Avalanche lets me hope that Avalanche > can become really valuable as a defect detection tool. So now I'm > thinking about releasing it "into the wild". > > Are you interested in such a tool? If so, I may give a more detailed > description or provide a preprint for the article that is going to be > published in "Programming and Computer Software" journal > (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) > soon. Can Avalanche probably become one of the Valgrind tools one day? > > Best regards, > Ildar > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Juan C. M. S. <jua...@gm...> - 2010-06-25 14:33:26
|
Hello, I tried to install the application, but I could not do it. I got the following errors. Regards, Juan Carlos ********************** In file included from m_cpuid.S:31: pub_core_basics_asm.h:42:33: error: pub_tool_basics_asm.h: No such file or directory pub_core_basics_asm.h:45:20: error: config.h: No such file or directory make[4]: *** [libcoregrind_x86_linux_a-m_cpuid.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [tracegrind] Error 2 On Wed, Jun 23, 2010 at 11:35 AM, Ildar Isaev <ii...@is...> wrote: > OK, so i released Avalanche on Google Code: > http://code.google.com/p/avalanche/ > > I hope it will be useful (at least for somebody). Any feedback is welcome. > > Best regards, > Ildar > > Hello, > > I'm Ildar Isaev, a researcher and software developer at Institute for System > Programming (http://www.ispras.ru/en/), Russia, Moscow. > > In the last fifteen months I was working on a research project, which main > goal was to investigate the possibility of using dynamic analysis in order > to generate 'inputs of death' - such a values of input data that cause some > critical bug in the analyzed program to happen. As a result of this > research, I developed a tool (it is named Avalanche), that successfully > found a number of bugs in the open source projects (see the attachment for > their list) and generated input data that reproduces these bugs. Most of > these bugs are confirmed and fixed by the developers. > > Speaking in very brief, Avalanche consists of a Valgrind plugin (it is also > developed by me), which tracks the flow of tainted data in the analyzed > program and emits special constraints, and a third party constraint solver > that checks the satisfiability of the emitted constraints. Some of the > constraints are emitted to achieve automatic path alternation, the rest are > emitted to check for the possible bugs in the certain situations. > > The number of bugs discovered by Avalanche lets me hope that Avalanche can > become really valuable as a defect detection tool. So now I'm thinking about > releasing it "into the wild". > > Are you interested in such a tool? If so, I may give a more detailed > description or provide a preprint for the article that is going to be > published in "Programming and Computer Software" journal > (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. Can > Avalanche probably become one of the Valgrind tools one day? > > Best regards, > Ildar > > ________________________________ > ------------------------------------------------------------------------------ > > ________________________________ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- Juan Carlos |
|
From: Ildar I. <ii...@is...> - 2010-06-25 14:56:23
|
I suppose you probably have an old version of automake/autoconf. The version should be >= 1.10. There's something wrong with Valgrind configuration in older versions. > Hello, > > I tried to install the application, but I could not do it. I got the > following errors. > > Regards, > > Juan Carlos > > ********************** > In file included from m_cpuid.S:31: > pub_core_basics_asm.h:42:33: error: pub_tool_basics_asm.h: No such > file or directory > pub_core_basics_asm.h:45:20: error: config.h: No such file or directory > make[4]: *** [libcoregrind_x86_linux_a-m_cpuid.o] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all] Error 2 > make: *** [tracegrind] Error 2 > > > On Wed, Jun 23, 2010 at 11:35 AM, Ildar Isaev <ii...@is...> wrote: > >> OK, so i released Avalanche on Google Code: >> http://code.google.com/p/avalanche/ >> >> I hope it will be useful (at least for somebody). Any feedback is welcome. >> >> Best regards, >> Ildar >> >> Hello, >> >> I'm Ildar Isaev, a researcher and software developer at Institute for System >> Programming (http://www.ispras.ru/en/), Russia, Moscow. >> >> In the last fifteen months I was working on a research project, which main >> goal was to investigate the possibility of using dynamic analysis in order >> to generate 'inputs of death' - such a values of input data that cause some >> critical bug in the analyzed program to happen. As a result of this >> research, I developed a tool (it is named Avalanche), that successfully >> found a number of bugs in the open source projects (see the attachment for >> their list) and generated input data that reproduces these bugs. Most of >> these bugs are confirmed and fixed by the developers. >> >> Speaking in very brief, Avalanche consists of a Valgrind plugin (it is also >> developed by me), which tracks the flow of tainted data in the analyzed >> program and emits special constraints, and a third party constraint solver >> that checks the satisfiability of the emitted constraints. Some of the >> constraints are emitted to achieve automatic path alternation, the rest are >> emitted to check for the possible bugs in the certain situations. >> >> The number of bugs discovered by Avalanche lets me hope that Avalanche can >> become really valuable as a defect detection tool. So now I'm thinking about >> releasing it "into the wild". >> >> Are you interested in such a tool? If so, I may give a more detailed >> description or provide a preprint for the article that is going to be >> published in "Programming and Computer Software" journal >> (http://www.maik.rssi.ru/cgi-perl/journal.pl?lang=eng&name=procom) soon. Can >> Avalanche probably become one of the Valgrind tools one day? >> >> Best regards, >> Ildar >> >> ________________________________ >> ------------------------------------------------------------------------------ >> >> ________________________________ >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > > > > |