Error,Timestamp,Participant,CodeFamiliarity,DiagnosisDifficulty,DiagnosisTechnique,DiagnosisTool,DiagnosisTime,FaultLocation1,FaultLocation2,FaultLocation3,FaultLocation4,FaultLocation5,Diagnosis,DiagnosisConfidence,DiagnosisProblems,DiagnosisSteps,DiagnosisImprovement,DiagnosisAutomation,DiagnosisAutomationRationale,BugfixDifficulty,BugfixTime,BugfixSteps,BugfixConfidence,BugfixEnsureCorrectness,BugfixProblems,BugfixAutomation,BugfixAutomationRationale,FillingQuestionnaireTime
find.091557f6,2/2/2016 17:20:53,ZTk0ZThkOD,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",eclipse cdt,30 - 40 minutes,find/pred.c:1578,find/pred.c:305-315,find/ftsfind.c:229-248,find/util.c:228-236,,"because ""stat"" function never called on symlinks, because of predicate->need_stat member wrongly initialized with false;",Moderately confident,,"1. found the line where assert triggered;
2. walked up to the stack
3. realized that get_statinfo never called with current predicate, that in turn leads to assetion ",,"No, there will never be a tool that can explain this error.","if was not easy to understand, also code that caused error spread over multiple functions",Moderately difficult,20 - 30 minutes,"set ""need_stat"" flag in predicate structure to true if ""following symlink"" option set",Slightly confident,"I'm not sure if it good fix - most likely there should be different place where to set ""need_stat"" variable, but it still works","while test failed to start:
""root@2b91814969fd:~/Desktop/find13# ./test/test.sh find
./test/test.sh: 131: ./test/test.sh: find/find/find: not found
/root/Desktop/find13""
I started program manually and checked output
","No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.091557f6,2/3/2016 10:06:14,YTA2MTE4ND,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,find/pred.c:1577-1578,find/ftsfind.c:457-460,find/ftsfind.c:465,gnulib/lib/fts.c:1384-1394,,"The error is inconsistency between state.have_type and state.type values. The first beeing true supposes the second is non-zero

The inconsistency was caused at find/ftsfind.c:457-460 and detected at find/pred.c:1577-1578

The actual reason behind this inconsistency is that fts_read doesn't return proper status code at gnulib/lib/fts.c:1384-1394",Moderately confident,,"1. looked at the place where assertion failed
2. watched for state.have_type and state.type modifications with gdb
3. found the place where the inconsistency appears
4. closely tracked execution and investigated the code to understand the logic behind
5. found out that status returned from fts is wrong
6. grepped for FTS_LSNONE through fts lib
7. breakpointed to that place and found why it is not returned there",,"No, there will never be a tool that can explain this error.","I can imagine a tool which would track all possible execution lines and explain the chain of events lead to this particular error, but 

1) i would not call such explanation intuitive

2) this seems to be uncomputable in terms of Turing machine in common case",Not at all difficult,5 - 10 minutes,i fixed `stat` ELOOP error handling in fts lib,Very confident,manual testing,,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
find.091557f6,3/18/2016 21:56:54,OTcyZjg1Mz,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",2 - 5 minutes,find/ftsfind.c:557-605,find/ftsfind.c:391-476,find/ftsfind.c:613-632,,,"Not treated all returned error codes from a function. This error is similar to other already done. 

The fts_open() function invoked at section can return a range of values, some of them error conditions that were not checked at section 2 (function consider_visiting()). Skipping this checking, exactly for the value FTS_NS that it is an error condition, caused that the code treated this as an OK scenario and then crashed",Very confident,,"First I run the buggy binary several times
Then run gdb till the crash point
Then did backtrace and show that not some errors were not considered",Not treated all errors,"No, there will never be a tool that can explain this error.","Complicated, you need to know the range of values that fts_open() can return",Not at all difficult,5 - 10 minutes,Treat the error code returned by fts_open() when using it symb links,Very confident,Tested it against crashing scenario and compare its output also with Linux find command to be really sure that it works at intended,,"No, there will never be a tool that can fix this error reliably.","This tool should know about fts_open(), complicated, no doubt",5 to 10 minutes
find.091557f6,4/12/2016 6:16:22,ZmZkMWM5OG,Moderately familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/pred.c:1578,find/ftsfind.c:584,find/ftsfind.c:430-444,,,"The illegal situation on filesystem has been forgotten to catch. 
For symbolic links loop, fts_read() will return an empty ent and ent->fts == FTS_NS, see  find/ftsfind.c:584. There is a function symlink_loop() which should check and report this situation but it is not called, because ent->fts_info is not FTS_SLNONE but FTS_NS, see find/ftsfind.c:430-444.",Very confident,,The assertion at find/pred.c:1578 confirms that type==0. I have traced this to fts_read. Because this is a system call I belived that it is OK. Thus I looked why this situation is not catched. I noticed function symlink_loop() which should check and report this situation (according to the comment) but it is not called.,"The meaning of all this FTS_ flags, I have to googled for them.","Yes, in principle a tool might be able to explain this error.",This is similar to segmentation fault. The tool can give us a trace which is a kind of an explanation.,Moderately difficult,10 - 20 minutes,I have made one block of code executed also for previously uncatched error.,Very confident,Test cases are working. It is somehow obvious that uncatched situation is wrong and thus this was really the needed fix.,,"No, there will never be a tool that can fix this error reliably.",This is about a missing fuctionality. The tool cannot know what is missing.,30 to 40 minutes
find.091557f6,4/14/2016 18:06:43,MGJmMTU1N2,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, snavigator",60 minutes or more,find/util.c:219,find/util.c:237,find/pred.c:313,,,"condition for getting stat on file was too tight, it should have been: if file is special type and mode is not known",Moderately confident,,multiple divide et impera debugging sessions and lots of code browsing in between,maybe a short explanation of how find is intended to work would have been very useful,"Yes, in principle a tool might be able to explain this error.","since it's a crash, an automated thing could have traced back runtime actions leading to the error",Moderately difficult,60 minutes or more,loosened the condition on the need for updating stat information of file,Moderately confident,crash dissapeared,,"Yes, in principle a tool might be able to fix this error reliably.",backtrack the runtime path that lead to crash is possible,5 to 10 minutes
find.091557f6,4/16/2016 12:37:46,ZTRmYWE5Nj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/pred.c:1578,find/ftsfind.c:460,find/ftsfind.c:1166,,,state type not correct,Slightly confident,,"Check the error log

then read the source to check ""state.type"" value",,"Yes, in principle a tool might be able to explain this error.","We can check the ""state.type"" value by using a tool.",Slightly difficult,10 - 20 minutes,"We do not check the ""type"" value",Slightly confident,"test it.
no error occured",,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.091557f6,4/24/2016 3:48:48,NDM5MjVmOT,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",20 - 30 minutes,find/pred.c:1578,find/ftsfind.c:389-515,lib/fts.h:204,,,Assert condition failed (find/pred.c:1578). Error state (gnulib/lib/fts_.h:204) caused by valid reason but seems do not handled properly before this point. ,Extremely confident,,"First I placed conditional breakpoint on assert() call. Running program with gdb I got backtrace when assert condition failed (find/pred.c:1578). Browsing source code, I found, that state.type is set to 0 just before consider_visiting() function invocation (find/ftsfind.c:590) and do not changed after this function invokes visit(), so it must be set within find/ftsfind.c:389-515. Tracing this code area, I found that statbuf.st_mode is 0 too and ent->fts_info is set to FTS_NS. This values combination preventing finction logic to change state.type but passed erroneous data to the next. Accorfing to (gnulib/lib/fts_.h:204) FTS_NS means ""stat(2) failed"". Structure value ent->fts_errno is set to 40 (ELOOP). So I decided that stat() on symlink loop causes error condition that does not handled properly.",tracing unhandled error conditions may be helpful here,"Yes, in principle a tool might be able to explain this error.",This error caused by unhandled error condition. A tool can be used to analyse program execution and report for unhandled error conditions.,Not at all difficult,1 minute or less,I enabled to handle FTS_NS error conditions by an usual way.,Extremely confident,This bug is simple and obvious. It does work and has no side effects.,,"Yes, in principle a tool might be able to fix this error reliably.",Error condition handling is quite simple and obvious thing to do. Although I am unsure if a tool can properly select best code location for error reporting.,10 to 20 minutes
find.091557f6,4/26/2016 15:35:15,NGU0NDRiM2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",40 - 50 minutes,ftsfind.c:425-430,ftsfind.c:425-430,ftsfind.c:431-446,pred.c:1578-1578,,Did not handle FTS_NS value of ent->fts_info.,Very confident,,"Build in debug mode
See to stack trace
Run 'find' utility with option '-D search'
See to code of function 'consider_visiting()'",,"Yes, in principle a tool might be able to explain this error.",Check to comparison to all values of ent0>fts_info,Moderately difficult,5 - 10 minutes,Add checking for FTS_NS value of env->fts_info.,Very confident,Test finished successfully,,"Yes, in principle a tool might be able to fix this error reliably.",Tracknig all comparison to all possible values of env->fts_path.,10 to 20 minutes
find.091557f6,5/29/2016 5:21:29,NzBjMjQ0OT,Slightly familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,10 - 20 minutes,find/ftsfind.c:240-241,find/pred.c:306-308,find/pred.c:1577-1579,,,find aborts the file if the mode is 0000,Very confident,,"Initially, using the core file generated I figured out that the assert() statement in pred_type is causing the abort. 
I decided the replace the abort with an if condition.","If I was told how the program should behave after the patch, it would have been easier I feel","Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,I replaced the assert statement with an if condition so that the program doesnt abort,Moderately confident,Applied the patch. Verified the correctness. I am not sure if the program has to behave this way after applying the patch. I have made sure that the program doesnt abort,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.091557f6,7/27/2016 18:43:27,ZTBjYWY1Nj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb,ack-grep",10 - 20 minutes,find/ftsfind.c:515,find/ftsfind.c:243,find/pred.c:1578,,,The case of symlink loop is not processed correctly; it should print an error message instead of plain assert,Slightly confident,,I've examined core dump after assertion and then tried to replace assert with proper error handling used throughout the `find` sources; it worked.,,"Yes, in principle a tool might be able to explain this error.","Well, theoretically, assert itself is an explanation to programmer that something she held true is not.",Not at all difficult,1 minute or less,I've replaced assert with proper error handling.,Moderately confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",There is no way an automated tool would `know` what to do when assertion held false.,20 to 30 minutes
find.091557f6,7/30/2016 2:26:57,MzBiYjQ4ZG,Moderately familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb, printing",10 - 20 minutes,find/pred.c:1578,find/pred.c:1610,find/ftsfind.c:560,,,method of checking variable was wrong.  Function should return some value but it was not returning it was just checking using assert but it should be if.,Very confident,,first try to looked at code flow but everything seems to be ok and error it self suggesting that this line assert is failed and found that in stead of assert we should use if and return some boolean as a false because it fails and it worked.,,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,Started using correct way to test variable.,Very confident,by running test script and checking functional impacts.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.091557f6,8/2/2016 5:43:04,MTk0NjE0Mj,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,ftsfind.c:440,ftsfind.c:455,ftsfind.c:460,,,"fts_read() returns FTS_NS in ent->fts_info which is not handled in consider_visiting() (ftsfind.c:455) and thus state.type left intact as 0 (ftsfind.c:460)  and triggering assert later in pred_type().
I noticed the symlink_loop() at ftsfind.c:440 which apparently should be used in case of, well, symlink loop.",Slightly confident,,Backtrace in gdb gave me that last `mode` change was in consider_visiting() and pointed me at ent->fts_statp and ent->fts_info which was set/handled incorrectly.,,"No, there will never be a tool that can explain this error.",Quite complicated for me and involves some comment reading/understanding.,Moderately difficult,10 - 20 minutes,Added check for ELOOP in ent->fts_errno. So if fts_read() detects loop it actually handled (presumably) correctly in consider_visiting(),Slightly confident,  ,,"No, there will never be a tool that can fix this error reliably.",To fix this bug reliably the tool should be able to understand the meaning of some functions as human understands it. I doubt that it's possible.,10 to 20 minutes
find.091557f6,8/3/2016 14:02:02,ODY3ODM5YW,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,pred.c:1577-1578,ftsfind.c:442-444,fts.h:203,ftsfind.c:458,,Unchecked error condition. Fetching the stat might fail,Moderately confident,,"1. Run gdb  an get backtrace
2. Find location that writes state.type 
3. set breakpoint at ftsfind.c:458
4. On breakpoint print statbuf.st_mode and fts_statp -> looks uninitialised
5. also print ent->fts_info. It is 10!
5. read man fts_read and fts.h:203 to figure out what that means,
",There were unchecked error values,"Yes, in principle a tool might be able to explain this error.",If you know what is an error value and you can see that some error values are handled separately and some are not handle at all that stinks.,Not at all difficult,1 minute or less,Check error condition and ignore (as in return),Moderately confident,This fix is simple. So I just ran the test case,,"No, there will never be a tool that can fix this error reliably.",I believe detection is simple. Fixing is probably much harder. But I suppose you could create some suggestions by looking at how the other error cases are handles.,10 to 20 minutes
find.24bf33c0,2/1/2016 6:09:48,ZTk0ZThkOD,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","eclipse, gdb",20 - 30 minutes,find/util.c:228,find/pred.c:310,find/pred.c:240,,,"""stat"" function doesn't get called on the path inside broken symlink",Moderately confident,,"1. traced program with debugger
2. located the place where program outputs path under broken sysmlink
3. checked why ""stat"" doesn't called on that item",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,"flag that tells program to stat the path before processing it ""eval_tree->need_stat""",Slightly confident,"I checked program output and compared it with ""system's"" find;
BUT testcase returns failure in some reasons",,"No, there will never be a tool that can fix this error reliably.",,more than 40 minutes
find.24bf33c0,2/3/2016 11:34:32,YTA2MTE4ND,Very familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/ftsfind.c:388-462,find/ftsfind.c:578-596,find/ftsfind.c:418,,,error condition check at find/ftsfind.c:418 ignores one of the possible error codes,Very confident,,"1. check backtrace at pred_print function call which is responsible for bad result output
2. look into `find` function at find/ftsfind:578-596 to investigate why it is proceeding with bad starting point. (mistake, that's ok to proceed here, error is reported in `consider_visiting`)
3. trace fts_open function, found that the error on fts_stat call is ignored (mistake also)
4. here i realized that starting point would be processed by fts_read too, which error result is processed in `consider_visiting`
5. investigated consider_visiting code and found that FTS_NS error code is not handled appropriately",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,added error handling for FTS_NS,Moderately confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.24bf33c0,3/18/2016 3:34:22,OTcyZjg1Mz,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",50 - 60 minutes,find/ftsfind.c:668-702,find/ftsfind.c:600-608,find/ftsfind.c:548-591,find/ftsfind.c:391-540,,An non existing file is treated as a valid path and returned error is ignored,Slightly confident,,"First I have to studied completely the code (deeper than previous bugs)
Then I found that it was generating an error not treated
Finally I added treatment for this error",Not treated all errors,"No, there will never be a tool that can explain this error.","It was really difficult for me to find it after a long while, I can believe this can be done with a button",Very difficult,30 - 40 minutes,Treat an error scenario (error code) not considered at consider_visiting() function. It copes with most of the errors but this one was not taken into account and the code continued treating this path as OK,Moderately confident,"Tested against bug report, tested many other scenarios of links and find commands",,"No, there will never be a tool that can fix this error reliably.","Impossible for a tool, this made me sweet a lot",10 to 20 minutes
find.24bf33c0,4/12/2016 22:02:36,ZmZkMWM5OG,Extremely familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",2 - 5 minutes,find/ftsfind.c:431-446,find/ftsfind.c:586,pred.c:1459,,,"For symbolic links loops fts_read() at find/ftsfind.c:586 returns ent with ent->fts_info == FTS_NS. This situation is not covered in consider_visiting(), e.g. in find/ftsfind.c:431-446. Thus the program proceeds further without the error and line in pred.c:1459 it prints out the element.",Extremely confident,,I have to say that this error is the same as the previous one. When I read the description I have immediately check the same part of the code which was wrong in the last example. I found out that the same statement is missing. Then I made the same fix and checked tests.,,"No, there will never be a tool that can explain this error.","Although the root cause for the error is the same as in the previous example, it does not produce the same output and especially, there is no assert to catch it. Without telling the tool about the wrong situaton it is just a missing/broken functionality which is not uderstandable by the tool.",Not at all difficult,1 minute or less,I have correctly process the bad situation wich appears after the system call.,Extremely confident,Test cases are working.,,"No, there will never be a tool that can fix this error reliably.",Adding/changing functionality from the given traces is not applicable to such C projects.,10 to 20 minutes
find.24bf33c0,4/14/2016 22:16:19,MGJmMTU1N2,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,snavigator",60 minutes or more,find/ftsfind.c:546,find/ftsfind.c:580,find/ftsfind.c:590,,,an error case when the top dir could not be opened was ignored,Moderately confident,,"debug and check variables. 
verifying the reverse call tree
more debug",,"Yes, in principle a tool might be able to explain this error.",might be possible since an error condition was left untreated,Moderately difficult,5 - 10 minutes,added treatment for the error condition on top of walking the directory tree,Moderately confident,ran in debugger and made sure the variables and control flow is as expected,,"Yes, in principle a tool might be able to fix this error reliably.","an error condition was left untreated, so maybe there's a way to discover that and warn",less than 5 minutes
find.24bf33c0,4/15/2016 11:08:05,ZTRmYWE5Nj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/ftsfind.c:440-445,find/ftsfind.c:318-327,find/ftsfind.c:413-414,,,"""fts_info"" is not the right value",Slightly confident,,"find ""symlink_loop"" function and read it.",,"No, there will never be a tool that can explain this error.",,Slightly difficult,10 - 20 minutes,"give ""ent->fts_inf"" a right value.",Slightly confident,"test the result,it is ok.

but not sure whether it is the right code line to fix error.",,"No, there will never be a tool that can fix this error reliably.",I think It is hard to figure out the right code segment to fix this error.,5 to 10 minutes
find.24bf33c0,4/19/2016 22:51:25,NDM5MjVmOT,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",60 minutes or more,gnulib/lib/fts.c:1385,find/ftsfind.c:578,find/ftsfind.c:389-542,,,"Program trying to open given path for search by invoking  fts_open() (find/ftsfind.c:578). On error conditions it set fields of returned structure (fts_info, fts_errno) appropriately (gnulib/lib/fts.c:1385). If fts_open() can not stat() given path, it returns FTS_NS - 'stat(2) failed' value in fts_info field. But this value do not checked in consider_visiting() function  (find/ftsfind.c:389-542) like other errors. That is why some error cases remains not reported just working like there are no error at all.",Extremely confident,,"I ran the program with gdb using corresponding command line options. Setting program trap on stdout output and viewing backtrace at that point I determined common trace path which leads to such result. Viewing source code along this trace path I noticed that there is fts_open invocation which obviously must give error result. Tracing it by gdb, I found that error condition filled to structure correctly. Next I continue tracing to find where those error values is used. I found that check for error conditions returned by stat() invocation is missed so program passes erroneous values to output. ",Compilers can check if switch() operators uses all range of passed values. Similar tool working in runtime could be handy.,"Yes, in principle a tool might be able to explain this error.","It is easy enough to check if all range of values are used. Due this may be usual program execution too, tool may produce warning about that. It will be helpful but maybe not determine root of problems actually. In more complex case, tool must be learned about error conditions returned by system calls and demand that application handle each error condition by any way. At least application must not use any structure got from a system call returned error.",Not at all difficult,1 minute or less,I added handle of error condition caused by failed stat() invocation.,Very confident,"It fixes problem and do not affect other aspects of program execution. It fixed some other problems too. For example, 'find /foo' found /foo before patch even if /foo does not exists.",,"No, there will never be a tool that can fix this error reliably.","Although the unhandled error condition can be easily detected by a tool, I am not sure if tool can find correct place and way to handle the error condition. So I am not doubt about that at all.",10 to 20 minutes
find.24bf33c0,4/27/2016 0:05:17,NGU0NDRiM2,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",printf(),5 - 10 minutes,ftsfind.c:431-446,ftsfind.c:389-541,ftsfind.c:389-541,,,Do not handle FTS_NS value of ent->fts_info.,Moderately confident,,"Find using symlink_loop() function
See the code of consider_visiting() function
Printf ent->fts_info value
See that case of FTS_NS value of ent->fts_info variable do not process
Fix the bug",,"Yes, in principle a tool might be able to explain this error.",Tracking all values of ent->fts_info variables,Not at all difficult,2 - 5 minutes,Handle case FTS_NS value of ent->fts_info variable.,Moderately confident,Test running successfully,,"Yes, in principle a tool might be able to fix this error reliably.",Tracking all values of ent->fts_info variable,5 to 10 minutes
find.24bf33c0,5/26/2016 16:18:39,NTU0ZTZlNT,Not at all familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,find/ftsfind.c:447,find/ftsfind.c:545,find/ftsfind.c:694-699,,,"- region 1:  The code lacks the handler when the flags member of the consider_visiting FTSENT* argument is a stat(2) failure.
- region 2:  continued read of member files & directories of directories that produced an errno makes these kinds of 'finds' inefficient
- region 3:  catering for negative file descriptors adds a computing cycle",Extremely confident,,research about the flags member of the FTSENT structure,a symlink loop happens when a stat(2) failes,"No, there will never be a tool that can explain this error.",sufficient knowledge of the FTSENT flags member is needed to diagnose the problem,Very difficult,30 - 40 minutes,"- add a handler when the flags member of the FTSENT* argument of consider_visiting is a stat(2) failure & a symlink loop is present
- make the find function return a boolean instead of nothing
- don't query the starting directory's file descriptor for negativity as it will never be negative",Extremely confident,output is now as per bug description,,"Yes, in principle a tool might be able to fix this error reliably.",reporting symlink loops is locatable in consider_visiting function,20 to 30 minutes
find.24bf33c0,5/28/2016 5:12:52,NzBjMjQ0OT,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,40 - 50 minutes,find/ftsfind.c:687-689,find/ftsfind.c:614-615,find/ftsfind.c:388-469,,,"The line numbers might not be accurate since I have applied the patch and then put these numbers.
The condition to check the failure of stat call was missing. I added a simple check",Extremely confident,,"Initially, through gdb I traversed through the code once to get a gist of what code was getting executed. I noted down the variables . I printed down the values of ent and figured out there was en error check missing",,"No, there will never be a tool that can explain this error.",,Very difficult,30 - 40 minutes,I added an error check  to take care of failure of stat call in fts_stat() present in find(),Extremely confident,I have applied the patch and verified the correctness,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.24bf33c0,7/23/2016 2:29:56,MzBiYjQ4ZG,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,20 - 30 minutes,find/ftsfind.c:431,find/ftsfind.c:440,find/ftsfind.c:318,,,not taking care of all return types.,Very confident,,I saw function calling first from where to where.. then I found that it is not going in function give gives error result which is needed. I found why it is not going and then I found it was not handled so I handled it.,,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,10 - 20 minutes,taken care of all possible values.,Very confident,by running test scripts and by observing functional impact.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.24bf33c0,7/27/2016 19:27:05,ZTBjYWY1Nj,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",ack-grep,20 - 30 minutes,find/ftsfind.c:431,find/ftsfind.c:318,find/ftsfind.c:457,,,The check for symlink loop (region 2) was not executed because of testing against incomplete set of flags in region 1; for symlink loop the case is that ent->fts_info = FTS_NS. So the processing was going further (region 3) like it was normal file.,Slightly confident,,"I've searched for place where symlinks are processed and, after occasional grepping, stumbled upon a function from region 2 which checks for such loop. Then I've debugged with tracing the function that was calling loop checking function and found out it had incorrect flag checking.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,I've made sure the check for symlink loop case is called when needed.,Moderately confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,30 to 40 minutes
find.24bf33c0,8/2/2016 7:36:09,MTk0NjE0Mj,Moderately familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,ftsfind.c:431,ftsfind.c:431,ftsfind.c:431,,,"Basically the same bug as in find.091557f6.
",Slightly confident,,Same as in find.091557f6,,"No, there will never be a tool that can explain this error.",,Slightly difficult,2 - 5 minutes,"Same as in find.091557f6.

Maybe this is totally wrong fix just because it appears twice for quite complicated topic.
Maybe it should be fixed in a way where we check for ent->fts_info to be FTS_SL and some other stuff. But according to the description of FTS_SL it's just a symbolic link and it's strange to me to handle this case somehow specially. I.e. I do not know maybe there is legitimate case then ent->fts_info is FTS_SL and there is no ELOOP. Or maybe at this point FTS_SL is always means a error.",Not at all confident, ,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.24bf33c0,8/11/2016 18:05:15,ODY3ODM5YW,Very familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find.c:431,noother.c:0,noother.c:0,,,FTS_NS is not handled,Moderately confident,,Not much. Very similar to the other one so I knew were to look,,"Yes, in principle a tool might be able to explain this error.",Missing check of return value. So easy to find.,Not at all difficult,2 - 5 minutes,FTS_NS can be set if we have a loop. So do the same as for FTS_SLNONE,Moderately confident,Run test case.,,"No, there will never be a tool that can fix this error reliably.",Detecting should be easy but for fixing you need to know what to do.,10 to 20 minutes
find.24e2271e,10/24/2015 19:34:54,ZDc4NDZjMm,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ctags",20 - 30 minutes,find/pred.c:580,find/pred.c:712,find/ftsfind.c:278,,,"The state.starting_path_length variable does not change once it has been set. Hence, it continues using the value of the very first segment. This logic requires to be checked to fix the issue.",Very confident,,"I tried tracing the path of the program to reach the location that prints the actual values. From there, I tried going back to the location that creates the strings for fpritnf() to print. 

Then a bunch of gdb breakpoints and runs showed the exact error that the state information is not changing.","If only I knew where the exact printf statement is being formulated, this would have been much easier.","Yes, in principle a tool might be able to explain this error.","Following through this codebase is hard. And automating it to identify the one location that should change but doesn't seems like a very difficult problem to me. It might be possible, but definitely not trivial.",Moderately difficult,5 - 10 minutes,"I removed the one condition causing the issue. It seems like the code requires the state.starting_path_length to be 0 to actually set it. However, this initialization is done nowhere.

So simply eliminate the condition",Slightly confident,"I'm not confident since I have a strong feeling that eliminating this check will break something down the line. The ideal fix would have been to track down a good location to initialize state.starting_path_length to 0u. However, I again quote the 30 minute time constraint we have on each bug.

On a real source where I had to push this change, I wouldn't submit this without a lot more testing.",,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
find.24e2271e,2/3/2016 5:51:18,YTA2MTE4ND,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,find/pred.c:709-718,find/ftsfind.c:279,find/ftsfind.c:278,,,state.starting_path_length is used in pred_fprintf at find/pred.c:709-718 and it is not changed after switching to second starting point,Extremely confident,,"1. find pred_fprintf function
2. study %H switch case. bad starting_path_length is pretty obvious hypothesis for the test case provided
3. with gdb, track the point where starting_path_length is updated, fix and test",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,removed strange condition which made starting_path_length to be updated only once,Very confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.24e2271e,3/19/2016 16:17:53,OTcyZjg1Mz,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",20 - 30 minutes,find/ftsfind.c:125-136,find/pred.c:709-718,find/pred.c:809-820,find/ftsfind.c:278-280,,"At sections 2 and 3 we receive always the same length value regardless of the directory being considered (always 4 value in this case that is the length of the first directory treated). This value is never updated for other directories and this is the buggy part.
This was done at section 4",Very confident,,"First I run the debugger to see what was the pred_func called to print the ouput (wrong output), setting a breakpoint at section 1 where we invoke the callback to print result

Then I saw that it was the function pred_fprintf() present at section 2 and 3

Then I checked setting a breakpoint at these 2 sections that always the length is the same at these points and this is the reason of the bug

At section 4 we have the root cause and the condition is wrong there",Path length not updated correctly,"No, there will never be a tool that can explain this error.","Once again complicated, after many years debugging is a manual task and seems to be for a long time",Slightly difficult,5 - 10 minutes,Remove extra condition not required that caused path length to no be updated. Now we always update path correctly every time we reach a level 0 directory,Very confident,"Repeated buggy scenarios,
Created new sub-directories inside the original ones to test many levels
Compare results with Linux built-in find command",,"No, there will never be a tool that can fix this error reliably.","If the software is done by human, it should be fixed by human, this is just a human mistake and it is complicated to fix it with a tool.",5 to 10 minutes
find.24e2271e,4/10/2016 4:25:30,ZmZkMWM5OG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",30 - 40 minutes,find/ftsfind.c:278,find/pred.c:714,find/pred.c:813,,,"Condition in find/ftsfind.c:278 is not correct. The second part, i.e. (0u == state.starting_path_length) is wrong and thus starting_path_length is updated only the first time. It is used in find/pred.c:714 and find/pred.c:813 and we get wrong results.",Very confident,,"I have extended test example with ""mkdir dd"" and immediatelly I see, that for the all arguments, the length of the first dir is somehow in effect. Then I observed eval_tree to find out predicate pred_fprintf. I ha ve noticed the use of state.starting_path_length and check where it should be updated.",,"Yes, in principle a tool might be able to explain this error.",This is similar as before. If a tool get for every function a set of conditions about its arguments and if this conditions include enough information then the tool can give a callback trace to the situation where there is something wrong. But this is probably not applicable to this kind of C project.,Not at all difficult,2 - 5 minutes,"I have removed one condition, which I think is wrong.",Very confident,"It work for my test cases. Still, I do not understand , why the extra condition was there and maybe, it should not be simply removed. But it really looks unnecessary to me.",,"No, there will never be a tool that can fix this error reliably.","Similar as before, it is a change to functionality and the tool should ""understand"" the algorithm. This is not possible for C project which are not very useful formal models.",10 to 20 minutes
find.24e2271e,4/15/2016 10:24:03,ZTRmYWE5Nj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/ftsfind.c:279-280,find/ftsfind.c:273-276,find/ftsfind.c:375-378,,,"""starting_path_length"" variable need to reset every directory.",Moderately confident,,"First:Set breakpoint in ""visit"" function

After that:Set breakpoint in ""consider_visiting"" function

Finally:Check ""starting_path_length"" variable value ",,"Yes, in principle a tool might be able to explain this error.","We can check ""starting_path_length"" variable value by a push of button.",Slightly difficult,10 - 20 minutes,"reset ""state.starting_path_length"" to zero.",Moderately confident,It produce the result we expected.,,"No, there will never be a tool that can fix this error reliably.",A tool can never figure out the right location to fix this error.,5 to 10 minutes
find.24e2271e,4/24/2016 8:50:30,NDM5MjVmOT,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",30 - 40 minutes,find/pred.c:712-717,ftsfind.c:278-279,find/pred.c:813,,,Directory part length conditionally set to state.starting_path_length structure (ftsfind.c:278-279). Condition requires that previous value must be 0u but this structure entry does not either zeroed or assigned new value after first use. So for each usage of that directory entry used incorrect path length value.,Extremely confident,,"First I ran program using gdb and caught stdout output of incorrect result. Inspecting local variables I guessed thatstate.starting_path_length value is wrong. Backtracing, I found function call history leading to that result. I found that conditional assignment to the structure entry requires its zero value. Using grep I found that this structure entry does not changed after that, so it never changed after first usage.",this bug is easy to find already,"No, there will never be a tool that can explain this error.",I see no way how to explain to a tool why given result is wrong. Although a tool can be used to explain why given structure element has exact value. ,Not at all difficult,1 minute or less,I disabled to check if this structure element has assigned some value already. I see no make use for that.,Very confident,It works. I am not fully sure if it has side effects.,,"Yes, in principle a tool might be able to fix this error reliably.","If there a way to explain to a tool what result we expecting, it could trace value assignment and usage to make proper way to assign correct value.",10 to 20 minutes
find.24e2271e,4/25/2016 19:24:51,NGU0NDRiM2,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",printf(),5 - 10 minutes,find/pred.c:588-597,find/pred.c:719-728,find/pred.c:819-830,,,"Did not count state.starting_path_length, and in find/pred.c:719-728 (case 'H') program setup 0 character to pathname (pathname[state.starting_path_length] = '\0';)",Moderately confident,,"Build in debug mode.
Manually create dir1, foo, directory2, bar directories.
Run './find dir1 directory2 -printf '%H %P\n' '
See the output
Understood that program setup null character to middle of string, somewhere in code.
Find all frpintf() calls in code
Find case 'H'
Write correct counting of state.starting_path_length in begin of owner function
Test it again",,"No, there will never be a tool that can explain this error.",,Slightly difficult,20 - 30 minutes,Write correct counting of state.starting_path_length before program is used it.,Moderately confident,Tests successfully finished,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.24e2271e,5/28/2016 2:39:40,NzBjMjQ0OT,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/ftsfind.c:687-689,find/ftsfind.c:383-405,find/ftsfind.c:374-376,find/ftsfind.c:277-280,,The problem was when a call to find() is made (find(argv[i]) in process_all_startpoints()) the state.starting_path_length was getting overwritten with the length of the current argument. Therefore I initialized the starting_path_length before find(),Extremely confident,,"Initially, I read the code manuallyto understand how the code worked. I delved deep into the find function and understood the problem.
Confirmed my observations using gdb.",,"No, there will never be a tool that can explain this error.",I cant figure out how this particular error can be diagnosed automatically,Not at all difficult,1 minute or less,"I initialized the path length before the call to find().
Otherwise the same length was being used for the next call as well",Extremely confident,Applied the patch. Verified the test cases. Seems to working as expected,,"No, there will never be a tool that can fix this error reliably.",I am not sure this particular error can be fixed when I am not even sure about the automatic diagnosis for this particular error :),10 to 20 minutes
find.24e2271e,7/23/2016 22:11:30,MzBiYjQ4ZG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdv,20 - 30 minutes,find/ftsfind.c:279,find/util.c:300,find/pred.c:709,find/pred.c:809,,I saw the code flow and understood from output of program that length is not getting updated after updating first time. so started searching for code that sets path length. and then I found that condition was wrong to update path length.,Extremely confident,,first I started with code flow and understood the error and then I trace down the exact place where path length was not getting updated.,,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,10 - 20 minutes,condition was mistakenly put so changed it.,Extremely confident,from provided and test script and from testing different functional impact.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.24e2271e,7/26/2016 20:39:51,ZTBjYWY1Nj,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb,grep",20 - 30 minutes,find/pred.c:716,find/ftsfind.c:130,find/ftsfind.c:278,,,The length of starting part of current path processed is not re-calculated correctly.,Slightly confident,,"I've found where the output of -printf predicate is being formed. Than I've noticed global variable state.starting_path_length and by printf-like tracing found out it was not set correctly. Further investigation led me to place where this field is filled, and I'm pretty sure it is inside too restrictive if; zero checking it seems to be excess.",,"No, there will never be a tool that can explain this error.",,Slightly difficult,1 minute or less,I've made sure length of first part of the path being processed is re-calculated correctly.,Slightly confident,I've just tested it works.,,"No, there will never be a tool that can fix this error reliably.",,30 to 40 minutes
find.24e2271e,8/1/2016 4:56:36,MTk0NjE0Mj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,pred.c:712,ftsfind.c:279,pred.c:579,,,state.starting_path_length is not reset if once set at ftsfind.c:279. Thus leading to wrong pathname cut at pred.c:712,Moderately confident,,"Set btakepoint at pred_fprintf(). pathname argument seems ok. Looked down to the %H handling, noticed that state.starting_path_length doesn't changed once set. Restarted and set wathcpoint at it. Noticed excessive optimization at ftsfind.c:279.",,"Yes, in principle a tool might be able to explain this error.",Maybe with a lot of fuzziness some bruteforce algorithm can manage to get correct output.,Not at all difficult,1 minute or less,"Removed excessive optimization.

Maybe.

I am not quite sure about this fix, but after slight looking around I don't see what it could break.",Moderately confident,It just seems ok for me and seems like doesn't brake anything.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.24e2271e,8/3/2016 15:52:54,ODY3ODM5YW,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,pred.c:712,ftsfind.c:278-279,pred.c:809,,,"If multiple directories are passed via command line, the statement in ftsfind.c:278 is incorrect. It will only be executed once because of the second term in the condition.",Extremely confident,,"1. run gdb set breakpoint on write
2. set bp on pred.c:591 and a few other. Did not help
3. add fprintf at pred.c:712 and pred.c:809
4. realise state.starting_path_length is the culprit
5. set watchpoint on state->starting_path_length
6. Found location ftsfind.c:279",state.starting_path_length is only set once,"Yes, in principle a tool might be able to explain this error.",state.starting_path_length is in effect const but is is used to index multiple different string. That smells.,Not at all difficult,1 minute or less,Remove the second term in the condition.,Extremely confident,"Tested with provided test case
Added more directories. Tested again.
Compared output to output of my system installed find.",,"Yes, in principle a tool might be able to fix this error reliably.",I think it is easy to detect. Tool could suggest to remove the second condition since this is the reason it only get set once. (Assuming it never gets set to 0),10 to 20 minutes
find.6e4cecb6 ,10/24/2015 18:30:38,ZDc4NDZjMm,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/find.c:1094,find/find.c:132,find/find.c:137,,,The ternary operator at find.c:1094 messes up the logic and sets the O_NOFOLLOW flag for files that should be followed.,Very confident,,"First look at the debug output to see the last line printed.
Next, use gdb to locate the region of code creating the error. 

Thereon I followed the code sequence logically till I came across the ternary operation. Upon checking the return code of the following_links() function, I realized the logical error and fixed it.",If I could find the location causing the issue faster since a grep for the output string returned nothing in the codebase. I had to follow it through gdb to find the location,"Yes, in principle a tool might be able to explain this error.","Although again, the tool would need to have domain knowledge and understand what we are really looking for. This should be possible since the issue was only a simple logic reversal. ",Not at all difficult,1 minute or less,"Reversed the logic in the operation, so O_NOFOLLOW is set correctly.",Very confident,"I haven't touched anything else. Only one logical line. However, due to time constraints, I did not check it for quality. Ona normal day, I would run regression tests to ensure that this does not break anything else.",,"Yes, in principle a tool might be able to fix this error reliably.","Given the root cause, it should be fairly simple.",5 to 10 minutes
find.6e4cecb6 ,2/2/2016 3:07:09,YTA2MTE4ND,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/find.c:1139-1157,find/find.c:1088-1109,find/find.c:1618-1645,,,"Error was in wrong interpretation of following_links() option in safely_chdir_nofollow() function. When they should be followed, they weren't and vica versa.",Slightly confident,,"1. breakpoint at `write` syscall to see where error message is output
2. check backtrace to find where an error was caused
3. investigate code logics",,"No, there will never be a tool that can explain this error.",,Not at all difficult,1 minute or less,inverted the condition checked to decide if we should follow links or not,Moderately confident,a few manual tests,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.6e4cecb6 ,2/2/2016 5:27:51,ZTk0ZThkOD,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",eclipse cdt,10 - 20 minutes,find/find.c:1618,find/find.c:1642,find/find.c:1094,,,extraflags variable wrongly calculated : result of logical operation was wrongly calculated,Moderately confident,,"1. set breakpoint on the beginning of  ""process_path"" function, make sure that continuing leads to error;
2. narrowing down error site by setting breakpoints on functions being called from ""process_path""  - ""process_dir"" in our case;
3. tracing ""process_dir"" - checking why ""safely_chdir"" returns errors and so on
4. finally found that faulty function is ""safely_chdir_nofollow"" as it wrongly calculates ""extraflag"" variable",,"No, there will never be a tool that can explain this error.",,Slightly difficult,10 - 20 minutes,"fixed result of logical operation  so it returns ""extraflag"" correctly",Moderately confident,"run test, run program manually and checked output",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.6e4cecb6 ,4/11/2016 5:18:34,ZmZkMWM5OG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/find.c:1470,find/find.c:1083-1086,find/find.c:1094,,,"This is an almost syntactic mistake. Arguments to operator ? was switched. After a directory appear, find change to this directory for further processing, see find/find.c:1470. To prevent race conditions with symlinks (which are not connected to this error!),  special flag O_NOFOLLOW is used. Because of mistake it was used wrong, i.e. used in the case it shouldn't be used and not used in the case it should be used. Compare comment in find/find.c:1083-1086 and original implementation in find/find.c:1094.",Extremely confident,,"I have traced program to see, where I get the line with error. I found out that open() in safely_chdir_nofollow() returns the error. Then I spent quite a lot of time, because I have not read the complete comment above the function and because I don't know anything about filesystems flags.",what is the meaning of O_NOFOLLOW,"Yes, in principle a tool might be able to explain this error.","Call to open() produces error. First, the problematic call must be indentified. Then the tool can show a trace to the wrong situation.",Not at all difficult,2 - 5 minutes,Swith arguments of operator ?.,Extremely confident,The code is now compatible with the given comment and the given description of the used flag. It work for test cases.,,"No, there will never be a tool that can fix this error reliably.",Only two arguments were switched. This looks simple but the tool does not know that the error happens just because of switched arguments. The tool should get a model of a correct behaviour but this is not applicable to such C projects.,20 to 30 minutes
find.6e4cecb6 ,4/20/2016 7:37:03,NDM5MjVmOT,Slightly familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",60 minutes or more,find/find.c:1097,find/find.c:1642,find/find.c:1618,find/find.c:132-144,,"Program tries to open dir file (find/find.c:1097) before change dir to that (find/find.c:1618). Program either passed O_NOFOLLOW flag to the open() system call or not depending on (-L,-H) options and current depth (find/find.c:132-144). But I noticed that flags is set to O_NOFOLLOW when following to links is need but it set to 0 when following symlinks is not required. So open() invoked with symlink and O_NOFOLLOW flag arguments causing error. ",Very confident,,"First I used gdb to run program with appropriate command line options. Using watch on stderr output, I find trace path which leads to error. It was the same for both -L and -H options. Looking through the code and use gdb with breakpoints, I found that error caused by invoking open() with symlink and O_NOFOLLOW flag. I was unsure about which one is wrong, trying to change dir to symlink regardless -H option or O_NOFOLLOW flag passed. Looking through the code for a long time I decided that flag value assigned by incorrect way. It is set to O_NOFOLLOW when following_links() returns 1.",unsure how a tool could help in that case,"No, there will never be a tool that can explain this error.","Formally, this is not a bug but it is a way how real program may work too. It is unusable only from a human point of view. Unsure if there may be a tool which can determine such kind of errors even we hand them with a lot of examples of correct output.",Not at all difficult,2 - 5 minutes,I passed correct flag depending on program internal state.,Very confident,"I did some tests, for example I passed '-H .' and '-L .' command line options for the test directory. Output was reasonable.",,"No, there will never be a tool that can fix this error reliably.","As I said in diagnose part, a program logic could not determine if program works correctly or wrong in this case, so it could not make guess what and how it have to fix.",10 to 20 minutes
find.6e4cecb6 ,4/27/2016 3:23:51,NGU0NDRiM2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",50 - 60 minutes,find.c:1089-1136,find.c:1094-1094,find.c:1097-1097,,,Wrong conditional,Moderately confident,,"Build in debug mode
Debug step by step
Find suspected place in code
Fix it",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,Fix conditional,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.6e4cecb6 ,5/28/2016 16:20:59,NzBjMjQ0OT,Moderately familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/find.c:1213-1276,find/find.c:1140-1158,find/find.c:1094-1096,,,"Basically when the following_links() was returning true, the flag (extraflag ) O_NOFOLLOW was being set and hence the sym link was not being followed. 
Copying the comment from the source code below
""We use open() with O_NOFOLLOW, followed by fchdir().  This ensures
that we don't follow symbolic links (of course, we do follow them
if the -L option is in effect).""",Extremely confident,,"As always, I used GDB to understand the code execution and tried to understand why the symlink was not being traversed. I analysed the variables in the process and understood that the flag ""extraflag"" was not being set properly.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,1 minute or less,I changed the ternary condition to set the extraflags to O_NOFOLLOW only when the following_links() returned false and 0 if the following_links() returned true.,Extremely confident,Applied the patch. Verified the correctness.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.6e4cecb6 ,8/1/2016 22:05:56,MTk0NjE0Mj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find.c:1618,find.c:1094,find.c:1102,,,safely_chdir_nofollow() returns SafeChdirFailSymlink at find.c:1618. Because of O_NOFOLLOW flag passed to open() it return ELOOP find.c:1102 . This flag is selected at find.c:1094 by mistake.,Moderately confident,,"gdb brake at error() gave me the exit point here find.c:1642. Status was SafeChdirFailSymlink. I read the comments for safely_chdir_nofollow() that says that we should in fact follow symbolics links and do not use O_NOFOLLOW in case of -L (or -H with state.curdepth==0). Thus I decided that that trinary operator was wrong.
I have been refusing to believe in such a silly mistake. But I can't find any other more plausible causes of this bug.",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,Fixed incorrectly composed trinary operator.,Moderately confident,"Spent some time thinking on it.
Couple of tests.",,"Yes, in principle a tool might be able to fix this error reliably.",One line fix. seems easy for some fuzzy testing algorithm which knows that humans can make such a silly mistakes.,10 to 20 minutes
find.6e4cecb6 ,8/3/2016 12:20:16,ODY3ODM5YW,Slightly familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find.c:1637-1646,find.c:0,find.c:0,,,"I think there is only one interesting location find.c:1637-1646. The other 2 are garbage. Had to fill in something because required fields. Now I am wondering whether my understanding is correct.

If we fail to change into the directory, we print an error. Thats not correct if it is a symlink.",Moderately confident,,"1. gdb with bp on write
2. Found find.c:1642 on the call stack
",,"No, there will never be a tool that can explain this error.",I think this bug is largely due to user expectations. Yes in theory a tool could detect it if you capture all user expectations. That would mean a error free specification. That is impossible.,Slightly difficult,5 - 10 minutes,If it is a SafeChdirFailSymlink just return.,Moderately confident,"Reasoning about code
Run test case
",,"No, there will never be a tool that can fix this error reliably.",Compare comment about whether we are able to detect this error.,5 to 10 minutes
find.c8491c11,1/30/2016 2:47:29,YTA2MTE4ND,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find/parser.c:1274-1277,find/parser.c:1215,find/parser.c:1362,,,array bounds were not checked,Extremely confident,,"1. trace segfault
2. check source code of the last called function to look for an error (wrong)
3. check source code of `find/parser.c:1362` as the last function called from files in ./find/ tree
4. observe value of argc and argv variables at `find/parser.c:1362` for zero
",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,check for absence of argument. this patch of code was just copy-pasted from above of the same function.,Extremely confident,a few manual tests,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.c8491c11,1/31/2016 23:37:37,ZTk0ZThkOD,Slightly familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,5 - 10 minutes,find/parser.c:1357,find/parser.c:1350,find/parser.c:1351,,,"function 'fatal_file_error' called at parser.c:1357 with null pointer as filename, that causes segfault in library function 'quotearg_buffer_restyled'; Root cause of errors is in between parser.c:1350 and parser.c:1357 - code doesn't check if -neverXX followed by argument",Very confident,,"1. start program ""find -nevercc"" under gdb
2. see it crashed with segfault
3. examine stack trace",,"No, there will never be a tool that can explain this error.",,Moderately difficult,20 - 30 minutes,added check for null argument of -newerXX option,Very confident,"run the test;
run the program manually",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.c8491c11,3/15/2016 5:25:13,OTcyZjg1Mz,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/ftsfind.c:690-693,find/tree.c:1240-1245,find/parser.c:1269-1376,,,Index out of bounds used when accessing array of args at find/parser.c function parse_newerXY(). The variable arg_ptr reachs the value 2 that is out of bounds (we only have argv[0] and argv[1]),Very confident,"The ugly code again, it is hard to follow and understand","First I run the SEGV with gdb
Obtained the point where it fails and its stack
Then a moved backwards to reach the function that generates the failure and is calling the others with bad arguments",Out of bounds index at function XXX,"No, there will never be a tool that can explain this error.",It is complicated to get such a tool that undertands the human coding errors,Slightly difficult,20 - 30 minutes,"Added indexed value checking to ensure that we do not use out of bounds arrays and return correctly the expected error when no arg is supplied:

Now we return:

./find: missing argument to `-newercc'

instead of giving a SEG violation",Very confident,"Did regression tests using examples supplied

./find -newercc 
./find -newermm

...

","Again and of course from my opion, the code is the worst to solve this (just my personal opinion after many years of C coding). The complexity of the code makes it a ""jungle"" for everybody trying to solve bugs.","Yes, in principle a tool might be able to fix this error reliably.",Maybe a tool that checks out of bounds condition y arrays could solve this.,20 to 30 minutes
find.c8491c11,4/13/2016 6:25:26,ZmZkMWM5OG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/parser.c:1352,find/util.c:896,find/util.c:887,,,"For -neweraa, function parse_newerXY expect a file as the next argument. The root cause for the error is a missing check if the next argument exists and thus function optionp_stat (which is used if -P) at find/parser.c:1352 fail. Probably, it was expected that a call to fatal_file_error() in the next line will properly report the error, but this is not hapening. Function fatal_file_error()  will delegate a work to a function quotearg_n_style() which is outside of this project, see find/util.c:896 and find/util.c:887, and which does not correctly work for an empty argument.",Very confident,,"First, I find out, that segmentation fault is happen in the file which is outside the project. Thus I have to trace the program from start to find a problematic call. On this trace I have not found any possibility to get the correct result by adapting some variables. Thus I claim, that some code is missing.",,"Yes, in principle a tool might be able to explain this error.",For segmentation faults we could get a trace which is some kind of error explanation.,Moderately difficult,5 - 10 minutes,I have properly catch the bad situation when an argument is missing.,Very confident,Test cases pass.,,"No, there will never be a tool that can fix this error reliably.",Until the tool does not know that some arguments for system calls are wrong it is not able to check and repair them.,20 to 30 minutes
find.c8491c11,4/14/2016 18:51:42,MGJmMTU1N2,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,snavigator",5 - 10 minutes,find/util.c:893,find/util.c:895,find/util.c:897,,,invalid formatting of a printf-like message. less arguments than expected,Moderately confident,,"ran in debugger, checked the code for dangerous situations","no, I understood quick enough","Yes, in principle a tool might be able to explain this error.",crashes are easy to catch,Not at all difficult,5 - 10 minutes,"added a case when less arguments are sent, a valid error message is still printed",Moderately confident,ran the code,,"No, there will never be a tool that can fix this error reliably.","the exact error message to be printed is a convention and cannot be computed, really",5 to 10 minutes
find.c8491c11,4/15/2016 13:52:51,ZTRmYWE5Nj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/parse.c:1356-1357,quotearg.c:249,find/parse.c:1315,,,null pointer,Slightly confident,,"First:set breakpoint in ""main"" function
then debug it.",,"Yes, in principle a tool might be able to explain this error.",A tool can check the NULL pointer error.,Moderately difficult,10 - 20 minutes,change null-pointer to non-null pointer,Not at all confident,"test it,no segmentation fault.",,"No, there will never be a tool that can fix this error reliably.",It is hard for a tool to figure out the error code location.,10 to 20 minutes
find.c8491c11,4/24/2016 9:33:55,NDM5MjVmOT,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",2 - 5 minutes,find/parser.c:1315,find/parser.c:1356,find/parser.c:1357,,,"Arguments array index is increased at (find/parser.c:1315). If -newerXY is last command line argument, increased value is NULL. There are no NULL check for that case. It tried to use at find/parser.c:1356 as stat() argument and after stat() failed it tried to print out error message but failed due NULL argument.",Extremely confident,,"I ran program using gdb. After it segfaults, I see that it already trying to complain an error but NULL argument passed to error output function. That is why segfault happens. Browsing source code I guessed why there are NULL value. ",this bug is easy to find already,"Yes, in principle a tool might be able to explain this error.",NULL pointer dereference is easy to trace.,Not at all difficult,2 - 5 minutes,I added NULL pointer check and corresponding error message output.,Extremely confident,"It is simple and obvious. Only test input value, print message and quit if something wrong.",,"Yes, in principle a tool might be able to fix this error reliably.",NULL pointer tracing is simple enough. Apparently a tool can not compose correct human-readable error message. ,10 to 20 minutes
find.c8491c11,4/25/2016 22:25:28,NGU0NDRiM2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",40 - 50 minutes,quoteargs.c:249-249,parser.c:1269-1269,parser.c:1315-1315,,,Do not check for number of arguments,Moderately confident,,"Manually test
Debug
Find segmentation fault
Step up in stack trace
Find parse_newerXY
Read parse_newerXY",,"Yes, in principle a tool might be able to explain this error.",Trace arguments count,Not at all difficult,2 - 5 minutes,Check for argument count,Moderately confident,Test successfully finished,,"Yes, in principle a tool might be able to fix this error reliably.",Trace arguments,10 to 20 minutes
find.c8491c11,5/27/2016 3:51:25,NzBjMjQ0OT,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find/parser.c:1311-1317,lib/quotearg.c:248-250,find/parser.c:1267-1270,,,The code was trying to deferencing a null pointer and hence the segmentation fault. This happens when -newerXY is not supplied with an argument.,Extremely confident,,"First, I used gdb and found out that the issue was related to null pointer being accessed. 
I backtracked the code to understand which pointer was responsible for this.
",,"Yes, in principle a tool might be able to explain this error.",The tool can tell if any of the pointers are pointing to NULL at any point of time during the execution . This will help in case of seg faults,Not at all difficult,2 - 5 minutes,I add a condition to increment the arg_ptr only when the *arg_ptr + 1  was not NULL.,Extremely confident,Applied the patch. Verified the patch. Seems to be working as expected.,,"Yes, in principle a tool might be able to fix this error reliably.","Similar to the answer that I have put in bug diagnosis, this can be probably done if you know that a pointer is pointing to NULL and going to be accessed in the future without modification.",10 to 20 minutes
find.c8491c11,7/24/2016 1:25:45,MzBiYjQ4ZG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf",30 - 40 minutes,find/utils.c:898,find/parser.c:1313,find/parser.c:1319,,,case not handled. Null value check was missing.,Very confident,,"first started with gdb,then I tried to put prints and found that case was not handled at some places. ",,"Yes, in principle a tool might be able to explain this error.",,Very difficult,20 - 30 minutes,handled null case.,Very confident,by running provided test script and checking other function impact.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.c8491c11,7/24/2016 18:02:16,ZTBjYWY1Nj,Not at all familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,1 minute or less,gnulib/lib/quotearg.c:249,find/parser.c:1358,find/ftsfind.c:693,,,"When parsing command line parameters to the program at first region, it comes down to escaping filename being passed as argument to -newer option (at second region). The function that does actual parameter escaping (third region) does not check the absence of parameter and so dereferences null pointer.",Very confident,,"I've started by searching the code path that parses -newer argument, but thought that would be too difficult, because it is done with pointer-to-function magic. So then I've turned on core dumps, made program segfault and ran gdb on coredump. The rest was easy - I've just read the code and comments of function on top of stack (which was quotearg_buffer_restyled).","If I was told that command line parser of find is so complex, I've run gdb instantly instead of trying to understand its code.","Yes, in principle a tool might be able to explain this error.","It would be simple for some tool (e.g. clang-like analyzer) to ""understand"" that the faulting function, quotearg_buffer_restyled, does not check the actual presence or abstence of its parameter that needs quoting.",Slightly difficult,20 - 30 minutes,"Bug was not precisely where I thought it was. The actual error was when find was trying to output error with filename which was null pointer, without even addressing situation when user missed filename parameter for -newer argument. I've made sure that when outputting filename it is not a nullptr.",Moderately confident,I've pinpointed where the bug originates and checked several situations it might occur (e.g. different -newer flags).,,"No, there will never be a tool that can fix this error reliably.","There would be hard for automated tool to ""understand"" where in the long call stack null pointer arguments are allright, and where not.",5 to 10 minutes
find.c8491c11,8/1/2016 5:31:55,MTk0NjE0Mj,Not at all familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,parser.c:1360,parser.c:1360,parser.c:1360,,,Segfault deep inside fatal_file_error() just because the passed pointer to the filename was 0 at parser.c:1360. parse_newerXY() does not check for existence of it's argument.,Very confident,,bt in gdb pointed me at parse_newerXY(). After that I realized that there is no check for the argument to -newerXY predicate.,,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,Added check and error message for an argument to -newerXY predicate.,Very confident, ,,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
find.c8491c11,8/2/2016 15:56:39,ODY3ODM5YW,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,quotearg.c:249,quotearg.c:667,util.c:896,,,There is an OOB access in quotearg.c:249 on arg. arg is NULL,Moderately confident,,"1. gdb
2. bt
3. look at code (could have skipped in retrospect)
4. look at call tree
5. use gdb to print arguments across multiple frames
6. verify by printing arg in quotearg.c:249",arg is NULL,"Yes, in principle a tool might be able to explain this error.","Straight forward bug. If you look at the loop and know that there is a NULL pointer, it is easy to see the problem.",Slightly difficult,5 - 10 minutes,"Check for NULL, pass """" if NULL",Moderately confident,Run the test case. Probably could have done better but objective was to pass the test case so that's what I did.,,"Yes, in principle a tool might be able to fix this error reliably.","The call to safely_quote_err_filename fails with an OOB access. The result is a const char*. Checking for NULL and replacing with a """" seems to be straight forward and probably correct in most cases that I can think of.",10 to 20 minutes
find.07b941b1,10/24/2015 21:24:51,ZDc4NDZjMm,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find/parser.c:926,find/parser.c:1644,find/parser.c:1645,,,The root cause is simple. It is an increment of the operator before its use.,Extremely confident,,"I recompiled the program with debugging symbols included. Then I ran the executable under gdb and noted the backtrace. 
Next, I tried understanding the scope of the problem by manipulating the arguments. This shows that the issue occurs on any regex. Irrespective of the correctness of the expression or the existence of the file on disk.

Next, I followed the backtrace till I saw that the argument pointer (*arg_ptr) was incremented just before it's use. Changing its location fixes the problem","If I knew that the issue lay entirely in the regex parser alone, I wouldn't have tried to localise it first.","Yes, in principle a tool might be able to explain this error.",Yes. Since this issue is indeed quite simple. An argument that changes before its old value is used causing a fault. Should be able to write up a generic rule to identify this,Not at all difficult,1 minute or less,Changed the location of the increment so that it increments *after* the value is used,Extremely confident,"Ideally, I'd like to run a regression test suite. But we seem to lack those on the repos provided. 

However, the fix is simple enough that I'm intuitively confident about it.",,"Yes, in principle a tool might be able to fix this error reliably.","Yes. As reported earlier, this should be relatively simple.",less than 5 minutes
find.07b941b1,1/29/2016 4:48:35,YTA2MTE4ND,Not at all familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",gdb,2 - 5 minutes,find/parser.c:1644-1645,find/parser.c:924-926,find/parser.c:924-926,,,"In find/parser.c:1644-1645 arguments pointer `arg_ptr` was accidentally incremented before using it with `estimate_pattern_match_rate` function call, and it went out of array bounds.",Extremely confident,,"1. I've found the place where segfault happens with gdb.
2. I randomly checked the only variable there for zero value. It turned out to be zero.
3. Backtraced calling functions to the place where this value was used.
4. Found that some pointer is incremented before being used.
5. Tried to swap those lines and succeeded with test.",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,I swapped wrong-ordered lines.,Extremely confident,Run a few tests manually,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.07b941b1,1/31/2016 22:50:40,ZTk0ZThkOD,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,5 - 10 minutes,find/parser.c:1644,find/parser.c:1644,find/parser.c:926,,,"variable pointed by arg_ptr increased before estimate_pattern_match_rate function called, this function doesn't check input",Very confident,,"1. run 'find -regex '.*' under gdb
2. see it crashed
3. check the backtrace",,"Yes, in principle a tool might be able to explain this error.",probably this can be checked by source code analyzer ,Slightly difficult,10 - 20 minutes,"moved ""increase arg_ptr"" variably after estimate_pattern_match_rate function call",Moderately confident,"1. run test case; 
2. run fixed program and checked output",,"Yes, in principle a tool might be able to fix this error reliably.",probably with help of static code analyzers it's possible,5 to 10 minutes
find.07b941b1,3/15/2016 23:29:27,OTcyZjg1Mz,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/main.c:465-466,find/tree.c:1322-1323,find/parser.c:1645-1646,find/parser.c:926-927,,The arg counter is increased before the expected position. It should be increased after calling the function estimate_pattern_match_rate() and not before as it is done,Very confident,Nothin,"Firstly I launched de debugger and obtained the point where it crahes:

Program received signal SIGSEGV, Segmentation fault.
estimate_pattern_match_rate (pattern=0x0, is_regex=1) at parser.c:926

Then we see , that it is receiving a NULL.

Then we see that pointer is out of range at insert_regex() function line 1645

This value is increased before calling the function and pointing to invalid memory. 

Checking the rest of calls I understood that this step must be done after calling the function and not before, we must pass the regex pattern and not the next arg
",Array out of bounds,"Yes, in principle a tool might be able to explain this error.","Again if we can make something that detects arrays out of bounds we can catch this type of errors, knowing that we are pointing to something out of the original array size",Slightly difficult,10 - 20 minutes,"Changed the order of the statements, increment must be done after calling the function, this way we pass correctly the regex pattern",Very confident,"Run test.sh against new binary, execute it in command line with new binary generated",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.07b941b1,4/11/2016 15:05:23,ZmZkMWM5OG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",20 - 30 minutes,find/parser.c:1644-1645,find/parser.c:1615,find/parser.c:926,,,"For -regex the program search for one argument.  This is done by calling parse_regex, see find/parser.c:1615. The work is then done in insert_regex() but near the end, see find/parser.c:1644-1645, there is an error. Variable arg_ptr is incremented and therefore
strpbrk in find/parser.c:926 gets NULL insted of pattern.",Extremely confident,,"First I found, that using -regex segmentation fault appear in strpbrk which is called from parse_regex. Then I traced why it gets NULL and notice the incrementation of  arg_ptr. I commented it out and there was no segmentation fault.",,"Yes, in principle a tool might be able to explain this error.","As for any segmentation fault, debuggers already give you a trace, which is a kind of explanation.",Slightly difficult,5 - 10 minutes,I have moved a line which increments a variable to be executed later than in the original solution.,Extremely confident,"First, I try to remove the problematic line. But the results was wrong. Because I am slightly familiar with the code (after solving 8 problems :-) I know that arguments are usualy consumed thus I put the incrementation back but on different place. Test cases are now working.",,"No, there will never be a tool that can fix this error reliably.",This is about changing a functionality and I think that repairing it is the same as creating new functionality from the given traces. This is not applicable to such C-projects.,20 to 30 minutes
find.07b941b1,4/14/2016 16:57:49,ZTRmYWE5Nj,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find/parse.c:1644,find/parse.c:1645,find/parse.c:926,,,"strpbrk(pattern, ""."");

strpbrk function first parameter must not be NULL pointer,otherwise Segmentation Fault.",Very confident,,"First:Run gdb debugger

Second:Get the message ""Program received signal SIGSEGV, Segmentation fault.
estimate_pattern_match_rate (pattern=0x0, is_regex=1) at parser.c:926""

Third:Read parser.c line 926",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,change null pointer to Non-NULL pointer.,Moderately confident,"I run the find command,no segmentation fault error occured.",,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.07b941b1,4/14/2016 18:30:04,MGJmMTU1N2,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,snavigator",5 - 10 minutes,find/parser.c:1640,find/parser.c:1574,find/parser.c:1648,,,"consuming the regex argument too lazily. after use of a command line parameter, the index of the current parsed argument was not incremented",Moderately confident,,"gdb run to reproduce crash
then a look in parse/insert_regex
then a gdb session to see what runtime values appear
",not sure,"Yes, in principle a tool might be able to explain this error.",at least some vague explanation about the error and a source code region to look at could be a good hint/starting point,Not at all difficult,5 - 10 minutes,incremented the positional argument index and checked it against null before deffering,Moderately confident,rerun in debugger to make sure the code runs as expected/variables have the intended values,,"Yes, in principle a tool might be able to fix this error reliably.",at least an indicative error message for the crash could be useful,5 to 10 minutes
find.07b941b1,4/19/2016 1:35:36,NDM5MjVmOT,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",40 - 50 minutes,find/parser.c:1644-1645,find/parser.c:926,find/tree.c:1322,,,"Index of array increased before using element of array it points to. Element of array must be used at find/parser.c:926 invoked from find/parser.c:1644-1645. Arguments counter must be increased after element value used. In test case used for this study, it is last argument in arguments list. That is why next vaue does not exists and segfault caused by passing NULL to a function. NULL is invalid argument for strpbrk() causing segfault. I believe if there will be more arguments in command line after -regex x, then no segfault will happen but program will not work correctly anyway. Although I did not tested that.",Extremely confident,,"By using bash trace ability I determined command line caused segfault. Next I ran program using gdb with given arguments. When I got segfault, I checked local variables values to determine what value caused segfault. Next I used backtrace to determine way how this variable got such value. By using common sense I decided that array index variable arg_ptr value is +1 larger than ough to be. Considering this value must be increased only at very end of function to prepare work on the next command line argument, I decided that lines with function call and index increase (find/parser.c:1644-1645) are follows in wrong order.",,"Yes, in principle a tool might be able to explain this error.","Although this bug is very easy to locate and fix by a human, I believe it will be challenge for any automated tool. First, diagnostic tool must guess what argument value must be passed to segfaulthy function actually. Second, diagnostic tool must have common sense about high leveled blocks of operations. In this case it will be order similar to: (get option such like -regex, increase index, get argument corresponding to command line option, increase index) repeating for each command line option. Such strict order corresponding to human-like ability of decomposition. It reflects way of thinking used by a human due human used strict such order to avoid to be lost in minds. So diagnostic tool must know human psychology to use this knowledge for determining how the things must go actually. This is very complex task, but it looking doable in principle.",Not at all difficult,2 - 5 minutes,I did swapped two lines to let program use array value before increasing index pointed to that value.,Very confident,I did some runs with various -regex options. It seems it worked correctly with all cases.,,"Yes, in principle a tool might be able to fix this error reliably.","I did some explanations in diagnostic part of this study. For this bug, way to fix it goes directly from way to diagnose it.",10 to 20 minutes
find.07b941b1,4/26/2016 20:17:20,NGU0NDRiM2,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/parser.c:1644-1645,find/parser.c:926-926,find/parser.c:1644-1645,find/parser.c:1619-1646,,Increment index too early,Moderately confident,,"Debug with gdb
See that arg_ptr is too big
See to stack trace
Find suspect place in code
Fix it",,"No, there will never be a tool that can explain this error.",,Slightly difficult,2 - 5 minutes,Move incrementing of arg_ptr to later place in code,Moderately confident,Test finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.07b941b1,5/27/2016 5:07:06,NzBjMjQ0OT,Moderately familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,10 - 20 minutes,find/tree.c:1320-1322,find/parser.c:1621-1647,find/parser.c:924-935,,,"A null pointer was being passed (assuming no of arguments as 3) to estimate_pattern_match_rate.
The arg_ptr was incremented before it was sent to the above function and hence the segfaults",Extremely confident,,"First, I tried to understand which function was failing. I took a little longer time since I got confused in the build_expression_tree() because one if condition on i++ was missing. I thought the value of i was getting incremented and being sent but it was not the case. 
I later saw the *arg_ptr++ before the call to estimate_pattern_match_rate() and concluded my diagnosis.",,"Yes, in principle a tool might be able to explain this error.",This answer would be the same as my answer for find.c8491c11(find14),Not at all difficult,1 minute or less,I put the line *arg_ptr++ which was before the call to estimate function after that function.,Extremely confident,Applied the patch. Verified the output.Working as expected,,"Yes, in principle a tool might be able to fix this error reliably.","As I have mentioned, a tool may tell you that a null pointer is being passed to a function but I am not sure how reliable fixing this error would be.",10 to 20 minutes
find.07b941b1,5/27/2016 16:55:42,NTU0ZTZlNT,Not at all familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,find/parser.c:1621,find/tree.c:1496,find/parser.c:1644,,,"- region3:  the arg_ptr value points to a nonexistent array element already
- region1:  there's no mechanism to properly advance the arg_ptr value
- region2:  the -regex predicate maybe processed as one of the first ones leading to inefficient execution of the binary",Extremely confident,,"1. understand the arguments used by the binary especially with how the predicates play within them
2. understand execution priorities of the predicates",predicates are used as what I've discovered,"No, there will never be a tool that can explain this error.",detection of incorrect usages of predicates is hard to locate,Moderately difficult,20 - 30 minutes,- advance arg_ptr value only at the right place,Extremely confident,ensure result of test/test.sh is 0,,"Yes, in principle a tool might be able to fix this error reliably.",advancing arg_ptr value could be inserted in the code correctly.,10 to 20 minutes
find.07b941b1,7/25/2016 3:00:00,MzBiYjQ4ZG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,printf",20 - 30 minutes,find/parcer.c:1646,find/parcer.c:1640,find/parcer.c:1641,find/parcer.c:1615,,Passing pointer argument was not in correct way.,Very confident,,first looked with gdb but didnt help so started putting prints. finally found the place where it was crashing. Found that pointer was not passed properly.,,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,passing pointer in correct way as an argument.,Slightly confident,by running provided test script and understanding functional impact.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.07b941b1,7/26/2016 19:55:06,ZTBjYWY1Nj,Slightly familiar,Not at all difficult,Post-Mortem or Offline Debugging (using core dumps and stack traces),gdb,2 - 5 minutes,find/tree.c:1322,find/parser.c:1646,find/parser.c:926,,,The cause of error is trying to estimate pattern match rate with corresponding function called with incorrect pattern argument.,Very confident,,I've examined core dump and then examined closely the function from which the faulty function was called.,,"No, there will never be a tool that can explain this error.","How in the heavens an automated tool would know where arg_ptr should be incremented? Again, to do so, this tool should somehow ""know"" semantic of program in question.",Not at all difficult,1 minute or less,I've made sure pattern match rate estimation is called for right thing.,Very confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.07b941b1,8/1/2016 5:40:20,MTk0NjE0Mj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,1 minute or less,parser.c:1644,parser.c:1644,parser.c:1644,,,Weird premature increment of *arg_ptr at parser.c:1644. After increment it starts to point to 0 and used in estimate_pattern_match_rate().,Very confident,,gdb backtrace. Up to an insert_regex() function.,,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,Moved increment of the variable to a proper place.,Extremely confident,Looks good and I can't imagine other reasons that influenced this bug.,,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
find.07b941b1,8/12/2016 11:08:47,ODY3ODM5YW,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,parser.c:926,parser.c:1643-1644,noother.c:0,,,"NULL pointer access at parser.c:926
",Extremely confident,,"Run gdb and bt -> find parser.c:926
",,"Yes, in principle a tool might be able to explain this error.",Because it is a NULL pointer,Slightly difficult,5 - 10 minutes,Moved the increment of arg_ptr after the last use.,Extremely confident,"Added some logging
Ran a few times.
Seems to be trivial fix that does not require much testing.",,"No, there will never be a tool that can fix this error reliably.","I am not sure. This is a NULL pointer so it is trivial to find. Fixing it is a different story, because it might well be that the increment of arg_ptr before the call to estimate_pattern_match_rate is intentional. Since pattern is not OOB it is not immediately clear that the increment is wrong.",10 to 20 minutes
find.ff248a20,10/24/2015 19:37:20,ZDc4NDZjMm,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/find.c:1428,find/find.c:1428,find/find.c:1428,,,"The logic to ensure that the we do not follow into the same directory seems to be checking the inode of the symlink itself. If it followed into the symlink, it would realize that the two inodes are the same and would not drop in again.",Moderately confident,,"First get the debugging version of find. With the debug output, take a look at what is repeatedly printed. This is what will lead us to the infinite recursion. 

Next, grep for the string being repeated. This leads to the process_path() function. Here on reading the code, line 1428 seems to be the one creating the error",,"Yes, in principle a tool might be able to explain this error.","*might* be possible. Here, I needed the semantic information that a symlink has its own inode. If the tool has such domain knowledge, it would be possible.",Very difficult,5 - 10 minutes,"I have a good understanding of the bug, but I haven't been able to track down the exact source and fix it. Given more time, I would.",Not at all confident,"I was unable to fix it, since the code deals with a layer fairly below what I'm used to working with. I'd require a little more time and patience to look into this and figure out the exact issue.",Mentioned above,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.ff248a20,2/2/2016 5:43:49,YTA2MTE4ND,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/find.c:1428-1434,find/find.c:1432-1443,find/find.c:1621-1622,,,"dir_ids[dir_curr] array is used to track directories which were already seen on current branch.

at find/find.c:1428-1434 current file is checked to be already traversed through

at find/find.c:1432-1443 current file is added to the list as being traversed currently

at find/find.c:1621-1622 that data is overwritten with some other value",Very confident,,"1. i executed infinite loop in gdb, and broke it at random point.
2. checked which functions are called repeatedly (process_dir and process_path)
3. investigated those functions and found a piece of code responsible for  checking for infinite recursion: find/find.c:1428-1434
4. with gdb, inspected values of dir_ids array and found that they are overwritten somewhere before the next check
5. found all places where dir_ids are changed. There was only one such place besides find/find.c:1432-1443 and it didn't seem to make sense",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,10 - 20 minutes,Extra overwriting of dir_ids is removed,Not at all confident,"I did a few manual tests. Although I'm not sure if this fix is correct, but at least it solves the issue. Probably, further testing should be done to find another bug related to this fix.",,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
find.ff248a20,3/19/2016 19:22:08,OTcyZjg1Mz,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",20 - 30 minutes,find/find.c:1428-1434,find/find.c:1428-1443,find/find.c:1471-1471,find/find.c:1621-1622,,"Array of values we store to detect loop condition at section 2 is corrupted due to wrong index management at section 4. 
At this array we keep track of the entries already visited to detect loop condition and once inserted the link entry, section 4 corrupts it making it impossible to detect at comparison",Moderately confident,,"First a looked for the code that detects loop condition (expected result)
Then I found the function issue_loop_warning()
Studied the conditions when this function is called and how we store information of every entry already visited at array and how we compare this array with next entry visited
Then using debugger detected that entry is stored correctly but somehow it is then modified/corrupted
Then found the reason at section 3 and 4, we decrease index and then we do not increase it again when filling info.",Array corruption,"No, there will never be a tool that can explain this error.","Again it is something related with the code itself and how the function is implemented, we decrease the counter and then we have to remember to increase it, difficult to detect and explain",Moderately difficult,5 - 10 minutes,Fixed wrong array index management when filling information,Moderately confident,"Run test case again

/root/Desktop/find8/test/test.sh /root/Desktop/find8/find
/root/Desktop/find8/find/find/find: Symbolic link `/tmp/tmp.FhGSsFg07f/symlink' is part of a loop in the directory hierarchy; we have already visited the directory to which it points.

root@carlos-ubuntu:~/Desktop/find8# echo $?
0

Repeated the actions that previously lead to infinite loop
Generated some new scenarios to check that the normal case is working (no infinite loop there)

Like normal links like this (some regression):

NORMAL LINK

carlos@carlos-ubuntu:~/debugstudy/debugstudy/source_find/find8/find/find$ ./find testingfindagain -follow
testingfindagain
testingfindagain/b
testingfindagain/a

LOOP LINK SCENARIO

carlos@carlos-ubuntu:~/debugstudy/debugstudy/source_find/find8/find/find$ ./find testingfindagain -follow
testingfindagain
testingfindagain/b
testingfindagain/a
./find: Symbolic link `testingfindagain/c' is part of a loop in the directory hierarchy; we have already visited the directory to which it points.
testingfindagain/c


Compared execution with built-in find Linux command",,"Yes, in principle a tool might be able to fix this error reliably.","Maybe, if this tool can detect indexing changes and warns about the same",10 to 20 minutes
find.ff248a20,4/12/2016 2:55:07,ZmZkMWM5OG,Moderately familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/find.c:1611,find/find.c:1426-1434,find/find.c:1614-1623,find/find.c:1138-1150,,"The program supports two kind of system libraries and use #ifdef to choose the correct one, see find/find.c:1138-1150. After safely_chdir() at find/find.c:1611, one kind of system call needs some postcalculations based on the value of variable ""stat_buf"", see find/find.c:1614-1623, but this should not be done for the other one becuase variable ""stat_buf"" does not have the correct value. Because of missing #ifdef, the wrong value of ""stat_buf"" is used and then the lcurrent directoty is not correctly remebered. Finaly, the loop in find/find.c:1426-1434 is not able to detect symlink to the already visited directory.
",Very confident,,First I checked the part of the code which should write out the error. I have checked why this part of the code is not executed. I found the loop which compare the current dir with an array of already visited directories. Then I found out that this array has wrong values. Then I trace the program to find out where these wrong values come from. I found that place but I need some time to understand the error. The key was the comment before the code witch mentioned function wd_sanity_check(). I have found out that this function is invoked only for one type of system calls and thus the postprocessing should not be done for the other.,what is a valid range for dev and ino,"Yes, in principle a tool might be able to explain this error.","Well, because of the missing #ifdef, one variable is used uninitialized or with a value clearly out of the correct range. The tool could detect this and give you a trace.",Very difficult,60 minutes or more,I have excluded some part of the code if the particular system flags are defined.,Very confident,Test cases are working.,,"No, there will never be a tool that can fix this error reliably.",The tool cannot know why the variable with wrong value is used. Maybe the value should be initialized before the use or the variable should not be used at all.,30 to 40 minutes
find.ff248a20,4/19/2016 11:55:31,NDM5MjVmOT,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",60 minutes or more,find/find.c:1572,find/find.c:1428-1434,find/find.c:1442-1443,find/find.c:1621-1622,,"Program uses (inode, dev) pairs chain to identify path already visited (find/find.c:1442-1443). It performs check against new directory visited to prevent loops (find/find.c:1428-1434). Value of struct stat stat_buf (find/find.c:1572) used to overwrite (inode, dev) pair (find/find.c:1621-1622) but stat_buf is not initialized before this point, so it contains garbage data. That is why replaced values can not be used to identify path already visited.",Extremely confident,,"I ran program using gdb. By interrupting program execution after it goes to infinite loop, I determined infinite loop area. Obviously, this area must contain some conditions for leaving loop, but they don't make effect due a bug. Viewing source code I found guard code which have to prevent infinite loops (find/find.c:1428-1434). Tracing this code and watching variable values I noticed, that dir_ids[] array filled by correct values but those values are changed within next loop iteration. Using hardware watch ability of gdb, I determined point where new vaules assigned (find/find.c:1621-1622). Checking reason of new values, I found that those values goes from stat_buf but this structure is not initialized prior this point. So correct values were changed to garbage data.",Tools detecting uninitilaized data passing already exists,"Yes, in principle a tool might be able to explain this error.",Some tools such as Valgrind already can figure out bugs like that. I do not use them personally because I avoiding bugs like that but those tools may be useful for some cases.,Slightly difficult,2 - 5 minutes,"I did initialized structure so if it remains uninitialised before assigning its values, it does no-op as mentioned by remark at find.c:1619.",Very confident,It fixes problem and do not affect things which already works. Also I did some tests.,,"No, there will never be a tool that can fix this error reliably.","Although this bug can be detected easily by software analysers, unsure how a tool can guess which value must be passed to uninitialized structure. I see no criteria for program logic to determine particular solution is either correct or not.",5 to 10 minutes
find.ff248a20,4/25/2016 21:02:16,NGU0NDRiM2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",printf(),30 - 40 minutes,find/find.c:1442-1443,find/find.c:1461-1463,find/find.c:1621-1622,,,"In process_path() function we check for already passed paths and put new dirs to dir_ids, but in process_dir() we reassign latest dir_ids.",Moderately confident,,"Find error message
Find functions that must call function with error message
See how work process_path() and process_dir() functions",,"Yes, in principle a tool might be able to explain this error.","Trace global variables, such dir_ids and dir_curr.",Slightly difficult,5 - 10 minutes,Add increment of dir_curr before call to process_dir() and decrement of dir_curr after process_dir() call.,Moderately confident,Tests finish successfully.,,"Yes, in principle a tool might be able to fix this error reliably.",System can trace variables dir_ids and dir_curr.,10 to 20 minutes
find.ff248a20,5/29/2016 8:05:24,NzBjMjQ0OT,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/find.c:1427-1435,find/find.c:1462-1464,find/find.c:1610-1624,,,"After, analyzing for quite some time , I figured out that the issue_loop_warning() was not getting called. 
The issue was that a call to stat() was missing in the process_dir()",Extremely confident,,"After, analyzing for quite some time , I figured out that the issue_loop_warning() was not getting called. 
The issue was that a call to stat() was missing in the process_dir() .
Hence the dir_ids variable which helps in detecting if there is a loop or not was not getting initialized.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,20 - 30 minutes,"As I mentioned earlier, the status of the file was not being taken. This status was essential in determining the loop condition",Extremely confident,Applied the patch. Verified the correctness. Working as expected,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.ff248a20,7/27/2016 22:17:54,ZTBjYWY1Nj,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,10 - 20 minutes,find/find.c:1701,find/find.c:1463,find/find.c:1261,,,"When recursing to subdirectories (region 1), there is no checking for symlinks at all (along with funny source code comment about weird filesystems ""which don't have Unix-like directory link counts"").",Slightly confident,,"I've set stack limit to a low value (ulimit -s 32) and made program crash to get stack trace. Then I've examined it and found a place where, I think, there is missing check for symbolic links. Debug printing confirmed my guess.",,"Yes, in principle a tool might be able to explain this error.","The tool could in principle present a chain of calls which are looped infinitely, in an apprehensible way.",Moderately difficult,20 - 30 minutes,I've made an ugly hack to stop find from descent on a symlink loop and to show corresponding error message.,Not at all confident,"I've tested it, and well it works.",,"No, there will never be a tool that can fix this error reliably.",,more than 40 minutes
find.ff248a20,8/1/2016 6:59:37,MTk0NjE0Mj,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find.c:1442,find.c:1621,find.c:1123,,,"Already filled dir_ids at find.c:1442 gets overwritten by uninitialized values in process_dir() at find.c:1611.
safely_chdir() uses safely_chdir_nofollow() which, in turn, does not do any calls to stat() and just returns at find.c:1123.",Moderately confident,,"I found the string about warning in function issue_loop_warning() which is used only once in process_path(). Stepping through this function in gdb I noticed that dir_ids are changed after another round.
Making watchpoint at current dir_ids gives me a hint that it's changed in process_dir(). New stat values seemed ok (some members was like 27 or 17), so at first I thought that safely_chdir() actually calls stat and works as intended.
After some time I decided to check if stat values are in fact changed by safely_chdir(). Turns out it was not. I've added zero-initializer to this sctruct and simple checks for 0 before attempt to change dir_ids.
Maybe there is a better way of signalling about the fact that safely_chdir() haven't used stat(), but it requires to modify SafeChdirStatus enum and propagating all switches with new return values.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,Added check for the fact that safely_chdir() actually calls the stat().,Slightly confident,Nothing. Already spent more than 45 minutes for it.,,"Yes, in principle a tool might be able to fix this error reliably.",Do not use variables without initializing them. Maybe some tool can add a simple workaround for this (instead complaining like gcc). But I think it would be unreliable at most cases. Better fix such warnings with gcc's hints.,10 to 20 minutes
find.ff248a20,8/3/2016 11:28:37,ODY3ODM5YW,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",fprintf,20 - 30 minutes,find.c:1444,find.c:1623,find.c:1634,,,"While processing the path we set the inode and dev at find.c:1444
Then while processing the directory we check whether it is safe to change into the directory. If yes, we overwrite the indode and dev in the dir_ids array with the inode of the symlink.
",Moderately confident,,"1. grep for ""we have already visited the directory""
2. Look at find.c:1305. Search for uses of issue_loop_warning
3. Add fprintf for dir_ids in the loop
4. Inspect result, realise that it does not match
5. Add fprintf for all the locations in which dir_ids gets modified
6. Isolate likely cause at find.c:1623. esp in combination with find.c:1634. Looks fishy.
",That dir_ids get overwritten at find.c:1623,"Yes, in principle a tool might be able to explain this error.",A tool might need some help. Some hints to look at. But actually it seems like dir_ids gets written and then overwritten without a read in between. (I am not too sure about that) So this looks fishy and should be easy to catch. Especially if the developer indicates. an interest in dir_ids,Very difficult,20 - 30 minutes,"Set stat_buf.st_ino to -1
Only overwrite if stat_buf.st_ino was actaully set during the call to safely_chdir",Slightly confident,"Run test case, inspect output, reason about code",,"Yes, in principle a tool might be able to fix this error reliably.","Yes, I was stupid. Please refer to the initial bug description was is totally wrong. I did not change it, because I think you are probably interested in the fact that I totally misinterpreted the bug. This bug uses uninitialised memory. So it should be easy to detect.",30 to 40 minutes
find.e6680237,2/2/2016 7:59:47,YTA2MTE4ND,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,find/pred.c:626-633,find/pred.c:532,find/pred.c:543-549,find/pred.c:511-529,,"the working directory for -execdir option at variable execp->wd_for_exec was successfully initialized at first, but never updated after that",Extremely confident,,"1. inspect pred_execdir function responsible for -execdir child process execution.
2. take a look at record_exec_dir function and check with gdb whether it is executed or not on first and subsequent execdir runs.
3. the condition at find/pred.c:513 was false starting from second run",,"No, there will never be a tool that can explain this error.",,Slightly difficult,5 - 10 minutes,i fixed record_exec_dir function to update working directory record in execp struct unconditionally.,Moderately confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.e6680237,3/20/2016 20:14:49,OTcyZjg1Mz,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",60 minutes or more,find/ftsfind.c:332-539,find/pred.c:533-616,find/pred.c:511-528,,,We do not update correctly the current working directory PWD,Moderately confident,,"This took me a lot because I am not familiar at all with low level functions used to execute commands.

First I studied section 1 and checked that there visiting was done properly
Then I spent a long while debugging section 2 with traces and prinft, and debugger
Finally I found that section 3 does not allow to change directory due to initial condition (if statement)","Were clear, the difficulty was the code","No, there will never be a tool that can explain this error.","At all, I have spent many hours studying the low level functions, difficult for a button I think",Extremely difficult,60 minutes or more,Condition avoid to update current directory path,Moderately confident,"Repeated tests cases, tested against find built-it command",,"No, there will never be a tool that can fix this error reliably.","This made me sweat, I think that it is too difficult for a tool/button",more than 40 minutes
find.e6680237,4/10/2016 3:18:01,ZmZkMWM5OG,Moderately familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/ftsfind.c:198,find/pred.c:523,find/pred.c:513,,,"For -execdir the command must be executed in working directory. There is an element wd_for_exec, which is used to denote working directory. When apply_predicate, see find/ftsfind.c:198, is called for element in different directory as in the previous call, this should be set to 0 to request call of ""openat"", see find/pred.c:523 which will update working directory. Decision about the need for the update is done in find/pred.c:513.
",Very confident,,"First I found out that in apply_predicate() the name of file and dir is correct. Then I try different examples using -execdir, -exec, and -okdir and find out, that only *dir variants are wrong. I noticed the part of the code which should change working dir and research why it is not working. I found that the problem is element wd_for_exec which should have value 0 if working dir is different as in the last call.",there exist -okdir which is easier to test,"Yes, in principle a tool might be able to explain this error.","Well, if you make an automated simulation (other methods e.g. model checking are probably out of scope for such large C projects) then the tool can give you some trace where you can see, that function for updating directory is not called. But it is a question if this is a real explanation.",Very difficult,60 minutes or more,"Now, working directory is always updated, even when this is not neccessary.  This is not efficient but I was not able to find, how to reset value of wd_for_exec only when needed.",Moderately confident,"Well, the program is now working, but the soluton is not efficient",,"No, there will never be a tool that can fix this error reliably.","A value must be changed but it is unclear if an assignments must be done or a function call must be done. And any such fix can have (or must have!) side effects, thus this is hard to do automatically.",20 to 30 minutes
find.e6680237,4/14/2016 17:56:02,MGJmMTU1N2,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,find/pred.c:500,find/pred.c:600,find/pred.c:2035,,,a pointer for exec working directory was not cleared after use. that lead to the pointer not being updated with the new path.,Moderately confident,,"a sparse read of the code to identify code paths candidates for behavior
a debug session to see what's going on inside
more checks in the code
finally noticed that the working directory pointer should be updated (debugger showed the old value still there)
cleared the pointer to obtain update
checked the binary to see if fixed",uninitialized variable reuse maybe?,"No, there will never be a tool that can explain this error.",requires understanding of the programmer conventions with respect to the use of the pointer,Moderately difficult,60 minutes or more,a pointer to the working directory for execution was not cleared/updated after each predicate evaluation. ,Moderately confident,checked if the wrong behavior is still present. it wasn't,,"No, there will never be a tool that can fix this error reliably.",would require the tool to understand programmer convention regarding the use of the working directory pointer,5 to 10 minutes
find.e6680237,4/18/2016 20:52:57,NDM5MjVmOT,Extremely familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",60 minutes or more,find/pred.c:513-527,find/pred.c:549-550,find/pred.c:604-605,,,First occurrence allocating resource which incorrectly used in the rest occurrences but it does not applicable for rest cases. The resource must be invalidated and freed after use.,Extremely confident,,"First, I found line of code where output is obviously incorrect. Next, I determined reason of incorrect output. By tracing program with gdb, I found ways how the data structure formed and how it affects to result. Finally, I decided reason preventing next occurrences to form correct data structure, so next occurrences produce incorrect result.",Viewing data structure diagrams with ability to save state and compare to previously saved states would be so helpful.,"Yes, in principle a tool might be able to explain this error.","I would have a tool that I say to that: ""look, there must be output such like that. Explain me, why the output is looks different"". In case of this study, it is possible to trace program back to determine reason of wrong output due first occurrence is correct, so it can be used as a sample for next occurrences. Root cause of error may be determined by comparing execution traces. This bug maybe can be even fixed automatically but it need a lot of execution time to make tries and determine use cases affected by each try.",Slightly difficult,50 - 60 minutes,Deallocate and free resource incorrectly used in next cases. This resource allocated for the first case and do not fit to others.,Moderately confident,It fixes the case and seemly do not affect to things already worked.,,"Yes, in principle a tool might be able to fix this error reliably.",It need to construct time of life diagram for this resource and see at what lines of code the resource have to be freed safely. I see nothing incredible in that.,5 to 10 minutes
find.e6680237,4/21/2016 15:09:18,ZTRmYWE5Nj,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/ftsfind.c:190-204,find/util.c:1090-1108,find/ftsfind.c:332-538,,,array error when access array data,Not at all confident,,"First:make breakpoint in ""visit""function
then look at what happened when run this function
 ",,"No, there will never be a tool that can explain this error.",,Very difficult,40 - 50 minutes,can not fix it,Not at all confident,not sure,Donot know how to fix it in the right way.,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.e6680237,4/27/2016 2:10:05,NGU0NDRiM2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",50 - 60 minutes,pred.c:511-529,pred.c:513-513,buildcmd.h:49-49,,,Wrong condition,Moderately confident,,"Build in debug mode
Debug step by step
Find wrong condition
Fix it",,"No, there will never be a tool that can explain this error.",,Slightly difficult,2 - 5 minutes,Fix condition,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.e6680237,5/28/2016 19:23:59,NzBjMjQ0OT,Slightly familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,find/pred.c:629-635,find/pred.c:538-620,lib/buildcmd.c:305-307,find/pred.c:2029-2125,,"The current file id is not getting changed  and we need to look in to that. I tried to debug this for a while, understood the bug a little bit but not able to patch it.",Not at all confident,I was not able to find out how to make the launch() execute the pwd command taking into care the current gid.,"Hmm. I tried to find out where output is getting printed.
Traced the whole execution path. Couldnt quite fix the bug",,"No, there will never be a tool that can explain this error.",,Extremely difficult,50 - 60 minutes,Hmm. I think we need to pass the current directory information to the launch function which is missing.,Not at all confident,Not fixed yet. Will try later again.,I was trying to patch but the code wouldnt compile. I felt I wasted quite good amount of time here so decided to move on to the next bug.,"No, there will never be a tool that can fix this error reliably.",,less than 5 minutes
find.e6680237,7/20/2016 6:14:39,OTRmYzA5OD,Not at all familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,ddd",50 - 60 minutes,find/pred.c:513,find/pred.c:521,find/pred.c:524,,,"The check if (!execp->wd_for_exec) was true on the first directory and wd_for_exec was set correctly. On the next runs it was false, so wd_for_exec was not changed and command was executed in the first directory",Very confident,,"1. Run gdb (namely ddd to make it easier) to trace the sequence of the function calls
2. Narrow down the calls to find the place where actually the command was run",the inner structure of the program,"No, there will never be a tool that can explain this error.","Tool can find the problem if pointer is NULL, and the check looks absolutely correct at this point.  ",Slightly difficult,5 - 10 minutes,Removed check,Moderately confident,"The test is passed, but possible memory leak may occur",,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.e6680237,7/21/2016 1:58:28,MzBiYjQ4ZG,Not at all familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,30 - 40 minutes,find/pred.c:510,find/utils.c:312,find/pred.c:510,,,Checking method of struct is having initialised was wrong. ,Very confident,,tried with gdb then started puting prints everywhere .. started printing pathname following the code etc.,runtime function flow,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,appropriate checking of condition.,Moderately confident,by running diff test cases and provided test.sh,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.e6680237,7/26/2016 16:28:13,ZTBjYWY1Nj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",grep,10 - 20 minutes,find/pred.c:631,find/pred.c:549,find/pred.c:513,,,"When filling the exec structure for command to be run, working directory is being filled only if it was not filled before, so the command will be ran in the same directory for each find result - specifically, the first one.",Very confident,,"I've grepped the ""execdir"" in the sources and found the place where it is implemented; then I've read comments and viola.",,"No, there will never be a tool that can explain this error.","In this case, I think, an automated tool would need to, so to speak, ""know"" the principles of program being debugged, e.g. somehow know that it executes the command for each file found etc.",Not at all difficult,2 - 5 minutes,I've made sure the working directory field is set correctly when executing a command.,Very confident,I've checked whether it works. Also I've made sure there's no memory leak.,,"No, there will never be a tool that can fix this error reliably.","Again, knowing the origin of the bug this would be simple. But then again, you'll need some sort of representation of program's functions and data structures to fix this bug by a push of a button.",30 to 40 minutes
find.e6680237,7/30/2016 4:30:49,MTk0NjE0Mj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,pred.c:513,pred.c:523,pred.c:549,,,"Somebody forgot to close and free the file descriptor that was responsible for pointing child (pwd) to the necessary directory.

Somewhere between new_impl_pred_exec() and launch() resources taken for wd_for_exec (pred.c:523) must be released. So I've decided to quickly put close()/free() right after passing wd_for_exec to the child.",Very confident,,"I was suspicious about that new function (new compared to previous `find`) recored_exec_dir used at pred.c:549. At the beginning I thought the bug was in state.cwd_dir_fd, that is not changed over time, but I was wrong (it cost me about 20 minutes). After another run in gbd I realized that execp is not changed between calls to record_exec_dir().

While I am writing this I've managed to change my patch 2 times. 1) I forgot to close(). 2)I placed close()/free() before wait().",,"Yes, in principle a tool might be able to explain this error.",Looks like resource leaking. Maybe it's possible for a tool to understand that that fd was needed only for child process.,Not at all difficult,5 - 10 minutes,Release resources at certain moment,Moderately confident,"Fixed it two times, heheh.
I do not know, actually, I haven't checked it at all.",,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
find.e6680237,8/3/2016 14:52:46,ODY3ODM5YW,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,pred.c:538-556,pred.c:513,pred.c:0,,,"The working directory is cached, even though it might change.",Moderately confident,,"1. Run gdb
2. print some variables
3. Got obsessed with the fact that dir_fd of buildcmd_state (buildcmd.h:52)
 is always -1. 
4. This did not lead to anything
5. Got a stroke of inspiration and just commented pred.c:513

Yes I was lucky.",,"No, there will never be a tool that can explain this error.",Hard. You have to know what's actually happening and why it is done. I would never say never but it is going to be pretty hard.,Not at all difficult,2 - 5 minutes,Just always call openat.,Moderately confident,Run test cases. Added more directories (deeper). Run again.,,"No, there will never be a tool that can fix this error reliably.",I think it is hard to find. Thus I also believe it is at least hard to fix. ,10 to 20 minutes
find.dbcb10e9,1/29/2016 6:01:45,YTA2MTE4ND,Not at all familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,find/parser.c:2739,find/parser.c:2759,find/parser.c:2762,,,Subjective error with pointer-to-pointer leveling,Extremely confident,,"1. gdb backtrace
2. take a look at the code related
3. noticed use of uninitialized pointer
4. checked for pointer semantics and found that it should be * instead of **",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,Made `pend` to be char* instead of char** and replaced all its occurrences accordinly to new variable type.,Extremely confident,testing,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.dbcb10e9,1/31/2016 22:11:11,ZTk0ZThkOD,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,5 - 10 minutes,find/parser.c:2762,find/parser.c:2762,find/parser.c:2762,,,de-referencing NULL pointer at find/parser.c:2762,Very confident,,"1. start program under gdb with ""-mtime"" parameter
2. see program crashes with segfault",,"Yes, in principle a tool might be able to explain this error.",my guess this kind of errors can be detected by static source code analyzers,Not at all difficult,10 - 20 minutes,added additional check,Very confident,run the test and checked functionality,,"Yes, in principle a tool might be able to fix this error reliably.",I think this kind of errors could be fixed by static analizer,10 to 20 minutes
find.dbcb10e9,3/16/2016 3:00:01,OTcyZjg1Mz,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,find/find.c:157-159,find/tree.c:1270-1448,find/tree.c:2669-2670,find/parser.c:2634-1,find/parser.c:2762-2763,Accessing pointer to pointer not initialized,Moderately confident,,"First using gdb I run: gdb ./find -mtime 2
Got the point where SEGV is generated at 
get_num (str=0x0, num=0x0, fractional_part=0x7fffffffe1f0, comp_type=0x7fffffffe67c) at parser.c:2762

Here we see that a null value is received at str parameter, so someone is introducing this error somehow, probably wrong pointer obtained before.

Then I found that there was an unitialized pointer at line 2762 parser.c
we try to access pointer to pointer before validating it",Invalid string parameter,"No, there will never be a tool that can explain this error.","Never seen before a tool that can cope with this type of errors, bug fixing is almost an art. If one day we can find a tool to do this please call me :-).
The range of causes is so wide that the push of a button is like a dream.",Slightly difficult,2 - 5 minutes,Added extra checkings to ensure that memory we want to access is OK,Very confident,"Run regression tests that previously failed, and some extra tests using mtime values to ensure that everything works as intended not only the failing scenario",,"No, there will never be a tool that can fix this error reliably.","I pray to find a tool for the same, but for the moment I believe that is something impossible, it depens on many factors, human errors, mistakes, typos,... too many factors to create a tool that can solve them, maybe some but not all, I have found bugs that are really really a headache to finally discover that was a stupid thing that generated the disaster.",10 to 20 minutes
find.dbcb10e9,4/9/2016 6:43:45,ZmZkMWM5OG,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",20 - 30 minutes,find/parser.c:2739,find/parser.c:2759,find/parser.c:2759,,,"Function get_num which is called in the case of -mtime make a call to function xstrtoumax, see find/parser.c:2759. Function xstrtoumax requires that there is an allocated memory to store one resulting pointer (second parameter). The way used to define variable ""pend"" which is passed as a second parameter is not correct because it does not allocate memory. ",Very confident,,"First compiled with -g and then started using ddd. When the problematic line was located I put breakpoint there and find out, that the value of second argument is not initialized before the call. Then I googled for xstrtoumax (because man did not exist) and find out the description and one example of usage. I was lucky to find a nice example which clearly showed that the second argument should be defined differently.",if I had manual for xstrtoumax I could avoid googling,"Yes, in principle a tool might be able to explain this error.","It is quite a simple error, the tool can (and debuggers already do this) show the problematic call stack.",Not at all difficult,5 - 10 minutes,I have changed second argument to function xstrtoumax so that it is now a local variable with allocated memory.,Very confident,The function call is now as expected in the documentation. I am not extremely confident because I did not find documentation for xstrtoumaxm thus I have used documentation for function with a similar name (without the first x).,,"Yes, in principle a tool might be able to fix this error reliably.","Well, it is not trivial but in some situations it could be done. The biggest problem is if a variable to be changed is used elsewhere (i.e. if it is global). If it is localy used, only, the fix could be quite reliable.",20 to 30 minutes
find.dbcb10e9,4/14/2016 18:45:16,MGJmMTU1N2,Slightly familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,snavigator",5 - 10 minutes,find/parser.c:2731,find/parser.c:2768,find/parser.c:2739,,,deferring an unallocated pointer,Moderately confident,,online debug followed by checking values in the pointers,"no, I think I did ok myself","Yes, in principle a tool might be able to explain this error.",use of unallocated pointer can be caught by static analysis almost,Not at all difficult,5 - 10 minutes,attributed the unallocated pointer to the addres of an already declared one,Moderately confident,"ran tests, ran binary in debugger and made sure that it behaves as expected at runtime (variable values, branches)",,"Yes, in principle a tool might be able to fix this error reliably.",crashes are easy to fix. ,less than 5 minutes
find.dbcb10e9,4/19/2016 3:00:15,NDM5MjVmOT,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",10 - 20 minutes,find/parser.c:2739,find/parser.c:2759,find/parser.c:2762,gnulib/lib/xstrtol.c:86,,"Variable char **pend used incorrectly in this case. Pointer to a pointer used uninitialized here (find/parser.c:2739) , so it don't provide actual storage memory for pointer changed by xstrtoumax() function (../gnulib/lib/xstrtol.c:86). Access to random area of memory pointed by uninitialized char**pend caused segfault. (find/parser.c:2759, find/parser.c:2762)",Extremely confident,,"I ran program with -mtime 2 option using gdb. So I got line of code where segfault occurs. Using gdb I checked variable values causing segfault. Looking through source code, I see that pointer to pointer variable used obviously in the wrong way. It not providing actual storage memory. It points to random, usually protected memory location which cause segfault.",,"Yes, in principle a tool might be able to explain this error.",Using -Wall -Werror gcc options already preventing bugs like that. ,Not at all difficult,1 minute or less,I used a pointer to store data instead of using of uninitialised pointer to pointer. ,Extremely confident,"Incorrect use of variable have limited area within one small function. Algorithm of this function is quite simple and obvious. Those changes obviously don't affect rest of program. Also, I did some tests with different command line options.",,"Yes, in principle a tool might be able to fix this error reliably.","Fixing tool logic must be like that: (value changed by xstrtoumax() have no storage space due function tries to alter random area of memory pointed by uninitialized pointer. So pointer must be initialized by a variable containing actual storage space). I believe fixing tool can apply such logic an alter find/parser.c:2739 by that way instead:
char * tmpvar = NULL;
char **pend = &tmpvar;
And rest of code remains unmodified. That is correct way to fix problem too but it don't used by human due additional variable is not necessary. Using simplification algorithm, it could even make patch like provided by me.",10 to 20 minutes
find.dbcb10e9,4/21/2016 9:48:40,ZTRmYWE5Nj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/parser.c:2742-2760,gnulib/xstrtol.c:78,find/parser.c:2669-2670,,,pointer NULL,Slightly confident,,"First:Debug using gdb
After:Get the code line where cause the error
Finally:Analysis the error",,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,20 - 30 minutes,"make ""pend"" variable non-NULL ",Not at all confident,"test it ,no segmentation fault",,"No, there will never be a tool that can fix this error reliably.",No tool can fix it .,5 to 10 minutes
find.dbcb10e9,4/26/2016 18:18:30,NGU0NDRiM2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",20 - 30 minutes,find/parser.c:2739-2739,find/parser.c:2759-2759,parser.c:2764-2764,,,"Send to function pointer to c string (local variable), and assume that this pointer will be changed, but it did not. Developer must send pointer to local variable.",Moderately confident,,"Build in debug mode
See to stack trace
See the code in suspected function",,"Yes, in principle a tool might be able to explain this error.",System could trace using of local variables,Moderately difficult,5 - 10 minutes,"Send to function pointer to local variable, i.e. send variable as reference, not as value.",Moderately confident,Test successfully finished,,"Yes, in principle a tool might be able to fix this error reliably.",Trace local variables usage,5 to 10 minutes
find.dbcb10e9,5/16/2016 22:22:19,NTU0ZTZlNT,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,40 - 50 minutes,find/parser.c:2739,find/parser.c:2759,find/parser.c:2762-2779,,,"pend could still be null after xstrtoumax call.  pend should just have been a string instead of an array of strings.  therefore, checking on 'pend' instead of '*pend' in line 2762 could trap situations when pend would be null.",Extremely confident,,"1. run gdb on the executable with the sample arguments straight to the crash (without breakpoints)
2. get the crash's stacktrace
3. breakpoint on the line that crashed
4. break and/or check on the previous function calls & inspect which functions failed to allocate the get_num function's str argument as stacktrace seem to suggest it as null upon entrance to said function
5. understand xstrtoumax use

Add the real step as this form won't accept less than 3 erroring regions.  reviewed a 2nd time despite initial insistence on a single erroring region:
6. read more on 'man strtol'",less than 3 erroring regions would flag error here,"No, there will never be a tool that can explain this error.","without seeing a sample use of xstrtoumax, passing an array of strings as the 2nd parameter would be valid",Not at all difficult,2 - 5 minutes,made pend into a simple string instead of an array of strings.  i then passed the address of pend to xstrtoumax instead of the whole variable (array of strings previously) itself.  changed then the usages of pend when looking out for a fractional part.,Extremely confident,checked the result of '$?' as 0,,"Yes, in principle a tool might be able to fix this error reliably.","when the error main cause has been diagnosed already & that in this scenario, it's the declaration of an array of strings instead of a string, a tool might be able to fix the error reliably, as it will just then be a matter of changing the usages (or invocations) of the variable.",5 to 10 minutes
find.dbcb10e9,5/29/2016 17:06:37,NzBjMjQ0OT,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/parser.c:2668-2670,find/parser.c:2633-2635,find/parser.c:2761-2763,,,The program was trying to dereference a null pointer unneccessarily,Very confident,,"GDB always comes very handy when a core dump is generated and I made use of it. I figured out that *pend was the culprit. Since this function was trying to return a boolean value, the part of the code where it was trying to access was unnecessary",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,10 - 20 minutes,I removed the code which was trying to access a null pointer and since the fractional part is always zero it is not needed,Very confident,I applied the patch. Verified the correctness. It is working as expected,,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
find.dbcb10e9,6/4/2016 8:23:02,MzYzM2Y4MG,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,1 minute or less,find/parse.c:2764,find/parse.c:2764,find/parse.c:2764,,,"The value pend is null. And when the program get the value of *pend, it will have a segmentation fault.",Very confident,,"First I try to run the ""find -mtime 2"" and segmentation fault error occur.
Then I use GDB to debug, when the GDB shows the file name and line number, I check the code the replace the correct code. After that I compile and run it. Finally, the application didn't have any segmentation fault ",file name and line number,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,2 - 5 minutes,Change *pend to pend,Very confident,"This is good fix because it ensure that when it will check the value of the pointer, it will not have a segmentation fault","Without a debugging tool, I can't fix it","Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.dbcb10e9,7/13/2016 14:26:38,OTRmYzA5OD,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb,valgrind",10 - 20 minutes,find/parser.c:2739,find/parser.c:2758,find/parser.c:2763,find/parser.c:2767,,Memory for pointer pend is not allocated,Very confident,,"1. Run gdb
2. Study backtrace
3. Study the code where crash occurs and documentation to strtol function
",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,"Create pointer to char on stack, instead of pointer to pointer to char",Very confident,No other way to fix it,,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
find.dbcb10e9,7/15/2016 1:42:35,MzBiYjQ4ZG,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find/parser.c:2762-2762,find/parser.c:2764-2764,find/parser.c:2764-2764,,,If condition was not properly used and comparison of pointer and character was not used properly.,Extremely confident,,I tried to look error segmentation fault with gdb. Then I got exact line number. I understood the function and then I tried to solve it.,,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,10 - 20 minutes,condition parameters.,Extremely confident,by testing with test script and manually testing with scenario and utility usage given.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.dbcb10e9,7/24/2016 18:42:29,ZTBjYWY1Nj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,20 - 30 minutes,gnulib/lib/xstrtol.c:79,find/parser.c:2778,find/parser.c:2674,,,"The cause of error was bad checking of the return parameters of function __xstrtol, which parses the argument string of -mtime option to actual numbers. The check for pointer to pointer to char correctness was wrong.",Moderately confident,,I've used postmortem debugging to understand the cause. Actually I've spend too much time looking for error in __xstrtol functioin insted of looking to the way its return values were processed.,,"Yes, in principle a tool might be able to explain this error.","Well, possibly it would be feasible, but only if the tool knew about semi-standard functions like __strtoul and the conventions about its parameters and return value(s).",Not at all difficult,2 - 5 minutes,"I've just made sure return value from __xstrtol (aliased here to xstrtoumax) checked correctly, i.e. checked for null pointer before dereferencing.",Very confident,"Well, I've compiled and ran it, and it was not segfaulting.",,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.dbcb10e9,8/1/2016 5:11:56,MTk0NjE0Mj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,parser.c:2762,parser.c:2739,parser.c:2739,,,`pend` variable at parser.c:2739 declared and used parser.c:2762 completely wrong.,Very confident,,Backtrace in gdb pointed on parser.c:2762. After a closer look it was clear that somebody just misused pointer to pointer thing.,,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,Made use of pointer to pointer in a correct way.,Very confident,none,,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
find.dbcb10e9,8/3/2016 16:19:36,ODY3ODM5YW,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,parser.c:2758-2761,parser.c:0,parser.c:0,,,Missing NULL pinter check,Extremely confident,,"1. run gdb and create backtrace
2. add fprintfs because pend was <optimized out>
3. Try to understand xstrtoumax",what xstrtoumax actually calls,"Yes, in principle a tool might be able to explain this error.",This is a NULL pointer access.Very easy to catch and explain.,Not at all difficult,5 - 10 minutes,Check for NULL pointer. If NULL then the entire string was valid and there is no fractional part.,Extremely confident,This is a trivial fix. Minimal testing.,,"Yes, in principle a tool might be able to fix this error reliably.",It is easy to find. It should be easy to generate a fix candidate.,10 to 20 minutes
find.e1d0a991,10/24/2015 22:48:54,ZDc4NDZjMm,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/ftsfind.c:346-359,find/pred.c:494,find/pred.c:312,,,"The error is caused because the path passed to the function executing the execdir predicate is wrong.

This happens because the flags passed to fts_open were  wrong.",Moderately confident,,"I first manipulated the arguments to get a better understanding of the issue at hand. Where is the execdir command executed from? I answered such questions. 

Next, run the program under gdb to understand the function path it will take. This was difficult since I had to step trace through the entire program to identify the function executing the particular execdir predicate. Once I had that, it was simply a matter of tracing the logic path and identifying the first location where the path went wrong. This turned out to be the position where the ent structure is first created. Upon manipulating the flags, I came across a combination that worked","If only I was told where the execdir predicate is executed from, I could have understood the entire flow much earlier.","No, there will never be a tool that can explain this error.","Since a lot of time here was spent on following intuition and then trying things, I'm not sure a tool could be able to automate this.",Very difficult,30 - 40 minutes,I changed the flags passed to the fts_open method. The flags originally sent caused the method to return the wrong path in the structure.,Moderately confident,I checked against various other combinations of flags and also went through the documentation to ensure that I'm not messing it up.,,"No, there will never be a tool that can fix this error reliably.","As mentioned in the last form, this fix required relying on my intuition to follow certain paths. Not sure if a tool could do that",less than 5 minutes
find.e1d0a991,2/3/2016 13:43:03,YTA2MTE4ND,Very familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, strace",30 - 40 minutes,find/pred.c:484-490,find/pred.c:467-471,find/pred.c:1561-1577,,,"This bug involves two sub-issues

1. The working directory is never changed for execdir. (This is not needed when -P option is on as fts library chdirs itself to the correct directory. But when -L or -H is on, fts doesn't use this feature on some reason)

2. execdir command parameters ('{}') are substituted as a full path from starting point instead of just a file name (same comment as above)
at find/pred.c:484-490 and find/pred.c:467-471",Extremely confident,,"I was debugging two process instances, one with -L and one without in parallel

1. strace for chdir-related functions. the process with -L chdirs much less than the other one

2. find places in code where chdir happens for no-L process version

3. check why there is no chdir with -L process version there",,"No, there will never be a tool that can explain this error.",,Slightly difficult,30 - 40 minutes,I've implemented a workaround for `launch` function to chdir into proper directory when it otherwise didn't and for `new_impl_pred_exec_ok` function to build args array without leading directory path,Moderately confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.e1d0a991,4/9/2016 23:48:02,ZmZkMWM5OG,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/ftsfind.c:349,find/ftsfind.c:364,find/ftsfind.c:373,,,"If using -L then FTS_LOGICAL flag is set in find/ftsfind.c:349 and passed to fts_open in find/ftsfind.c:364. Because of this flag, no chdir is performed during fts_read, called from find/ftsfind.c:373. I have tried without FTS_LOGICAL flag but then the results are even more wrong (link are not followed). Thus, if I suppose, that the error is not in fts_read (because that function is from fts.c which is outside of current project) then (1) something must be added to tell fts_read that chdir must be made or (2) chdir must be invoked and also struct ent adapted just before find/ftsfind.c:375. Please note, that chdir must be invoked, otherwise one could not obtain the correct result e.g. for ""-execdir pwd"".",Slightly confident,Function fts_read is from fts.c which is not the part of project and I cannot debug it in detail. The implementation of fts_read is too complicated for me.,First I follow the program until I foundnd out that command given after -execdir is executed in new_impl_pred_exec(). I found out that the arguments are different if using -L.  Then I found out that fts_read from fts.c is responsible for this because of FTS_LOGICAL flag. ,What is the meaning of all this FTS_ flags?,"No, there will never be a tool that can explain this error.","First, the tool should know what is the correct output for the given negative test. Moreover, the tool should have a detailed formal model of the algorithm which is probably not obtainable from C code.",Extremely difficult,60 minutes or more,no solution,Not at all confident,no solution,Source code include to many unfamiliar system calls and unknown flags.,"No, there will never be a tool that can fix this error reliably.","The error is not local, e.g. it seems to me that something must be changed in one function which will then change the behaviour of other functions. To corect this error it is the same effort as to implement new functionality from the given set of traces. I do not expect any automatic and reliable solutions.",30 to 40 minutes
find.e1d0a991,4/14/2016 10:41:27,ZTRmYWE5Nj,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,50 - 60 minutes,find/ftsfind.c:346-359,find/ftsfind.c:373-376,find/ftsfind.c:125-130,,,"346   switch (options.symlink_handling)
347     {
348     case SYMLINK_ALWAYS_DEREF:
349       ftsoptions |= FTS_COMFOLLOW|FTS_LOGICAL;
350       break;
351
352     case SYMLINK_DEREF_ARGSONLY:
353       ftsoptions |= FTS_COMFOLLOW;
354       break;
355
356     case SYMLINK_NEVER_DEREF:
357       ftsoptions |= FTS_PHYSICAL;
358       break;
359     }
Different symlink handling option have different fts opening option.",Moderately confident,,"First:find the code line which produce the output(./a/b)
After that:find the variable value difference between ""./find a -name b -execdir ls {} \;"" and ""./find -L a -name b -execdir ls {} \;"" using gdb
Finally:look at the root cause of the difference.",Different symlink handling option have different fts opening option.,"Yes, in principle a tool might be able to explain this error.",We can easily figure out the the different fts open option between different symbolic link handling manner.,Not at all difficult,2 - 5 minutes,Change fts options .,Slightly confident,"First:I think I solved the problem.
But I do not know the details why when using the find -L command  ,the fts option is FTS_COMFOLLOW|FTS_LOGICAL.",,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
find.e1d0a991,4/19/2016 14:06:41,MGJmMTU1N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","strace, gdb, snavigator",60 minutes or more,find/gnulib/lib/fts.c:779,find/gnulib/lib/fts.c:1309,find/gnulib/lib/fts.c:720,,,"when looking for files, the symlink file is considered ""cannot-stat-the-file"" leading to later ignore it in search results",Moderately confident,,"gdb divide and conquer, compared strace outputs, inserted a line of code (that diff.sh cannot outline) and checked that test passes",a high level overview of what's going on could help,"No, there will never be a tool that can explain this error.",because it would take it real understanding on what the software is intended to accomplish,Very difficult,60 minutes or more,made all files that could be found undergo a stat,Moderately confident,ran test script on it and returned 0,,"No, there will never be a tool that can fix this error reliably.",it would require the tool to understand programmer convention on how things should look inside the code,5 to 10 minutes
find.e1d0a991,4/23/2016 10:09:17,NDM5MjVmOT,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim, strace",60 minutes or more,find/ftsfind.c:348-350,lib/fts.c:236-238,lib/fts.c:313-315,lib/fts.c:525,,"When -L command line option specified, program logic set FTS_LOGICAL option flag (find/ftsfind.c:348-350). Directory to change is opened in function fts_open(lib/fts.c:313-315) and actually changed in fts_read() (lib/fts.c:525) only if FTS_NOCHDIR flag is not set. But this flag is always set for FTS_LOGICAL mode. So this behaviour is not a real bug but predefined program actions.",Very confident,,"First I ran program using strace to see what system calls occurs. I determined that with -L option specified, chdir() function does not invoked at all. Next, I ran program using gdb without -L option. Catching fchdir() syscall, I determined place where directory actually changed. Running program using gdb with -L option, I determined fchdir() is not invoked in this case because directory handler is not set and flag disabling dir changing is set. Browsing source code I determined that is predefined behaviour for this case. ",not sure if there can be a tool to help in this case,"No, there will never be a tool that can explain this error.","This behaviour is deeply coded into program logic. In strict terms, this is not a bug at all.",Extremely difficult,60 minutes or more,I add change dir function on execdir call when -L option specified due it is not provided by program logic.,Slightly confident,"I am not sure this is a good fix. Due behaviour is deeply coded in program logic, maybe there will be no good fix without very deep changes and testing. I am unsure if there may be some side effects and security issues caused by this fix.",,"No, there will never be a tool that can fix this error reliably.",Fixing this bug is like extend or rewrite program functionality. It requires vast understanding of the ways what is going and why.,10 to 20 minutes
find.e1d0a991,7/29/2016 4:18:43,MTk0NjE0Mj,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","strace, gdb",40 - 50 minutes,gnulib/lib/fts.c:237,pred.c:1531,pred.c:507,,,"I was not able to understand the cause of the bug. I've spent a lot of time just to get to the gnulib/lib/fts.c:237. According to it this bug is ""desired"" behavior (desired by programmers).

After this I went back to the launch() and *pred_exec() functions. Maybe it's possible to analyze the state of the program (is -L in effect) and change working dir and args somewhere before pushing them to the list (i.e.  bc_do_insert/bc_push_arg). But I can't do in *properly* in 45 minutes.
",Not at all confident,,"Search for fork/exec to understand that there is too late to change something.
Try to track down the chdir() usage. Understand that chdir is disabled intentionally because it's hard to detect loops while following symlinks and changing dirs.
Go back to the pred.c.
Maybe there is a way to fix it somewhere around pred_execdir().",,"No, there will never be a tool that can explain this error.","Because I can't.
But, well, I guess I am just not as good as some tool. So, maybe yes.",Very difficult,50 - 60 minutes, ,Not at all confident, ,Time constrains.,"Yes, in principle a tool might be able to fix this error reliably.",Automated tool have a lot more time/flexibility to test-fix-repeat and find out how to fix the program.,5 to 10 minutes
find.e1d0a991,7/30/2016 4:11:00,MzBiYjQ4ZG,Moderately familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",prints and gdb,30 - 40 minutes,find/ftsfind.c:348,find/ftsfind.c:507-541,find/util.c:501,find/util.c:485,find/parser.c:315,if -L is given then everything will be considered as a link and it will be followed and it will print full path.,Very confident,,first had a looked at program and functionality was working fine. Even tried to looked at original find utility and found same output so thought this is not actual bug then found that if I dont set follow_defere stat then it is resolved then found that everything regardless its type it is set as a symbolic link.,,"No, there will never be a tool that can explain this error.",,Very difficult,20 - 30 minutes,Added new condition ( file type check ) to avoid such case.,Moderately confident,by running provided test script and checking functional impact.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.e1d0a991,8/3/2016 13:19:40,ODY3ODM5YW,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,40 - 50 minutes,pred.c:511,ftsfind.c:128,ftsfind.c:0,,,Did not have enough time to fully understand bug. The ent->fts_accpath is different at ftsfind.c:128 from the 2 executions. I am not familiar with fts_read and I am not sure whether this is a bug in find or in the library,Slightly confident,Not enough time. Complexity of code. Unfamiliar with fts_read,"1. gdb 
2. Inspect pred.c
3.  More gdb",,"No, there will never be a tool that can explain this error.",I did not find the bug. So honestly I cannot tell.,Extremely difficult,1 minute or less,Nothing,Not at all confident,Nothing,Finding it.,"No, there will never be a tool that can fix this error reliably.",I do not know the bug. So I cannot judge about whether it is possible.,5 to 10 minutes
find.b445af98,2/1/2016 7:55:15,ZTk0ZThkOD,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",eclipse cdt,5 - 10 minutes,find/tree.c:1190,find/ftsfind.c:226,find/util.c:978,,,"not really sure what is *root* cause, but applying  fix 
""eval_tree->need_stat = !state.have_stat;"" in find/fstfing.c:237 fixes the output and it behaves as expected",Not at all confident,,"1. check the source code by searching how ""-H"" processed;
2. tracing program with both options (-H and -type l) and with one of them, checking execution paths and examine state
",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,"turned on flag that will force ""stat"" call on processed path, and it fixes program, but I didn't have a time to find out all the details and root cause.",Slightly confident,"started test, started program and checked output manually. While I didn't process complete regression testing with all the possible options.",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.b445af98,2/3/2016 5:21:19,YTA2MTE4ND,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/util.c:524,find/ftsfind.c:230,find/util.c:518-542,find/ftsfind.c:495,,"-H option should make `find` to dive into symlinks on the first-level directory items only (that is, on the arguments provided to find). state.curdepth is checked for that reason at find/util.c:524, but state.curdepth is updated _after_ checking type of the object at find/ftsfind.c:230, and symlink is dived into on 2nd level too at find/ftsfind.c:495.",Extremely confident,,"1. breakpoint at write syscall and check backtrace to see which predicate function is run to print filepath (pred_print). it is not called for the symlink test case with `-H -type l`
2. track for the predicate sequence on symlink case to see why pred_print is not called. turned out that pred_type returns false on this symlink
3. investigate pred_type for why it returns false. turns out that the stat data obtained by get_stat_info function is not a symlink stat data.
4. trace get_stat_info to find out why it returns wrong type data. while, investigating optionh_stat function, i found that curdepth value is not incremented yet.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,"I made state.curdepth to be updated earlier, before checking of stat.",Very confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
find.b445af98,3/21/2016 2:01:39,OTcyZjg1Mz,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",10 - 20 minutes,find/ftsfind.c:389-547,find/ftsfind.c:228-243,find/pred.c:1708-1779,,,When calculating stat information about symlinks it is overwritten at sections 1 and 2 and when we reach section 3 this info is no longer available,Slightly confident,,"First I run the different scenarios described here to see it in place
Then I saw that the cause was at pred_type that it was not able to depict the symlinks because stat info is no longer available
Finally I decided that the root cause was this, and probably it is overwritten somewhere",Wrong stat info management,"No, there will never be a tool that can explain this error.",It is difficult to make up a button for this type of bugs.,Moderately difficult,30 - 40 minutes,We ensure that we always have the stat infor of each file before doing filtering by type,Slightly confident,"Repeat test case, done some comparisons with built-in find command, created 2-3 new scenarios using symlinks to demonstrate that anything else is broken",,"No, there will never be a tool that can fix this error reliably.","A tool must to know about deeper functions used inside the logic, quite complicated",20 to 30 minutes
find.b445af98,4/8/2016 20:34:25,ZmZkMWM5OG,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/ftsfind.c:617-620,find/ftsfind.c:230,find/ftsfind.c:495,find/util.c:599-612,find/pred.c:1749,"Global variable state.curdepth is not updated before call to consider_visiting(), see find/ftsfind.c:617-620. It is updated in visit(), see find/ftsfind.c:230, but it is to late there. Function digest_mode() called before visit(), see find/ftsfind.c:495, is needed the updated information. Because state.curdepth is wrong, the condition in find/util.c:629 is true (see find/util.c:599-612) and therefore variable mode will get the wrong value. Afterwards, when comparing mode and type in find/pred.c:1749 the result will be false and the file, which should be printed will not be printed.",Very confident,,"I had a hard time to understand code and runtime actions because I was completely unfamiliar with implementation of linux utlities (parsing arguments etc.) and becuase I was unfamiliar with the command ""find"" - I am using it very rarely and only without arguments. First I find out, where the printing is done, then I find out the line which compare ""mode"" and ""type"", then I made my own tempdir1 and find out, that some symlinks are correctly written out, then I compare two runs and find out that symlinks get wrong mode because of wrong state.curdepth.",entries have numeric type and 40960 is used for symlinks,"No, there will never be a tool that can explain this error.","This error happens because in some moment some variables have an incorrect value. To explain this, the tool should know the correct values for every variable in every moment for the given test. This is not possible without help of the user. It would be somehow possible it we are able in every function to check the consistence of obtained arguments (and global variables), but this requires completely different design.",Not at all difficult,5 - 10 minutes,I have moved one line of code. There is an assignement to a global variable which should be done earlier than in the original solution.,Very confident,"I have checked the proposed test and also on my test. I have checked through the source code, that the new place of the assignement is correct, i.e. no other function in any file is affected. I have marked ""5-10 min"" because I had to finish tests. I have already know what is the right solution before I started to make fix. If I had to report time e.g. from the moment I detected that the problem is the wrong value of aglobal variable to the moment to find out the reason for that it would be more than 60 minutes.",,"No, there will never be a tool that can fix this error reliably.","The tool may know that some value is wrong but it is hard to decide why it is wrong (e.g. a missing call to some function, a wrong or missing assignement, etc). It is not possible for the tool to check if there are any side effects and thus it would not be a reliable fix.",30 to 40 minutes
find.b445af98,4/25/2016 1:50:25,NDM5MjVmOT,Moderately familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim, strace",60 minutes or more,find/ftsfind.c:493-497,find/util.c:629-636,find/util.c:607,,,"Program invokes digest_mode() to fill 'state' structure fields (find/ftsfind.c:493-497).  Depending on tree position and command line options, it may call get_statinfo() function, which dereferences symlinks. With -H command line option supplied, program always decides to dereference symlinks to a files contained in directory passed as command line argument but not deeper when checks file types.",Very confident,,"First, due symlink printed out when no -type l option specified, I considered that symlink information may have wrong file type set when used -H command line option. To figure that out, I ran program with -printf ""%p: %y\n"" option. I found that without -H option link files has type 'l' as ough to be, but with -H option only links to regular files
has 'l' type. Links to directories has apparently incorrect 'd' type. Using 'strace' utility, I found that with -H option program invokes newfstatat() function before printing out symlink information. I ran program with -H option using gdb. Caughting 'newfstatat' syscall, I found nested calls trace leading to that. Tracing program execution, I found that state.type is changed from 40960 (meaning it is a symlink) to 16877 (meaning it is a directory). So in short terms, digest_mode() invocation dereferences symlink to a directory. Browsing the code, I found that program decides when perform dereferencing symlinks in following_links() function. In case of SYMLINK_DEREF_ARGSONLY option, it dereferences them only on case if (state.curdepth == 0). To test that, I invoked program with '-H . -printf ""%f: %y\n""' instead of '-H tempdir -printf ""%f: %y\n""'. It determines symlink type correctly in that case (state.curdepth is 1). So I decided that program must not dereference symlinks with state.curdepth==0 but it does.
",not sure if there can be a tool to help in this case,"No, there will never be a tool that can explain this error.","In strict terms, program is working correctly. If only I can explain to a tool why given result is wrong, there could be too many reasons for such incorrect result.",Not at all difficult,1 minute or less,I required that with -H option symbolic links contained in working directory do not dereferenced too as they does in deeper directories.,Moderately confident,"It works. Due the fix can break some things which had some takeup for this bug, it need to do many use case tests to be sure. ",,"Yes, in principle a tool might be able to fix this error reliably.","By tracing code execution, a tool can determine differences in execution patterns and find out what must be fixed.  ",10 to 20 minutes
find.b445af98,4/25/2016 8:44:30,ZTRmYWE5Nj,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/ftsfind.c:346-359,find/parse.c:3167-3179,find/ftsfind.c:232-249,,,can not figure out what cause the error,Not at all confident,can not figure out what cause the error,"First:set breakpoint in ""visit"" function
then debug",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,can not figure out what cause the error,Not at all confident,can not figure out what cause the error,can not figure out what cause the error,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.b445af98,7/31/2016 23:03:44,MTk0NjE0Mj,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,util.c:607,util.c:629,ftsfind.c:496,ftsfind.c:230,,"state.curdepth used before needed assignment.
digest_mode() at util.c:629 follows symlink because state.curdepth at util.c:607 sill 0 like we are parsing commandline arguments. Because of that mode changes to actual mode of the dir, not the symlink and pred_type() (i.e. -type l) check fail.
In case without -H state.curdepth is not used. In case without -type l the pred_type() is not used.",Very confident,,"I've looked at the pred_type() in gdb and compared behavior with different parameters. Noticed that with -H the mode is different and states that it's not a symlink.
Added watchpoint for state.mode and found get_statinfo() which was called from digest_mode(). Found out that in case with -H following_links() behaves differently.
Spent some time thinking about state.curdepth. Because it might be an intended behavior and following_links() should be completely replaced by some other way of handling fact that we (not)following symlinks.
Comment at defs.h:618 clearly states that curdepth can be 0 only if we are parsing commandline arguments. Thus I decided to modify it earlier, right in the consider_visiting() function.",,"No, there will never be a tool that can explain this error.",Given the simple fact that I got help from one comment in the source code I would say no.,Moderately difficult,10 - 20 minutes,"Moved state.curdepth assignment to earlier stage.
Still in doubt that this is a good place to modify curdepth.",Moderately confident,I starting to doubt that I can properly write and test my bugfixes in less than 1 hour.,,"Yes, in principle a tool might be able to fix this error reliably.",But maybe some program can find out that some variable are used too early.,10 to 20 minutes
find.b445af98,8/11/2016 19:06:59,ODY3ODM5YW,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,pred.c:1753,ftsfind.c:596,parser.c:464,,,Not sure but it looks like we do not follow the symbolic link somehow and that is why pred_type returns false.,Not at all confident,,"Use gdb to find good starting point. 
Try to understand how the and where the mode is set.
",,"No, there will never be a tool that can explain this error.","I am not sure about the bug. If in case it is as I suspect, it is not clear what should be done. Then a tool can also not detect it.",Extremely difficult,40 - 50 minutes,Failed to fix,Not at all confident,Failed to fix,,"No, there will never be a tool that can fix this error reliably.",Failed to fix,5 to 10 minutes
find.93623752,1/30/2016 4:11:42,YTA2MTE4ND,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/tree.c:1265,find/tree.c:1267-1287,find/parser.c:914,,,"There seems to be a few errors here

At first, the condition check ordering in find/tree.c:1267-1287 is wrong.

Second, there was a null-pointer access at find/parser.c:914 when the insert_num funciton returned error",Moderately confident,,"I traced segfault case with gdb first. (the one at find/parser.c:914) and found that variable `p` is used while being equal to 0.

After that I traced for `find/tree.c:1267-1287` to see why the ""argument missing"" / ""invalid argument"" messages do not work appropriately. I tried to understand that part of code, and then I've found the flaw.

There is also the same bug as in find07 here, which messed my testing attempts and made me to spend more time on fixing it, but i ignore it here for now.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,20 - 30 minutes,"I added a null-pointer checks, check for argv to be out of bounds and fixed ordering of error condition checking",Moderately confident,manual testing,,"No, there will never be a tool that can fix this error reliably.",,more than 40 minutes
find.93623752,2/1/2016 1:25:10,ZTk0ZThkOD,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb, eclipse",30 - 40 minutes,find/parser.c:914,find/tree.c:1263,find/tree.c:1250,,,"segfault: find/parser.c:914 - return value is not checked - dereferencing null pointer;
starting from find/tree.c:1250: referring to wrong arvg index when printing erorrs
",Moderately confident,,"1. start ./find -gid x -ctime 2 under gdb, locate segfault site
2. start ./find -ctime x -gid x, under eclipse, trace function ""build_expression_tree"" after line 1250, see it uses wrong index  in argv to report ""wrong argument""
3. start ./find -ctime -gid under eclipise, trace trace function ""build_expression_tree"" after line 1250, see it ises next offset in argv to report ""wrong argument"" instead if ""missing argument""",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,"for sefgault fix: added check for return value in ""parser_gid"" function
for logical fixes: 
a) changed ""i"" to ""oldi"" so error prints referred to valid argument values
b) in line tree.c:1250 added additional check to check if given argument is value for option, but not a next option",Moderately confident,started test; manually checked output according bug report,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.93623752,3/14/2016 23:16:10,OTcyZjg1Mz,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/find.c:131-217,find/tree.c:1192-1285,find/parser.c:237-238,find/parser.c:3094-3156,,Parser module is not working properly for these options,Moderately confident,"Code understanding, it is too complex in my opinion and not easy to understand","I first repeat the failing the test cases failing
Then I look for the module that displays the error 
Then I found that it was a parser error",There was a parser error,"Yes, in principle a tool might be able to explain this error.","If this tool only tests input arguments (not find result) maybe it could explain it saying ""Parsing error""",Moderately difficult,20 - 30 minutes,"Index management for arg[i] was not treated properly, when error function must go forward to oldi value",Very confident,"Tested regression tests, did some other test cases following bug report section",Complexity of the code,"No, there will never be a tool that can fix this error reliably.","It is complex to guess that a line is missing at this point, you have to know perfectly how the code works and I think it is not trivialo with a button",10 to 20 minutes
find.93623752,4/10/2016 14:36:55,ZmZkMWM5OG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/parser.c:914,find/tree.c:1248,find/tree.c:1250,find/tree.c:1263,,"There are two different errors. For -ctime and for invalid arguments in general, the reporting of the error is wrong. 
Function to recognize the given parameter is called from find/tree.c:1248. It will increment variable i even for the wrong argument. Thus for explaining the error, oldi should be used, see find/tree.c:1250 and find/tree.c:1263.

For -gid there is an additional error. If argument is missing, then we get segmentation fault in find/parser.c:914, because function inser_num return empty p. We must add checking in find/parser.c:914.",Very confident,,"First, I found out the line producing segmentation fault. But the error was special for one case only, Thus I looked also for other error. I noticed the line about ""missing arguments"" and ""invalid arguments"" and traced why they are not executed correctly.",,"No, there will never be a tool that can explain this error.","Well, there are two errors. Segmentation faults can be explained with a trace (debuggers already do this). But other error is using the wrong variable in the wrong place. User could set a line which should be executed and then the tool would try to explain why this line was not executed. But this is not and automatic explanation. It is also the problem, that there are more than one error and because of the first error the second error is not accessible.",Slightly difficult,60 minutes or more,"For segmentation fault, I add checking of pointer before it is used. For other error, I changed the variable used in the comparison.",Very confident,It work for the given test cases.,,"Yes, in principle a tool might be able to fix this error reliably.","Well, only the segmentation fault is easy. Pointers should always be checked before used and this can be automaticaly added (this will made source less readable if used everywhere). The error about using the wrong variable could not be understand by the tool.",20 to 30 minutes
find.93623752,4/14/2016 18:18:37,MGJmMTU1N2,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,snavigator",20 - 30 minutes,find/parser.c:910,find/parser.c:3124,find/parser.c:3255,,,multiple causes. a null pointer deference followed by incrementing an argv pointer even if argument not parsed yet,Moderately confident,,"fixed the crash (gdb, run, crash) 
then ran again (carefully checked what happens to arguments passed in)
used source navigator to lookup symbols/grep","no, I'm fine, nothing could have helped me","Yes, in principle a tool might be able to explain this error.","I'm not sure what the tool would do. detect crash, sure. but figuring out what is intended as parsing argv... not sure",Slightly difficult,20 - 30 minutes,protected against *NULL and decremented argv incremented too greedy on parse error,Very confident,"checked inside debugger that all works according to plan.
then run test",,"Yes, in principle a tool might be able to fix this error reliably.",the crash... maybe. the argv usage.. it would require understanding programmer's intent,5 to 10 minutes
find.93623752,4/20/2016 15:50:49,ZTRmYWE5Nj,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,find/tree.c:1249-1271,find/parser.c:3126-3127,find/parser.c:3096-3124,,,The argv parameter is NULL pointer.,Slightly confident,,"First:figure our the code location causing this error.
Second:Use gdb to check pointer value.
",,"Yes, in principle a tool might be able to explain this error.",A tool can figure out the error code.,Moderately difficult,20 - 30 minutes,make argv[] content non-NULL,Not at all confident,"run "" ./find -ctime x"".the result is OK.",,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.93623752,4/22/2016 8:05:16,NDM5MjVmOT,Very familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",5 - 10 minutes,find/parser.c:913-914,find/parser.c:1113-1115,find/parser.c:1159-1165,find/parser.c:2210-2212,find/tree.c:1248-1271,"It is actually not a real error. It is rather incomplete code missing checking values returned from function. Function insert_num() returns NULL on bad arguments. Next, NULL pointer dereferenced without any checks in many places. Return value for get_relative_timestamp() on error does not handled properly too (find/parser.c:3127). Error conditions does not handled fully at (find/tree.c:1248-1271).",Extremely confident,,"I ran program with gdb using arguments which according to bugreport produces segfault. Next, I used backtrace to know flow control leading to segfault. Browsing source code I found check for NULL pointer obviously missed. Setting breakpoint to suspected function call I confirmed that dereferenced pointer have NULL value caused by impossibility to convert incorrect string argument to numeric values. ",this is already very simple and obvious things to fix,"Yes, in principle a tool might be able to explain this error.",That is quite simple task. Some compilers gives warnings about error check missing already. Slightly more complex tool can detect those checks easily.,Not at all difficult,5 - 10 minutes,"I added check for error conditions after conversion function calls. On error condition, NULL pointer dereference now avoided and command line arguments counter decreased. If there are predicate-looking argument found instead of value expected for previous predicate, it prints message about missing argument.",Very confident,It is pretty obvious and passed some use case tests I performed.,,"Yes, in principle a tool might be able to fix this error reliably.",Checking for error condition like that is simple and obvious task. Unsure if tool generated patch may be human readable and placed at appropriate code location.,5 to 10 minutes
find.93623752,4/27/2016 0:50:42,NGU0NDRiM2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",30 - 40 minutes,parser.c:911-913,parser.c:3094-3155,parser.c:3127-3128,,,"There are 2 errors:
1. Bug in parse_gid() function when we do not check up return value for not NULL
2. In parse_gid() and in parse_time() we do not decrease arg_ptr if parameter is wrong",Moderately confident,,"Build in debug mode
Debug, find place with segmentation fault
Find that in parse_gid() function we do not checking return value for not NULL
Fix it
Try dicrease arg_ptr
It is working",,"No, there will never be a tool that can explain this error.",,Moderately difficult,5 - 10 minutes,"We check return value in parse_gid() function for not NULL.
And we decrease arg_ptr if parameter is wrong.",Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.93623752,5/25/2016 20:50:54,NzBjMjQ0OT,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,10 - 20 minutes,find/tree.c:1242-1270,find/parser.c:3112-3114,find/parser.c:561-573,find/parser.c:910-924,,The arg_ptr was getting incremented in the parser function(when the parser function calls collect_arg() ) and hence argv[i] was evaluating to null if there were only 3 arguments. The if condition to check the error cases needed some modifications.,Very confident,,"First , I checked why the specific error message was being printed.
I understood that if condition was getting evaluated to false always.

I tried to understand this better by setting breakpoints and printing the variables. I deduced that the 'i' which was being passed as arg_ptr to the parser function was getting incremented.

Finally, I realized that the condition used to print the error messages had to be modified a bit.",Not sure,"Yes, in principle a tool might be able to explain this error.","A tool can give insights into why the particular error message is being printed. Like for example in this particular case, it can tell that the error is being shown due to argv[i] being null and why it's null(the places where 'i' changes).",Slightly difficult,10 - 20 minutes,"I changed i to oldi in the if conditions in build_expression_tree() so that the error messages are shown correctly.

I also added a few checks to see that the program doesnt crash in case of -gid",Very confident,"I tested the code after I applied the patch.
The last test i.e
$ ./find -gid -ctime 2
Segmentation fault
This should complain about an missing argument for -gid.

It doesnt complain about the missing argument for -gid, it says invalide argument which is also a right error message in a way.",,"No, there will never be a tool that can fix this error reliably.","I am not sure if there is going to be a reliable tool to fix th kind of errors in the first two cases
But the one where the program crashes could be automated I feel by automatically including checks so that there is no deferencing of a null pointer.",5 to 10 minutes
find.93623752,7/26/2016 17:28:38,ZTBjYWY1Nj,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb,grep",40 - 50 minutes,find/tree.c:1248,find/parser.c:914,find/parser.c:3130,,,"First, when parsing gid, return structure isn't checked for null pointer. Second, for some cases when parsing gid and ctime argument index in agrv is incremented incorrectly.",Very confident,,I've examined core dump from last case and fixed it first. Then I've found out (from the same coredump) where arguments are checked for being valid and/or missing and then examined the logic behind it.,"If only I was told that in the last case in bug report find should report invalid argument, not a missing one, I would have earlier understood it.","No, there will never be a tool that can explain this error.","An automated tool possibly could fix the segfault (inserting the missing null pointer check), but then again, I can't imagine an automated tool would find out that some of the parser functions are not obeying the same rules for argv index as other functions do.",Not at all difficult,2 - 5 minutes,I've added missing nullpointer check and fixed incorrect argv index increment in some cases.,Very confident,I've checked all the cases to produce expected results.,,"No, there will never be a tool that can fix this error reliably.",,more than 40 minutes
find.93623752,7/30/2016 3:18:21,MzBiYjQ4ZG,Very familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,prints",20 - 30 minutes,find/tree.c:1250,find/tree.c:1269,find/parser.c:914,,,in first problem wrong argument were taken to check. And in second wrong way to return pointer as a boolean.,Moderately confident,,first I understood the error. and put prints at several places. It was clean that arguments are sent incorrect so put prints and found that incremented arguments were sent and in second problem  I found that returning the pointer casting into Boolean was not possible so handled it in correct way.,,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,20 - 30 minutes,correct use to argument passed and correct way to return pointer as a boolean.,Very confident,by running provided test script and understanding and checking functional impact.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.93623752,7/31/2016 19:13:58,MTk0NjE0Mj,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,parser.c:3102,parser.c:911,tree.c:1248,,,"tree.c:1248 rely on return value of parse_* functions and on a number of eaten arguments by the parser.
First, segfault (parser.c:911) was a weird case, because the parse_* functions clearly states that they returns boolean, but instead of boolean some of that functions return pointer. (At this point one should spend a lot more time investigating if it is intended behavior) And all of them use that pointer without checking it's validity.
There was some other functions that does the same (like parse_inum)

In the last case predicate treats another one as an argument, and complains about wrong argument (after fixing the segfault). Because parse_ functions advance the arg_ptr (`i` in tree.c).",Very confident,,gdb backtrace from segfault. After that just brake at tree.c:1248,,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,"Fixed the usage of possible NULL pointer.
Restored the arg_ptr pointer to it's initial position in case of parser fail.
Added checks for next predicate to properly complain about missing argument, not about wrong value.

Again, this bugs demands an ""architectural"" decision, which can only be truly correct if programmer are very familiar with the source code. I can imagine a couple of various ways of dealing with this bugs that will depend on particular project structure or maintainers' preferences.
Many quick fixes can be actually correct, but can bring a lot of headache later, just because of the particular way they were fixed.",Slightly confident,No special actions was taken to ensure that this is a good fix.,,"Yes, in principle a tool might be able to fix this error reliably.","Tough question as always. Many cases looks like intended behavior, so it's hard to say if any tool will be able to track them down correctly.",10 to 20 minutes
find.93623752,8/3/2016 17:25:51,ODY3ODM5YW,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Regression Debugging to identify failure-inducing changes (e.g., git bisect)","gdb, git blame",20 - 30 minutes,parser.c:913-916,tree.c:1243-1270,parser.c:3232-3260,,,"in commit 7102a229 someone changed the code quite a lot but was sloppy :)

The index into argv is wrong if i != oldi. Parsing might change the i. So we should use oldi",Moderately confident,,"1. run gdb. Some issue dues to optimzed values.
2. Find the NULL pointer access (fixed it)
3. Realise argv[i] == NULL with help of fprintfs
4. Realise that i > argc with fprintfs
",i > than argc,"Yes, in principle a tool might be able to explain this error.",We basically access OOB. i > argc. So relatively easy to find.,Very difficult,10 - 20 minutes,"This code is not easy to read. Someone should clean it up.

Fixed NULL pointer access.
Fixed OOB access by using oldi instead of i.",Very confident,"Looked at git blame
Checked git diff c7ca8e10f25d951943b536c9d68d0e740fa35415 7102a229fa068e5de206cbd0ef1c96decd672c23   find/tree.c
Ran test cases.",,"Yes, in principle a tool might be able to fix this error reliably.",OOB are easy to fix. Should also be easy to realise that the access to argv is off by one (sometimes),10 to 20 minutes
find.66c536bb,2/1/2016 3:00:23,ZTk0ZThkOD,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",eclipse cdt,30 - 40 minutes,find/parser.c:3094,find/parser.c:3013,find/parser.c:3128,,,"1. function ""get_comp_type"" modifying it's argument (shifts the pointer) called twice, second time called with same argument - it returns wrong output;
2. in line parser.c:3113 - comparsion performed with wrong (uninitialized) argument 
",Very confident,,"1. executed commands from bug report:
Lets say we created one file each day in the last 3 days in directory tmp:
$ mkdir tmp
$ touch tmp/a -t $(date --date=""today"" +""%y%m%d%H%M"")
$ touch tmp/b -t $(date --date=""yesterday"" +""%y%m%d%H%M"")
$ touch tmp/c -t $(date --date=""2 days ago"" +""%y%m%d%H%M"")
$ touch tmp/d -t $(date --date=""3 days ago"" +""%y%m%d%H%M"")

2. traced function ""parse_time"" with eclipse cdt, with command line args:
tmp -mtime -2",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,"1. added extra variable to store pointer to ""time"" argument as ""get_comp_type"" function modifies it and called twice;
2. fixed argument for comparsion operator",Moderately confident,"I run a test cases from bug report also compared output with system's ""find""; but in some reasons automatic testcase still failed - it requires file created 2 days ago also included to output, which doesn't match with ""expected output"" from bug report.",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
find.66c536bb,2/2/2016 4:19:21,YTA2MTE4ND,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,find/parser.c:268,find/parser.c:3112,find/parser.c:3122-3124,find/parser.c:3127,find/parser.c:3109,"there are actually two errors here.

1. tval.kind is used while not initialized yet (at find/parser.c:3112) and comp variable is never used. so this should be substituted with 'comp'

2. the value of timearg pointer was initialized at find/parser.c:3103, and was modified while used at find/parser.c:3109

but later, it should be used in original state at find/parser.c:3127, while it is actually used in modified state

the modification included shifting +/- character to the left of the pointer, so this part of the argument was lost for `get_relative_timestamp` function call",Extremely confident,,"As I'm already familiar with the code, I started from investigating code in pred_mtime function, and then switched to parse_time function.

I tried to use gdb to track `comp` variable value (breakpoint at get_comp_type)  and found that it was optimized out too soon which means it is not used after initialized.

when the tests didn't pass yet, i continued investigating the code and found that timearg was used again in already modified state. ",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,5 - 10 minutes,"1. replaced uninitialized `tval.kind` usage with comp `usage`
2. saved timearg pointer to restore it after modification",Extremely confident,"manual tests

I also found that your test.sh test case is not correct. It isn't passed by system /usr/bin/find implementation. That's likely due to it doesn't account for the first error (uninitialized tval.kind vs unused comp), but I'm not sure here",,"No, there will never be a tool that can fix this error reliably.",I'd rather say that this kind of error can be prevented reliably with proper restrictions on variable modification. Although that might not relate to low-level languages like C,20 to 30 minutes
find.66c536bb,3/18/2016 21:27:08,OTcyZjg1Mz,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",60 minutes or more,find/parser.c:3094-3157,find/parser.c:3167-3183,find/parser.c:3029-3078,find/parser.c:246-259,,The option -2 is considered as 2 and logic for this value is applied,Slightly confident,,"First I run the examples
Then got familiar with this part of the code (again the main issue I am finding is to cope with the unkown code, its complexity and lack of comments).
After a long while  I found the bug at the pointer that is increased within the get_comp_type() function. We must use an aux variable to keep track of the string but at the same time do not lose the '-' sign","Complex to say this here,  maybe bad time calculation","No, there will never be a tool that can explain this error.","Complicated, this time was awful",Extremely difficult,60 minutes or more,"We must keep track of the original string pointer for mtime parameter, if we pass it to the get_comp_type(), this function modifies it and then causes to treat -2 as 2",Slightly confident,"I am not completely sure, but did some tests and compare results with find command currently installed at my box","If it is not fixed, the awful code was the root cause","No, there will never be a tool that can fix this error reliably.","Impossible, it was so hidden that I can not be possible",5 to 10 minutes
find.66c536bb,4/13/2016 18:07:01,ZmZkMWM5OG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",40 - 50 minutes,find/ftsfind.c:703,find/tree.c:1248,find/parser.c:3109,find/parser.c:3127,find/parser.c:3038,"For -mtime, function build_expression_tree() called from find/ftsfind.c:703 creates wrong tree. The error is in parse_time(), which is called from find/tree.c:1248. In get_comp_type(), called from find/parser.c:3109, the preceding sign ('-' or '+') is removed from the argument. Afterwards, function get_relative_timestamp(), see find/parser.c:3127 and find/parser.c:3038, is trying to check the preceding sign again, but it would always return EQ because the sign is not there, anymore.",Very confident,,"First I find out what is evaluated for -mtime. I found out that the tree used in evaluation is wrong. Then I found out that tree is wrong right after the call to build_expression_tree() thus the error is in the construction of the tree. Finally, I traced the error to parse_time().",,"Yes, in principle a tool might be able to explain this error.","This is about the functionality but it could be traced if the user can mark a code which is executed but it should not be. It is much harder to explain why something did not happen instead of why something happen . Fortunatelly, this test case includes an extra print and thus the tool could at least get a trace to this extra print. If such a trace is not a valid explanation then the explanation is not possible. PLEASE NOTE, in the given 14 examples I detected error about the misiing/wrong functionality many times and I have sometimes marked it as Explainable by the tool and sometimes as Unexplainable by the tool. I really do knot know enough about the strength of today's formal approaches but I am quite sure that for such a project in C the tool is not possibile to show you more than a trace to the marked part of the code. Is this an explanation?",Moderately difficult,50 - 60 minutes,I made and used a copy of one variabe because it is used in the function which changes its value but we still needs the old value.,Moderately confident,"Well, not so trivial this time.  Test case is now working but I noticed that the output is not the same as in the description. In fact, the description and test.sh are not compatible. I think, that the description is better and thus another fix in the source code is needed. I marked this additional fix in the comment but not made it to assure that (wrong) test.sh is passing. Please note, that this additional fix seems very logical because without it the program is using and uninitialized variable.",,"No, there will never be a tool that can fix this error reliably.","Unitialized variables can be reported. I know about such tools but I do not use them for this study because I am not familiar with them on GNU/Linux (I am only using such features in Visual Studio). However, unitialized variables cannot be automaticaly fixed reliably. Regarding the error with using the variable with wrong value, the tool cannot automaticaly find a fix.",more than 40 minutes
find.66c536bb,4/15/2016 17:39:16,MGJmMTU1N2,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, snavigator",30 - 40 minutes,find/parser.c:3177,find/parser.c:3029,find/parser.c:3094,,,"get_comp_type had side effect of modifying the argument index. however, it was called twice and this lead to overwriting the comparison operator, therefore leading to a runtime behavior similar to COMP_EQ. as bug report stated",Moderately confident,,"read code to get in touch with the problem, then ran debugger and had the surprise the code isn't acting as I expected. searched step by step for the source problem and found it",,"No, there will never be a tool that can explain this error.",hard to say if it can be automatically classified,Slightly difficult,20 - 30 minutes,restored the value of the argument pointer/index to preserve its sign during parsing,Moderately confident,compared run for -mtime n with -mtime -n. checked in the debugger that code actually behaves (variables and branches taken) as expected.,,"No, there will never be a tool that can fix this error reliably.","again, hard to say. maybe if it compares the runtime trace of mtime n and mtime -n it might be able to make suggestions",5 to 10 minutes
find.66c536bb,4/25/2016 6:43:13,NDM5MjVmOT,Moderately familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim, strace",60 minutes or more,find/parser.c:3165-3182,find/parser.c:3109,find/parser.c:3127,find/parser.c:3038,find/parser.c:3112,"Function get_comp_type() (find/parser.c:3165-3182) increments pointer to argument line when leading '+' or '-' occurs. In function parse_time() this function invoked twice, so second function invocation does not get '+' or '-' at the leading position even it was before. Also, due usage of uninitialized tval.kind variable (find/parser.c:3112) some time comparisons may be wrong. I believe that test script for this study may be incorrect due it reports good result when uninitialised variable bug remains unfixed.",Extremely confident,,"First, using strace program I determined that file information collected by invoking newfstatat() system call. Caught this system call, I found it invoked at find/util.c:570. Setting hardware read watch on st_mtim.tv_sec element of structure filled by that call, I determined it used at find/pred.c:1246 as argument to pred_timewindow() function to compare with args.reftime.ts of predicate structure value using comparsion method placed at its args.reftime.kind element. Structure demands COMP_EQ method which seems to be wrong in this case.
Using backtrace and browsing source code, I found this predicate is eval_tree->pred_left->pred_right. Global variable eval_tree is defined at find/tree.c:47 and filled by find/tree.c:1190 build_expression_tree() invoked from find/ftsfind.c:703. Tracing build_expression_tree() function execution I found that '-mtime' option passed as command line argument is handled by parse_time() function invoked at find/tree.c:1248. Browsing source code I found that tval.kind variable is used (find/parser.c:3112) but not initialized. Also, I found that
leading '+' and '-' made used by get_comp_type() (find/parser.c:3165-3182) invoked by get_relative_timestamp(). After using leading '+' and '-' function get_comp_type() increases argument
pointer. So due prior get_comp_type() invocation at (find/parser.c:3109), get_comp_type() invoked by get_relative_timestamp() returns wrong comparison type.
",,"No, there will never be a tool that can explain this error.",I see no way to determine if a side effect of a function is desirable or not.,Not at all difficult,2 - 5 minutes,I take side effect of function back. Also I fixed uninitialized variable issue.,Extremely confident,This fix is simple and obvious. ,,"No, there will never be a tool that can fix this error reliably.","Although a tool can be used to fix side effect of a function, I see no way how a tool could know this side effect is not desirable and must be fixed.",10 to 20 minutes
find.66c536bb,4/25/2016 8:40:07,ZTRmYWE5Nj,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/ftsfind.c:234-249,find/ftsfind.c:393-417,find/parser.c:3096-3124,,,can not figure out the error,Not at all confident,do not know what cause this problem.,"First:set breakppint in ""visit"" function
then try to debug",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,can not figure out what cause the error,Not at all confident,can not figure out what cause the error,can not figure out what cause the error,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.66c536bb,4/26/2016 19:43:26,NGU0NDRiM2,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",50 - 60 minutes,find/parser.c:3109-3109,find/parser.c:3112-3112,find/parser.c:3171-3171,find/parser.c:3127-3127,,"There are 2 errors:
1. Change one variable, but compare to another variable
2. Change pointer in one place, then using changed pointer in another place, although in second place we must using original value of pointer",Moderately confident,,"Build in debug mode
Debug with breakpoints
Add printf() many times
Find first error
Repeat previous steps
Find second error",,"No, there will never be a tool that can explain this error.",,Moderately difficult,5 - 10 minutes,"Fix 1 error: change variable, used in comparison
Fix 2 error: save original string pointer, than reuse this string",Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.66c536bb,5/24/2016 18:04:47,NzBjMjQ0OT,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",Did not use any tools in this case. ,5 - 10 minutes,find/parser.c:3099-3129,find/parser.c:3169-3186,find/parser.c:3028-3046,,,The timearg is not reverted to point to the '+' or '-' in the earlier case since get_comp_type() would have advanced it.Hence it was hitting the default case always and the comparison type was being taken as COMP_EQ.,Extremely confident,,"First, I checked the part where the switch case code for '+', '-' were written.
It was clear to me that it was hitting the default condition always after this.

After that, I analysed the code and found out the reason.",I think the bug description was quite self explanatory and I didnt require anything,"Yes, in principle a tool might be able to explain this error.","I believe that static code analysis could help in understanding why certain parts of the code are not getting executed and this may help in explaining the error. 
",Slightly difficult,5 - 10 minutes,I made the pointer timearg revert back to where it used to point before the get_comp_type() function since this function will advance the pointer.,Extremely confident,"I compiled the program and generated the find binary after applying the patch.
When I ran the test cases, it worked fine",,"No, there will never be a tool that can fix this error reliably.",I am not sure if this can be done or not. The detection is a lot easier but the fixing is a little complicated I feel. It depends on the type of bug.,5 to 10 minutes
find.66c536bb,7/26/2016 18:37:53,ZTBjYWY1Nj,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",grep,30 - 40 minutes,find/tree.c:1248,find/parser.c:3110,find/parser.c:3125,,,"When parsing mtime (and other *time predicates) argument, the function to determine comparison type (minus or plus) is called twice; the problem is it modifies given string and cuts -/+ sign out.",Moderately confident,,I've grepped around mtime and found function parsing time; then I've traced state of almost all variables; then I've stumbled upon the comment on calling get_comp_type twice and figured it out.,,"No, there will never be a tool that can explain this error.","This bug is actually a bad design issue; if first argument to get_comp_type would be const, it wouldn't happen.",Not at all difficult,1 minute or less,I've made sure the plus/minus sign on argument is processed correctly.,Very confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,30 to 40 minutes
find.66c536bb,7/27/2016 21:14:12,MTk0NjE0Mj,Not at all familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",already included printf tracing,20 - 30 minutes,parser.c:3109,parser.c:3127,parser.c:3038,,,"Superfluous increment of timearg pointer that passed as pointer to pointer to get_comp_type() function at parser.c:3109 and again in get_relative_timestamp() function at parser.c:3127 (i.e. parser.c:3038)

Looks like the error caused by blind copy-pasteing of code blocks because there is another error with using uninitialized variable (parser.c:3109)
That uninitialized variable bugged me all the time I was fixing the error. I thought that it might not be involved.",Very confident,,"git grep mtime

choose to be consistent and decide to look at the parser first

Noticed that tval.kind was always COMP_EQ at the end.",which function to look at,"Yes, in principle a tool might be able to explain this error.",One can include in this tool some checks about all these pointer-to-pointer things. After some bruteforcing the tool might track down the error.,Not at all difficult,1 minute or less,Leaving timearg as it was,Very confident,Test against cases in bug description.,,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
find.66c536bb,7/28/2016 23:53:25,MzBiYjQ4ZG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb and prints,30 - 40 minutes,find/parser.c:3099,find/parser.c:3102,find/parser.c:3122,,,wrong incremented pointer was changing type of comparison as it was calling twice. Reset variable comment was written but actually reset was not done so reseted it.,Very confident,,first found why type is getting comp_eq instead of anything else .. then found code flow and found the cause.,,"No, there will never be a tool that can explain this error.",,Very difficult,10 - 20 minutes,correct variable used to increment. and corrected if condition arguments.,Very confident,by running test script and checking out functionality impact.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
find.66c536bb,8/2/2016 18:18:42,ODY3ODM5YW,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,prec.c:278-288,pred.c:1246,parser.c:3172,parser.c:3102-3128,,At parser.c:3110 we call get_comp_type which increments timearg if the comp type is COMP_GT or COMP_LT. The call to get_relative_timestamp also calls get_comp_type. However at this point the timearg was already incremented and does not point to the sign anymore but to the number.,Extremely confident,,"1. gdb
2. b write
3. b apply_predicate
4. single stepping through apply_predicate
5. Realised that I should actually look at the predicates instead of stepping through the function.
6. Found pred_mtime and pred_timewindow
7. set breakpoint on pred_timewindow and print pred_ptr->args.reftime.kind
8. Verify that it is always COMP_EQ independent of whether I pass ""-2"" ""2"" or ""+2"". That hints to a bug in the parser
9. Inspect parser
10. Found get_relative_timestamp and parse_time
11. Inspected get_comp_type. Realised that it manipulates the passed pointer and thus timearg points to the wrong location.
",pred_ptr->args.reftime.kind is always COMP_EQ,"Yes, in principle a tool might be able to explain this error.","I believe it is possible but hard. The problem here is that you need inherent knowledge about what is actually expected from the program. I believe it is possible to hint at code smell, because there is a pointer that is passed to get_comp_type, gets manipulated, and is then passed to get_comp_type again. In a different function. That might be intended, but smells suspicious. So I would not really say it can be explained, but the programmer can definitely get hints.",Not at all difficult,1 minute or less,Just create a copy of timearg and pass this instead of timearg.,Extremely confident,Run test case.,,"Yes, in principle a tool might be able to fix this error reliably.","A tool could suggest the fix. I think once you found the problem the fix is trivial. So it you have a tool that can find the problem, it should be easy to suggest a fix.",20 to 30 minutes
find.183115d0,2/2/2016 2:04:20,YTA2MTE4ND,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, strace",5 - 10 minutes,pred.c:516-525,pred.c:528-555,pred.c:566,pred.c:571,,Directory descriptor is never closed,Extremely confident,,"1. strace for repeating directory opens to know which syscall is used
2. gdb: set breakpoint on that syscall (openat) and check backtrace to know which user function calls it
3. study code leading to openat",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,just added descriptor closing function call after child process execution,Very confident,manual testing,,"Yes, in principle a tool might be able to fix this error reliably.",this will probably require the tool to track lifetime of the descriptor,10 to 20 minutes
find.183115d0,2/2/2016 15:40:14,ZTk0ZThkOD,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","valgrind, gdb",50 - 60 minutes,find/pred.c:520,find/pred.c:531-554,find/find.c:571-598,find/find.c:611-668,,"find/pred.c:520 - directory actually opened;
find/find.c:611-668 - after exec called on directory, it never closed
",Moderately confident,,"1. started program under valgrind to see the stack that leads to leaked fd
2. checked sources and traced with gdb to understand the logic",,"Yes, in principle a tool might be able to explain this error.",because valgrind does it currently,Moderately difficult,20 - 30 minutes,closed opened directory fd in case it was opened before,Moderately confident,"run testcase, run program manually with set ulimit=30 and make sure there's no error message anymore",,"Yes, in principle a tool might be able to fix this error reliably.","probably, but I'm not sure if it can be fully automatic,",10 to 20 minutes
find.183115d0,4/11/2016 2:05:23,ZmZkMWM5OG,Moderately familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,find/pred.c:520,find/pred.c:523,find/pred.c:660-664,find/ftsfind.c:349-356,,"For execdir, openat is called for every entry, see find/pred.c:520. The error appears because there is no coresponding close. There is a call to set_cloexec_flag() in find/pred.c:523 but I do not really understand the meaning of this flag and it is apparently not enough to prevent the error. fd remains open at the end of impl_pred_exec(), I have made check in find/pred.c:660-664. Probably, fd must be closed there. Or, something must be changed so that fd will be closed in find/ftsfind.c:349-356, that lines are called after all elements but those if statements are false during the problematic run.",Moderately confident,,"First, I tried execdir and exec and find out that only execdir is problematic. Then I found the part of the code which is called only for execdir and noticed openat. Then I add some printf to check, how many times openat is called and how long fd remains open. I found out that it remains open forever.",I do not have a knowledge about the  filesystem calls,"Yes, in principle a tool might be able to explain this error.","Well, this is somehow similar to segmentation faults. The tool can trace all fd from open to close calls and if too many fd-s are opened then it can show a trace to all open calls.",Very difficult,60 minutes or more,I have added a call to close() which will be executed for all elements.,Moderately confident,"First I spetn a lot of time trying to change the program in such a way that the lines in ftsfind.c:349-356 would be executed for ever element. But the program is too complex and I could not find the correct way.  Thus, I added a call to close(). It works for my test but I am not sure that this not break some other calls.",,"No, there will never be a tool that can fix this error reliably.","In principle, the tool could find all the paths, where fd-s are not closed until some given point and then add a call to close(). However, the tool will have a problem to find the correct place for close, it must not be placed to early. ",20 to 30 minutes
find.183115d0,4/15/2016 17:48:13,MGJmMTU1N2,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)","valgrind, snavigator",10 - 20 minutes,find/pred.c:657,find/pred.c:550,find/pred.c:2074,,,file descriptor for opening working dir was not closed after child exited.,Moderately confident,,ran valgrind with -track-fds and checked what file descriptor was about. then checked where in the program flow is that best closed,,"Yes, in principle a tool might be able to explain this error.","well, that's what I used, valgrind explained what happened",Slightly difficult,20 - 30 minutes,"after child exited, closed the file descriptor of the directory it was in",Moderately confident,checked with valgrind if there are any file descriptors left open,,"Yes, in principle a tool might be able to fix this error reliably.","maybe with human assistance: the tool would divide-and conquer (call tree based), asking for ""Is that intended behavior?"" and the human would answer",20 to 30 minutes
find.183115d0,4/24/2016 7:02:35,NDM5MjVmOT,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",50 - 60 minutes,find/pred.c:579,find/pred.c:520,find/pred.c:559-666,,,"Program opens directory file for each execdir call (find/pred.c:520) but do not closes fd. Although FD_CLOEXEC flag is set, but file descriptor is opened before fork() and child's exec(). Parent process has this descriptor not closed within impl_pred_exec() (find/pred.c:559-666). Finally, program consumes all file descriptors it limited to and failed at find/pred.c:579.",Extremely confident,,"First I used gdb to run program. I set breakpoint on stderr output. I got place where program trying to open dirdirectory file at find/pred.c:577. 
Browsing source code I found that directory opens at find/pred.c:520
by function initialise_wd_for_exec(). Browsing source code and tracing program execution after find/pred.c:577, I found that program invokes fork() and child process invokes exec(). Although file descriptor has FD_CLOEXEC flag set so child's fd is closed after invoking program passed by -direxec command line option,  in parent process the file still remains opened.",maybe a tool showing allocated resources with lines of code where those resourcs were allocated might be helpful,"Yes, in principle a tool might be able to explain this error.",Resource accounting and tracking time of life for variables contained those resources is simple enough task.,Not at all difficult,2 - 5 minutes,I freed allocated resources and closed file directory,Very confident,This is quite simple and obvious fix. It frees resources and have no side effects.,,"Yes, in principle a tool might be able to fix this error reliably.",Resource accounting and tracking context where they still accessible is quite simple task.,10 to 20 minutes
find.183115d0,4/27/2016 1:43:23,NGU0NDRiM2,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",30 - 40 minutes,pred.c:516-525,pred.c:558-665,pred.c:577-577,,,"Resources allocated for execp->wd_for_exec, but do not freed.",Moderately confident,,"Build in debug mode
Debugging step by step
See that resources allocated but do not freed
Fix it",,"Yes, in principle a tool might be able to explain this error.",Trace allocating and freeing memory,Slightly difficult,2 - 5 minutes,Free memory,Moderately confident,Tests finished successfully,,"Yes, in principle a tool might be able to fix this error reliably.",Trace for allocating and freeing memory,5 to 10 minutes
find.183115d0,5/23/2016 19:11:28,NTU0ZTZlNT,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf",50 - 60 minutes,find/pred.c:519,find/pred.c:659,find/pred.c:665,,,"The exec working directories of the predicates' ""exec_vec""s are never freed resulting to the leak on the directories.  These directories' file descriptors aren't closed also resulting to the later ""execdir""s not executing anymore.",Extremely confident,,"1. read openat manpage
2. read the bug description multiple times
3. understand the meaning of ""WD"" or ""*wd*""","""WD"" means or ""*wd*"" pertains to working directories","No, there will never be a tool that can explain this error.",Understanding the use of the wd_for_exec member of the predicate's exec_vec & concluding that its file descriptor can be finalized by a simple close command can never be arrived at without reading the code & its comments.,Slightly difficult,2 - 5 minutes,"1. free the malloc'd ""wd_for_exec""s
2. close the file descriptors of the ""wd_for_exec""s",Extremely confident,"check the ""echo $?"" command result",,"Yes, in principle a tool might be able to fix this error reliably.","Placement of the close & free statements may be done correctly.  Diagnosis must point the which objects were opened & where the ""wd_for_exec""s were malloc'd for the fix to be reliable.",20 to 30 minutes
find.183115d0,5/29/2016 4:26:46,NzBjMjQ0OT,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,find/pred.c:580-582,find/pred.c:554-556,find/pred.c:518-528,,,the execp->wd_for_exec->desc fd were not getting closed and hence the problem,Very confident,,"I understood where the fd's where getting initialized using gdb.
After that, I checked where the fd's were being closed.After analysing the code for some time , I figured out that the problem was due to these fds not getting closed",,"Yes, in principle a tool might be able to explain this error.",Static Code analyzer will term these as coverity bugs and it;s very much possible to detect these,Not at all difficult,2 - 5 minutes,I closed the file descriptor which were not being closed due to which find was not working properly.,Very confident,Applied the patch. Verified the test cases. I hope it works fine,,"No, there will never be a tool that can fix this error reliably.",I am not sure about the fixing part but diagnosing these bugs are easy,5 to 10 minutes
find.183115d0,7/28/2016 3:05:16,ZTBjYWY1Nj,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",ack-grep,5 - 10 minutes,find/pred.c:579,find/pred.c:545,find/pred.c:520,,,"The file descriptor for working directory for -execdir predicate was opened (region 3), but never was closed, which led to descriptor leak.",Very confident,,I've grepped error message text and then just examined source code.,,"Yes, in principle a tool might be able to explain this error.",An automated tool could in principle show call of open() unmatched by a call to close().,Not at all difficult,1 minute or less,I've made sure file descriptor is not leaked.,Moderately confident,I've tested it.,,"Yes, in principle a tool might be able to fix this error reliably.","Looking at this bug as at some sort of garbage collection issue, an automated tool could possibly detect when we stopped using file descriptor in code, so that it would insert missing close() there. But hey, we're talking C, so maybe it's not an issue for some other managed languages.",20 to 30 minutes
find.183115d0,7/29/2016 0:22:42,MzBiYjQ4ZG,Very familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,prints and self understanding",30 - 40 minutes,find/pred.c:580,find/pred.c:530,find/pred.c:664,,,"As we have limited maximum open file, it was not taken care in code. code was keeping all working directory open which was impacting limitation.",Very confident,,first understood the problem. found that code is working fine but limitation handling was not done so I added that.,,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,20 - 30 minutes,handled the scenario where maximum number of open files can be limited. Started freeing fd which is not necessary anymore.,Very confident,by running provided test script and checking function impact.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.183115d0,8/1/2016 23:20:33,MTk0NjE0Mj,Moderately familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,pred.c:2073,pred.c:520,pred.c:2097,,,"execp->wd_for_exec->desc (pred.c:520) is not closed after exec() in launch() pred.c:2073 . Apparently, FD_CLOEXEC does not work. Or I do not understand how it should work.",Slightly confident,,I was familiar with this wd_for_exec stuff and possible leak. So i just checked if something will change if I close the execp->wd_for_exec->desc after launching a child.,,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,"Same patch as for find.e6680237. Closed useless after exec fd and free'd memory.
Maybe it's better to deal with FD_CLOEXEC instead of this.",Slightly confident, ,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
find.183115d0,8/2/2016 17:23:11,ODY3ODM5YW,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,pred.c:520,pred.c:531-545,pred.c:577,,,"At pred.c:577  record_exec_dir is called. This functions checks the todo flag. This seems to be wrong since we should actually check whether the execp is actually initialised. Thus, the wd is initialised multiple times.Initialising the wd opens it. It is never closed. We run out of fds.",Moderately confident,,"1. gdb
2. set breakpoint on write
3. bt
4. inspect  visit at ftsfind.c:198
5. inspect apply_predicate
6. inspect impl_pred_exec
7. Search for anything that opens a file
8. Inspect record_exec_dir
9. Found openat at pred.c:520
10 Verified by setting breakpoint at initialise_wd_for_exec. Run out of fds after breakpoint is hit 25 times which is close enough to the ulimit
",the openat at pred.c:520 correlates nicely with the ulimit,"Yes, in principle a tool might be able to explain this error.",There is a nice correlation between the calls to  initialise_wd_for_exec and the open file descriptors. Should be easy to uncover this by running it multiple times and extracting the correlation.,Moderately difficult,20 - 30 minutes,Close the fd if it was opened before.,Very confident,"Ran test case.
Compare to output of my installed find.
Added print statements to verify expected control flow.
",,"Yes, in principle a tool might be able to fix this error reliably.","I think this one is possible but might be hard. I spent most of the fixing time on figuring out whether I should close the file descriptor, or not initialise the wd again. (as in skip the call initialise_wd_for_exec if initialise_wd_for_exec is set)

So I think it is possible, but in this scenario you probably want to generate a set of possible fixes and let a developer choose the correct one.",10 to 20 minutes
grep.c1cb19fe,3/24/2016 21:58:59,YmI4MGM3ND,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","printf, gdb, eclipse",30 - 40 minutes,src/search.c:378,src/dfa.c:2893-2896,src/dfa.c:1982-2272,,,"I couldn't understand root cause (in terms of few lines of code, hard to understand logic in ~300 lines function), but ""trans"" array filled in different ways for LC_ALL=C and LC_ALL=ru_RU.koi8r",Not at all confident,it's hard to understand search tables login in limited time.,"1. traced the code where matching happened: ...grep->grepbuf->EGexecute->dfaexec (src/dfa.c:2893:2896);
2. figured out that trans table filled diffidently for different locales (dfastate function)",,"No, there will never be a tool that can explain this error.",,Extremely difficult,20 - 30 minutes,coulnd't fix the error,Not at all confident,coulnd't fix the error,"complex logic of search tables implementation in grep, limited time","No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.c1cb19fe,4/18/2016 16:30:29,ZGU4Yjc1ZG,Not at all familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,src/dfa.c:1418,src/dfa.c:1103-1117,src/dfa.c:472,,,"For some locale, variable hard_LC_COLLATE is set (see src/dfa.c:1418) to denote that letters are ordered in a strange way (e.g. Russian cyrilic). In this case, else part of the block at src/dfa.c:1103-1117 is used to prepare the info about the letters in the given range. Function in_coll_range() uses the correct function strcoll() to compare letters. But the condition at src/dfa.c:472 has an error and thus wrong letters are selected to be in the given range.",Extremely confident,,"First I spent a lot of time checking the part of code which evaluates characters from the given input. I have compared traces for different locale. I found out that the prepared (compiled) info about the pattern is different. This was really a problem because I do not understand those large structures full of numbers used to store info about patterns. I was sure that if the compiled structure is correct and some code is missing or wrong while using this structure I will not be able to explain the error. Thus I concentrated on compilation of this structure and I also made some tests without range and with different range. I was surprised with strange results when using ranges. Then I also noticed the use of LC_COLLATE in the source code and I found in the documentation that this is connected to evaluating ranges. Finally, I concentrated on the part of the code which depends on the value of LC_COLLATE and found the bug.",russian cyrilic needs special functions for comparing characters,"Yes, in principle a tool might be able to explain this error.","Well, not really explained, but it can help you a little bit. The tool does not know, what is the purpose of using strcoll() and that we want to detect if characters are in the range and not e.g. outside the range. But for this specific error, the condition has two parts connected with && and in all situations the result of the evaluation is the same as the result of the second part. The tool can show you this as suspicious.",Not at all difficult,2 - 5 minutes,I have changed the wrong condition used to detect if a given character is in the given range of characters.,Extremely confident,Test cases are working. I spent a lot of time to detect the wrong part of the code but when I found out that checking the range is wrong the fix was easy.,,"No, there will never be a tool that can fix this error reliably.",The tool does not even know which variables have wrong values.,20 to 30 minutes
grep.c1cb19fe,4/27/2016 16:02:32,ZWM2ODBmOG,Moderately familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",60 minutes or more,grep/src/dfa.c:1113-1116,grep/src/dfa.c:469-473,grep/src/dfa.c:319-329,,,Program sets bit flag for each character (grep/src/dfa.c:319-329) if the character is within user defined range (grep/src/dfa.c:1113-1116). For locale dependent comparison strcoll() function used (grep/src/dfa.c:469-473). Function in_coll_range() incorrectly determined if a character is within a range.,Extremely confident,,First I ran program using gdb. Using step-by-step execution and inspecting local variables I found that in_coll_range() returns incorrect result.,High level data diagram may be helpful,"No, there will never be a tool that can explain this error.",A tool could not determine if this function behaviour is erroneous or it ought to be.,Not at all difficult,2 - 5 minutes,I fixed character order due character in between of two characters must have different signs on comparison.,Very confident,I did some use case tests. It looks working.,,"No, there will never be a tool that can fix this error reliably.","Due there are too many ways to get the same result, I am unsure if a tool can make decision if this function works correctly or not.",10 to 20 minutes
grep.c1cb19fe,4/29/2016 2:41:21,OWMzNDk3N2,Slightly familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",60 minutes or more,dfa.c:469-473,dfa.c:472-472,dfa.c:471-471,,,Wrong condition in region #2,Very confident,,"Debug, debug and debug step by step until in_coll_range() function.
If you look to this function (range #1) then you could see wrong condition.",,"No, there will never be a tool that can explain this error.",,Slightly difficult,2 - 5 minutes,Fix condition for char boundaries.,Very confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.c1cb19fe,6/4/2016 2:21:02,NTM3Y2E1MW,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,src/grep.c:1879-1881,src/grep.c:2299-2301,src/grep.c:1290-1292,src/grep.c:1201-1203,,"The LC_ALL was being set to the environment variable since it was """"(an empty string).And since the LC_ALL env was being set to  ru_RU.KOI8-R, it wasn't printing 'f'",Very confident,,"First, I ran through the execution of the program through gdb to understand better. I was able to figure out where the character f was getting printed.
It was because the LC_ALL was being set from the environment variable and hence the characters werent getting printed",export LC_ALL=ru_RU.UTF-8 should have been ru_RU.KOI8-R. I spent some time unneccessarily here,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,I set the LC_ALL to C and not set itself from the env variables.,Very confident,Applied the patch. Verified the correctness.Seems to be working,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.c1cb19fe,8/1/2016 0:28:39,MjYyYzZkN2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,src/dfa.c:472,src/dfa.c:1115,src/dfa.c:319,,,"The function to fill character class corresponding to [] pattern (region 1) was using strcoll, which is locale-dependent - that was screwing english characters (the first half of ASCII table, to be precise).",Slightly confident,,"I've set breakpoint on setbit(), then on setbit_case_fold(), then I've noticed where it is called from and noticed function in_coll_range. I've debugged around if expression containing its call and found out it returns strange results for english characters (e.g. that 'f' is not in range 'a' - 'z'). I've read it source finally and found out it uses strcoll, which is locale dependent.",,"No, there will never be a tool that can explain this error.","Only if a tool would somehow 'know' that in_coll_range should not screw first half of ASCII table, which is again a question of semantics of program being debugged.",Not at all difficult,1 minute or less,I've made sure english characters are processed independently of locale being set.,Slightly confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,
grep.c1cb19fe,8/11/2016 12:43:36,MDUyYzIwMz,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,50 - 60 minutes,dfa.c:473,dfa.c:1100-1121,noother.c:0,,,The compare operations for characters is wrong.,Extremely confident,,"1. gdb
2. lots of logging
3. lots of staring at the code at dfa.c:473
4. Almost give of
5. Randomly swapping the boolean expressions at dfa.c:473
6. Found working solution
7. Rewrote code to make it more readable
8. Reasoned about solution",in_coll_range always returns same value,"Yes, in principle a tool might be able to explain this error.",After finding it is seems to be straight forward. in_coll_range seems to return the same thing all the time,Not at all difficult,2 - 5 minutes,"Improve readbility by reordering expression
Make sure that the range is correct",Very confident,After finding it and reordering the code it seems to be straight forward. Ran test case manually did some expressions.,,"No, there will never be a tool that can fix this error reliably.","It might be a bit hard because you need to know what in_coll_range is supposed to do. It is supposed to check whether it is in the range. You might be able to guess that from the function name, but it is a guess.
",10 to 20 minutes
grep.c1cb19fe,8/15/2016 3:48:48,MGFkYmExOT,Not at all familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Regression Debugging to identify failure-inducing changes (e.g., git bisect)","gdb, git",30 - 40 minutes,src/dfa.c:469,none.c:0,none.c:0,,,"strcoll() in in_coll_range() src/dfa.c:469 used incorrectly, causing all characters fail to pass the check against a range.",Very confident,,"First I was looking at EGexecute() and dfaexec(). Didn't find (=understand) anything. Then I looked at the last commit in git history and checked previous version. Turns out HEAD~1 version is working well, so I immediately suspect that it's the in_coll_range()'s fault. I haven't much time to fully understand that exactly the original author meant by arranging strcoll()s in that way, so I just rewrote it in more clear (at least for me) way, consistently comparing given char with lower and upper bound. In first case it should be greater, in second - less than according boundary.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,5 - 10 minutes,Rearranged the strcoll() function usage to correctly compare given char against boundaries.,Very confident,It works. And previous version was obviously incorrect.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.9c45c193,3/19/2016 5:46:40,OWUwOTY1N2,Very familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,lib/exclude.c:359,src/grep.c:2268,lib/exclude.c:410,lib/exclude.c:426,,EXCLUDE_INCLUDE flag is accounted twice in both excluded_file_name and excluded_file_pattern_p functions.,Slightly confident,,"1. Being already familiar with this part of source code, I started with looking at excluded_file_name function called at src/grep.c:2268

2. It calls excluded_file_name_p function which was returning false if the file is present in the exclude sequence `seg` (actually an include sequence for the case of --include option)

3. I've made a few test runs with debug output of `excluded` and `rc` variables and found that for the case of --include option the correct return value is negated twice instead of only once.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,removed extra EXCLUDE_INCLUDE option check.,Slightly confident,manual tests.,"I could not build a correct diff for this bug with the tools provided, so I just supplied textual description of the fix.","No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.9c45c193,3/25/2016 0:36:30,YmI4MGM3ND,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",eclipse,10 - 20 minutes,src/grep.c:2136-2140,lib/exclude.c:445,src/grep.c:2261-2286,,,"""include"" option skipped by the incorrect loop within main function src/grep.c:2267+",Very confident,,"1. analyzed source code, located where include option parsed and how it affected to the program;
2. checked code till the place where ""include"" option handled, checked manually, traced to make sure it skipped because the bug;",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,"fixed incorrect condition handling;
was: if ""include"" -> skip
now: if ""include"" -> process",Moderately confident,"test passed, manual run",,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.9c45c193,3/25/2016 20:55:31,MjYyZjkxNm,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",5 - 10 minutes,src/grep.c:1866-1871,src/grep.c:2136-2140,src/grep.c:2260-2283,,,"Files put at --include-dir are never treated by the program.

After picking correctly the files to be included at section 2, we never process them at section 3. The logic there is broken and we skip the file processing.",Moderately confident,,"First I setup a few breakpoints at differents parts of the code, the sections 1 , 2 and 3, to investigate how the include files are treated by the program.
Then I detected that files are stored succesfully but never processed (section 3).
Finally I found that the logic at section 3 was not correct and needs to be fixed because files are never processed",Included files never processed,"No, there will never be a tool that can explain this error.","It is a logic error, the returned value of the function is not treated properly, so difficult to detect with the push of a button. You need to understand the function behaviour.",Not at all difficult,10 - 20 minutes,Applied the logic of excluded_file_name () correctly ,Very confident,"Tested again the scenario, run test case, compared output of current fixed binary with built-in Linux grep command.
Tested same scenario with different files names (not including and including the pattern)",,"No, there will never be a tool that can fix this error reliably.",Difficult to create a tool that can control functions returned values and logic applied,10 to 20 minutes
grep.9c45c193,4/18/2016 21:22:56,ZGU4Yjc1ZG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,src/grep.c:2136-2140,src/grep.c:2267-2269,src/grep.c:2274,,,"For --include, an internal structure included_patterns is built. This happens at src/grep.c:2136-2140. In the original program, this internal structure is not correctly builded (e.g. for patterns there will be an entry intended for hashes). Thus the decision at src/grep.c:2267-2269 is not correctly classifying files and thus wrong files are evaluated at src/grep.c:2274.",Moderately confident,,"First I remember that I have already solved a similar bug and I also remember that solution. But I just ignore this knowledge and traced the program using the given test case. I found out that the result of the function is not correct. I observed the whole trace of excluded_file_name() but I do not know the details about the calculation of hashes and thus I was not able to find the root cause of the bug. Then I tried a test case using a pattern instead of a file and I found out that the behaviour is the same as I already observed in that old bug. Because I already spent to much time I simply tried the same solution as I remember from the old bug. It works for the given test case and also for all my test cases. However, I was not sure about the correctness of this solution before I now I am even less confident about it. But I do not have any test case to show a mistake.",what is the meaning of EXCLUDE_INLCUDE,"No, there will never be a tool that can explain this error.",The tool cannot explain the mistake because it is about changing functionality.,Moderately difficult,5 - 10 minutes,I changed options in a call of a function for manipulating arguments of --include.,Moderately confident,The given test case and my test cases are working.,,"No, there will never be a tool that can fix this error reliably.",The tool cannot change the functionality without the formal model of the correct solution.,20 to 30 minutes
grep.9c45c193,4/25/2016 11:43:21,ZWM2ODBmOG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",50 - 60 minutes,grep/src/grep.c:2267-2269,grep/lib/exclude.c:399-440,grep/lib/exclude.c:355-394,,,"If --include command line option used, program invokes excluded_file_name() function to look for file name in hash table using excluded_file_name_p() (grep/lib/exclude.c:355-394) function invoked through excluded_file_name()  (grep/lib/exclude.c:399-440)call. The same code used for both --include and exclude options but each function returns 'false' on file occurrence when EXCLUDE_INCLUDE option passed and 'true' on another case. But code (grep/src/grep.c:2267-2269) skips the file when 'false' returned. It lets file to check on 'true' return value. So --include option works just the same as --exclude by that way. ",Extremely confident,,"Firs, I ran the program with corresponding options using gdb. Tracing program execution line by line and checking local variables, I found that test functions used for lookup file name in hash table works correctly but returned value made program skip this file instead of check it out. I created second text file to grep and ran program with various --include and --exclude options to be sure.",not sure if there can be a tool to help in this case,"Yes, in principle a tool might be able to explain this error.",A tool could use execution trace to guess why some code area is not executed but it must.,Not at all difficult,1 minute or less,I changed code so it used information about file presence properly.,Extremely confident,It fix the bug and have no side effects.,,"Yes, in principle a tool might be able to fix this error reliably.","If a tool can imagine how execution trace must go, it will be able to change code in proper way.",10 to 20 minutes
grep.9c45c193,4/28/2016 2:55:11,OWMzNDk3N2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",40 - 50 minutes,src/grep.c:2267-2269,src/grep.c:2270-2272,src/grep.c:2274-2275,,,Wrong condition in first region,Moderately confident,,"Find usage of 'include' word
Find usage of 'EXCLUDE_INCLUDE' words
Debug excluded_file_name() function
Read code in main.c what calls excluded_file_name() function
Read and understand wrong code
Fix it",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,Wrong condition,Moderately confident,Tests run successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.9c45c193,5/25/2016 17:40:21,ZjZhNTVkNj,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",kdbg,60 minutes or more,grep/lib/exclude.c:410,grep/lib/exclude.c:359,grep/lib/exclude.c:338,,,The conditional statement needed to be negated. ,Slightly confident,,"1) Ran program with non-numeric file name to eliminate to see if the output changed
2) Ran program removing the ""--include"" flag and checked if the output changed
3) Ran debugger on program with and without the ""--include"" flag and checked for when the execution path diverged.
4) I checked the statements and function calls just before the diverge section of code",,"No, there will never be a tool that can explain this error.",It is hard to connect the dots.,Not at all difficult,2 - 5 minutes,I negated the conditional statement,Slightly confident,It produced the correct output and it passed the automated test.,,"No, there will never be a tool that can fix this error reliably.",There is not enough information to detect this bug automatically.,10 to 20 minutes
grep.9c45c193,6/3/2016 18:14:08,NTM3Y2E1MW,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,src/grep.c:2136-2140,src/grep.c:2262-2276,lib/exclude.c:400-440,,,The program was excluding the file from its searches since there was a not (!) in front of the excluded_file_name(),Very confident,,I understood the code execution through gdb. I tried to understand why x wasnt getting printed. I understood that the function grepfile() was not being called on the file 1 since it wasnt coming till there. I tried to find out why. I realized that the file was being excluded due to a bug and fixed it,,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,I made the code not to exclude the file by removing the ! ,Extremely confident,Applied the patch. Verified the correctness. It seems to be working as expected,,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
grep.9c45c193,7/28/2016 23:17:10,MDliMzQ4OT,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",ack-grep,5 - 10 minutes,src/grep.c:2268,gnulib/lib/exclude.c:399,gnulib/lib/exclude.c:359,,,The call to check whether file is included (region 1) was incorrectly logically inverted. The function performing the check (region 2) does in turn all the necessary logical negations itself (region 3).,Very confident,,"I've grepped option --include and found out where it is put into program configuration (it was global variable included_patterns). Then I've grepped aforementioned variable and found out it was used only in two places in program. I've used trace-based debugging to find out where is the actual case for this bug; finally, I've examined source code of function excluded_file_name() and guessed its result was incorrectly logically negated.",,"No, there will never be a tool that can explain this error.","No way automated tool could ""understand"" relation of --include option parameters to parameters and return values of some function and how to call it correctly.",Not at all difficult,1 minute or less,I've made sure parameters to --include command line argument are processed correctly.,Moderately confident,I've studied and tested it.,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.9c45c193,7/30/2016 21:25:30,ZmU3ZTExOW,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb , prints",20 - 30 minutes,find/grep.c:2267,find/search.c:188,find/grep.c:2139,,,wrong handling of if condition. include argument should be considered and processed but here because of wrong if condition it was just continuing without processing it.,Moderately confident,,first tried to understand the error. Tried different argument and observed the error then I found the exact place where arguments decision are taken and found that if condition was wrong.,,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,10 - 20 minutes,correct use of if condition.,Moderately confident,by runnig test script and checking other functional impacts.,,"Yes, in principle a tool might be able to fix this error reliably.",Because we can set that if included arg is given then it should actually processing it or not.,5 to 10 minutes
grep.9c45c193,8/10/2016 0:35:23,MGFkYmExOT,Not at all familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,grep.c:2268,exclude.c:409,exclude.c:426,,,At grep.c:2268 the included file is incorrectly skipped. The function excluded_file_name() returns if the file should be skipped. Literally. So there is no need to invert it's result.,Slightly confident,,"Checked parsing first. It was ok.
Headed to the filtering in gdb. Noticed the grep.c:2268. At exclude.c:409 I lost my mind.
That's what you get if you use `exclude` to handle `include` in one function. They should name that functions like is_in_list() and handle exclude/include logic in separate place.",,"No, there will never be a tool that can explain this error.",Explanation would be not better than the code.,Moderately difficult,10 - 20 minutes,Removed the unnecessary inversion of the excluded_file_name() function.,Slightly confident, ,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.9c45c193,8/11/2016 13:09:32,MDUyYzIwMz,Very familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",none,2 - 5 minutes,grep.c:2139,grep.c:2263-2275,noother.c:0,,,the included_pattern is used in the same way as the excluded_pattern except a negation. Thus it should have the same flags,Moderately confident,,I already knew where to look. Added a bit of logging and then just set the flags to something that seemed to be reasonable. Worked. Next.,,"No, there will never be a tool that can explain this error.",You need  knowledge about what is expected.,Not at all difficult,1 minute or less,Set the flags the same as the excluded_pattern because they are used in the same way.,Moderately confident,Seems to be trivial. Seems to make sense. Test case works.,,"No, there will never be a tool that can fix this error reliably.",You need knowledge about the intended functionality.,5 to 10 minutes
grep.55cf7b6a,3/20/2016 4:03:27,OWUwOTY1N2,Very familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",none,5 - 10 minutes,src/main.c:1217-1223,src/main.c:1246-1255,src/main.c:1852-1859,,,stdin file is skipped on --device=skip option.,Not at all confident,,"The bug description is pretty clear, so I didn't need any debug actions at all.

1. confirm the bug

2. find how --device option is handled in sources (src/main.c:1852-1859). `devices` global variable is set.

3. find where this variable is used (src/main.c:1217-1223 and src/main.c:1246-1255)",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,fix to not skip file if it is stdin,Extremely confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.55cf7b6a,3/24/2016 1:55:45,YmI4MGM3ND,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, eclipse",10 - 20 minutes,src/main.c:1853,src/main.c:2238,src/main.c:1247,,,"code at the main.c:1247 doesn't take into account that ""skip"" action shouldn't be applied in case of ""input from STDIN""",Very confident,,"1. analyzed source code - main() function, figured out that ""grepfile"" is the last function executed before app exists;
2. traced ""grepfile"" in debugger, figured out it doesn't attempt to read from stdin, finally located error in that function",,"No, there will never be a tool that can explain this error.",,Slightly difficult,10 - 20 minutes,"added additional check ""if file is STDIN - do not apply ""skip"" policy;",Very confident,"started test, compared with non-buggy application",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.55cf7b6a,3/26/2016 0:26:12,MjYyZjkxNm,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)","gdb, editplus(editor)",5 - 10 minutes,src/main.c:403-408,src/main.c:1853-1860,src/main.c:1211-1285,,,"Skip rule for -D option is applied in section 3 to stdout, when the option information says that: ""This option has no effect on a file that is read via standard input"". It should not be applied and input must be processed",Very confident,,"First I added some printf() traces to detect the steps that the code execute using input file (we can not use debugger this time because we use input file at pipe).
Then I detected that at line 1247 (aprox.) the rule was applied and it should not.
Finally I noticed that stdout value was not taken into account to apply this rule.",Skip rule applied to stdout when it should not be applied,"No, there will never be a tool that can explain this error.","I think that this error can be generated by many causes and only debugging manually can determine it, at all using a button.",Not at all difficult,5 - 10 minutes,We must only apply the skip rule when no stdout is in place. Now it was applied always,Very confident,"Repeated the buggy scenario, run the test case supplied, and compared output result with built-in grep command (the command that comes with Linux)",,"No, there will never be a tool that can fix this error reliably.","The tool should know about the command logic and this option in particular, quite complicated to have this tool, it should know about all the options. I keep saying that automated bug fixing requires automated code development, both controlled by tools. When code done manually impossible to fix it with a tool.",20 to 30 minutes
grep.55cf7b6a,4/20/2016 3:44:55,ZGU4Yjc1ZG,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",20 - 30 minutes,src/main.c:1854-1861,src/main.c:1246-1251,src/main.c:1256,,,"For -D the program sets variable devices = SKIP_DEVICES at src/main.c:1854-1861. Before any input is being evaluated, it is checked, if this input should be skipped, see src/main.c:1246-1251. I do not understand all constants used in the if statement at src/main.c:1246-1251 but they somehow include stdin and this is wrong. As the result, return 1 at src/main.c:1256 is being executed for stdin.",Very confident,,First I constructed additional test case which can be used with the debugger (using - at the end). Then I traced the program to find out the part where -D is being served. I noticed if statement with different constants followed by a return statement. I checked documentation for this constants but I was not sure of the exact meaning (does S_ISCHR include stdin?). However I was sure that the bug is in the observed if statement.,what is the meaning of S_ISCHR,"Yes, in principle a tool might be able to explain this error.",The tool can give you a trace and in the case of this bug you will clearly see that return 1 is being executed when the program should proceed further.,Not at all difficult,2 - 5 minutes,I have changed the condition of if statement.,Moderately confident,"Test cases now passed. However, I am not sure if this is the optimal solution (maybe checking of some ""S_"" constant must be added or removed with the same effect).",,"No, there will never be a tool that can fix this error reliably.",This is about changing/adding functionality which I consider not applicable in this kind of C-project.,10 to 20 minutes
grep.55cf7b6a,4/26/2016 11:29:51,ZWM2ODBmOG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",10 - 20 minutes,grep/src/main.c:1217-1218,grep/src/main.c:1246-1255,grep/src/main.c:1209-1346,,,"Program checks and open device for input (grep/src/main.c:1209-1346). If device is stdin, no need to open it due fd of stdin is passed on program start already (grep/src/main.c:1217-1218). Due stdin have S_IFIFO type, SKIP_DEVICE option causing program exit on file stat check (grep/src/main.c:1246-1255). ",Extremely confident,,I ran program using gdb and executed it step-by-step. I found code area where program stop execution and returns. Browsing the code I found logic error that leads to such result.,high level execution diagram may be helpful,"No, there will never be a tool that can explain this error.","In strict terms, it is not an error. Command line option disables stdin usage due it is fifo device so program failed. ",Not at all difficult,5 - 10 minutes,I disabled stdin to be checked if it is a device due stdin is obvious device anyway.,Extremely confident,This is simple and obvious fix.,,"No, there will never be a tool that can fix this error reliably.","Due in strict terms it is not an erorr at all, tool can not make decision why stdin must be skipped on check.",10 to 20 minutes
grep.55cf7b6a,4/29/2016 0:01:29,OWMzNDk3N2,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",printf(),20 - 30 minutes,main.c:1852-1859,main.c:1217-1223,main.c:1246-1255,,,"SKIP_DEVICES set in first range, and in 3 range we check up for device state, and miss checking for STDIN_FILENO.",Moderately confident,,"Find 'D' usage and we got range #1
Find SKIP_DEVICE and we got range #2 and #3
Read the code and find incomplete condition in range #3.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,Fix condition,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.55cf7b6a,6/13/2016 19:34:24,NTM3Y2E1MW,Moderately familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",Didnt use any tool,10 - 20 minutes,src/main.c:1851-1857,src/main.c:1214-1218,src/main.c:1246-1255,,,"SInce we had used -D skip option, the stdin was getting skipped. Ideally, this should not happen for stdin. I added a check to make sure that this doesnt happen

To quote from the MAN page 
""If an input file is a device, FIFO, or socket, use action to process it. If action is ‘read’, all devices are read just as if they were ordinary files. If action is ‘skip’, devices, FIFOs, and sockets are silently skipped. By default, devices are read if they are on the command line or if the -R (--dereference-recursive) option is used, and are skipped if they are encountered recursively and the -r (--recursive) option is used. This option has no effect on a file that is read via standard input.""

This option has no effect on a file that is read via standard input.
the above was missing",Very confident,,"I couldnt use gdb since I could not emulate the stdin in gdb. I tried to find where the directories and the files were getting skipped . I added a few printf statments to understand better. Finally, I added a check and made sure that the input from stdin is treated properly.",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,"I added a check to make sure that ""The option -D has no effect on a file that is read via standard input."" quoting from MAN pages is taken care of.",Very confident,I applied the patch. Verified the correctness. Seems to be correct.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.55cf7b6a,7/28/2016 22:00:48,MDliMzQ4OT,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,ack-grep",10 - 20 minutes,src/main.c:1217,src/main.c:1247,src/main.c:1792,,,There were no checking of file descriptor being stdin when checking for device to skip in region 1.,Moderately confident,,"I've tried to run program under gdb, but failed miserably since i couldn't correctly emulate input from stdin. So I've closely examined source code of function corresponding to opening file (grepfile() it is) and using lots of printfs found out the incorrect condition.",,"No, there will never be a tool that can explain this error.","No way an automated tool would ""know"" meaning of the flag -D, stdin, enum READ_DEVICES, and how they should correspond.",Not at all difficult,2 - 5 minutes,I've made sure -D flag is processed correctly.,Very confident,I've tested it and it works.,,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.55cf7b6a,7/30/2016 22:21:43,ZmU3ZTExOW,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,prints",20 - 30 minutes,grep/main.c:1247,grep/main.c:1254,grep/main.c:1219,,,in wrong case it waas going intto if condition. Actully if we write -D skip then should skip the part instead of exiting program.,Slightly confident,,first I tried using different arguments and checked the behaviour and found that we are expecting exactly opposite of happening. So I reverted arguments of if condition.,,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,negation of the if condition.,Moderately confident,by running provided test script and checking other function effect.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.55cf7b6a,8/9/2016 23:07:02,MGFkYmExOT,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,main.c:1246,main.c:1218,none.c:0,,,desc is STDIN_FILENO at main.c:1218. So if statement is taken on main.c:1246 because stdin is a character device indeed (S_ISCHR (stats->stat.st_mode)).,Very confident,,Find where `devices` variable is used. Trace grepfile() function in gdb. Find that `if` statement is true at main.c:1246.,,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,Added check for stdin file handle.,Very confident,Feels right.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.55cf7b6a,8/11/2016 14:32:40,MDUyYzIwMz,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",none,5 - 10 minutes,main.c:1251,main.c:1217-1220,main.c:1856,,,"stdin is a special device, we still dont want to skip it if -D skip is specified",Extremely confident,,"0. understand that stdin is a special device, we still dont want to skip it
1. grep for 'D' -> find main.c:1856
2. grep for devices -> find main.c:1219
3. understand code",,"No, there will never be a tool that can explain this error.",This seems to be special. stdin is a special device. So it is just to skip it if -D skip is specified. It is just that users expect a different behaviour.,Not at all difficult,2 - 5 minutes,Do not skip if we read from stdin,Very confident,test cases. Trivial fix so not much testing needed.,,"No, there will never be a tool that can fix this error reliably.",Because I fo not believe there will be an automated tool to find it.,5 to 10 minutes
grep.3220317a,3/18/2016 3:13:45,OWUwOTY1N2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,grep/dfa.c:697-726,grep/dfa.c:697,grep/dfa.c:244-276,,,"the setbit_case_fold function was called at grep/dfa.c:697 even if the character is multibyte (i.e. outside of char type). in this case, it is called with -1 value (0xFFFFFFFF) which falls outside of allowed borders",Very confident,,"1. try to reproduce bug with different characters ('é' and 'n'). check backtrace.

2. found that it happens in setbit function; turns out that the bit to set is -1

3. analyze backtrace functions from inside to outside, tracing them. i found that in parse_bracket_exp its inputs are fine, while it mistakenly calls setbit_case_fold with -1 argument which is wrong. So I closely inspected this function to understand how it works and found that multibyte character in charclasses are handled in a different way than single-byte characters.",,"No, there will never be a tool that can explain this error.",,Slightly difficult,5 - 10 minutes,call setbit_case_fold if only the character is single-byte.,Very confident,a few tests with different case (in)sensitivity on multi-byte and single-byte letters.,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.3220317a,3/23/2016 16:28:21,YmI4MGM3ND,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb, eclipse, printf",30 - 40 minutes,src/dfa.c:168,src/dfa.c:274,src/dfa.c:697,src/dfa.c:1053,src/dfa.c:1371,"in case ""setbit"" function receives EOF as first argument (b variable), app crashes because of b used to calculate offset in charclass. in case of b will be EOF, offset will be invalid; Not sure if this a core reason eigher..",Slightly confident,,"First: started app under gdb, analyzed stack trace;
Second: checked what argument in the last function caused segfault;
Finally: Figured out that EOF argument passed when parsing wide character",,"No, there will never be a tool that can explain this error.",,Moderately difficult,20 - 30 minutes,"added guard statement that checks if value passing to ""setbit"" is not EOF",Slightly confident,"Unlikely this is a good fix as most likely logic error in another place. Anyway, it passes the test.",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.3220317a,3/26/2016 2:52:42,MjYyZjkxNm,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",10 - 20 minutes,src/dfa.c:697-698,src/dfa.c:246-275,src/dfa.c:168-168,,,Invalid use of memory address when indexing charclass array at section 1 that causes a Segmentation fault at  section 3 (Section 2 is justa a passing function),Slightly confident,,"First I run the scenario using debugger and found the stack trace for the coredump:

Program received signal SIGBUS, Bus error.
0x000000000040921e in setbit (c=0x7fffffffe210, b=4294967295) at dfa.c:168
168       c[b / INTBITS] |= 1 << b % INTBITS;
(gdb) where
#0  0x000000000040921e in setbit (c=0x7fffffffe210, b=4294967295) at dfa.c:168
#1  setbit_case_fold (b=4294967295, c=0x7fffffffe210) at dfa.c:274
#2  0x0000000000409a5d in parse_bracket_exp () at dfa.c:697
#3  lex () at dfa.c:1053
#4  0x000000000040bd1c in dfaparse (s=s@entry=0x62bfe0 ""[Ã©]"", len=len@entry=4, d=d@entry=0x629880 <dfa>) at dfa.c:1371
#5  0x000000000040e161 in dfacomp (s=s@entry=0x62bfe0 ""[Ã©]"", len=len@entry=4, d=d@entry=0x629880 <dfa>, searchflag=searchflag@entry=1) at dfa.c:3024
#6  0x00000000004065b6 in GEAcompile (pattern=0x62bfe0 ""[Ã©]"", size=4, syntax_bits=2822) at search.c:351
#7  0x0000000000403121 in main (argc=2, argv=<optimized out>) at grep.c:2241

Then I put some traces/printf to detect the cause of wrong initialization of the c variable and finally found that the wrong variable to be used there was the wc one instead the c, because we are supporting multibyte characters",Wrong indexing of charclass maybe,"No, there will never be a tool that can explain this error.","At all, this again requires a deeper understanding of the code itself, impossible with a button",Very difficult,40 - 50 minutes,"I used the suitable variable when MBS_SUPPORT is enabled, the other contained unitialized memory value",Slightly confident,"Run the test case again, and compared output with built-in grep output-",,"No, there will never be a tool that can fix this error reliably.","I do not think that a tool can detect this human mistakes, just using an invalid variable at one point, from the point of view of sintax is correct, noone can determine that it is a mistake till debugged.",10 to 20 minutes
grep.3220317a,4/18/2016 0:33:21,ZGU4Yjc1ZG,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,src/dfa.c:1053,src/dfa.c:498,src/dfa.c:697,,,"The content of brackets is parsed in parse_bracket_exp(), invoked at src/dfa.c:1053.  Character are read within a macro FETCH_WC. In this macro, for ascii characters, variables c and wc both get assigned a current characters, whilst for wide characters variable c gets assigned value -1. Aterwards, at src/dfa.c:697, internal structure ccl is updated using function setbit_case_fold(). But, this internal structure is intended only for use with valid ascii characters and thus we get segmentation fault when trying to use it with c = -1 (this happens for wide characters).",Very confident,,"After some test cases (and problems with using wide characters in ddd) I detected that call to setbit_case_fold() is using wrong argument c. Because the source code is quite long and complex I need some time to find out that this is inevitable consequence of reading wide character and that between reading and using c there is no part of the program which could repair this situation. Thus, this call is clearly wrong but I was lost in complex code not knowing how to modify this call. After detailed study I tried to use wc instead of c and all the test case passes. This was nice but I was not sure about the solution and tried also with simply skiping the problematic call to setbit_case_fold() for in the case of wide character. I was a little bit surprised that all tests passed again. Then I try to skip this call for all characters and the solution was wrong. Finally, I observed the code after setbit_case_fold() and while I do not really understand it I am somehow sure that wide characters are served without using internal structure ccl and that the second solution is better because the first solution only adds some unnecessary information to local structure ccl.",what is the role of internal structure ccl,"Yes, in principle a tool might be able to explain this error.",The tool can give you a trace to segmentation fault and also explain to you where the wrong value origins from. This a quite a useful explanation although if will not help you a lot in solving the problem.,Very difficult,50 - 60 minutes,"If have excluded function call for situations where it is wrong to use it,",Moderately confident,Test case are passing. It is a simple fix but I measured time since I detected wrong value for argument to setbit_case_fold().,,"No, there will never be a tool that can fix this error reliably.",This is about a changing of functionality and not possible without a formal model of the algorithm.,30 to 40 minutes
grep.3220317a,4/26/2016 7:37:58,ZWM2ODBmOG,Moderately familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",50 - 60 minutes,grep/src/dfa.c:168,grep/src/dfa.c:271-274,grep/src/dfa.c:697,grep/src/dfa.c:363,,"While parsing unicode expression, program converting wide char to single byte char (grep/src/dfa.c:363). Function wctob() used for that returns -1 when such conversion not available. Program using returned value to set bit corresponding to found character (grep/src/dfa.c:697). Function setbit_case_fold() seems have guard code for that case but it actually never work due wctob(-1) returns -1 anyway. Using -1 value at grep/src/dfa.c:168 is invalid and causing segfault. ",Extremely confident,,"First I ran program using gdb. After it segfaults, I checked local variables and saw invalid value. I used backtrack and browsing code to see where this values comes from. ",perhaps a tool keeping variables changing history and diagram may help,"Yes, in principle a tool might be able to explain this error.",Tracing back invalid variable values is not so hard.,Moderately difficult,20 - 30 minutes,I did used wide char instead of 8bit char to set bit flag corresponding to character.,Slightly confident,"I did some tests. It works. Due it deeply affect program execution, it have to do a lot of testing to be sure.",,"No, there will never be a tool that can fix this error reliably.","A tool must have vast understanding of result we expecting to get. Without that, it can not determine whether changing a char to wide char is a good idea or bad one. It is mostly the same as write program completely.",20 to 30 minutes
grep.3220317a,4/29/2016 4:26:44,OWMzNDk3N2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf(), valgrind",60 minutes or more,dfa.c:168-168,dfa.c:458-748,dfa.c:341-366,,,"Do not transform multibyte wchar to int in region #3.
",Moderately confident,,"Debug step by step and find region #1 with segmentation fault.
Go up in stack trace and find region #2.
Read body of parse_bracket_exp() function, insert some printf() and find that in region #3 (FETCH_WC macros) do not handled multibyte wchar cases.
Fixed it and tested id.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,5 - 10 minutes,Write function to convert wchar to int.,Moderately confident,Tests finished successfully.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.3220317a,6/10/2016 8:53:32,NTM3Y2E1MW,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,40 - 50 minutes,src/dfa.c:168-170,src/dfa.c:280-282,src/dfa.c:696-699,src/dfa.c:543-545,,The arguments to the setbit_case_fold() method was incorrect and hence the setbit() was computing a value which was out of bounds and hence a bus error was being generated.,Extremely confident,,"I made use of gdb to understand where the program was exiting. 
After studying the code for some time, I understood that the parameter which was being passed was incorrect.
I backtracked the code , wrote a few printf statements to understand where the setbit_case_fold was getting called and the arguments to it.
I was able to figure out that the fetch from a character set and not a wide character set was being sent.",,"No, there will never be a tool that can explain this error.",,Slightly difficult,5 - 10 minutes,"I changed the parameters to the function setbit_case_fold().
",Extremely confident,I applied the patch. Verified the correctness. The program seem to be working fine.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.3220317a,7/31/2016 23:32:35,MjYyYzZkN2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,30 - 40 minutes,src/dfa.c:168,src/dfa.c:274,src/dfa.h:43,,,The root cause was setting bit for character class (region 1) in case of multibyte character (region 2) lead to overflow - the argument was -1 and then casted to unsigned int; while size of character class array is only 32 bytes (region 3).,Slightly confident,,"I've examined core dump; then I've used trace-based debugging to examine values of b and c changing, which confirmed my hypothesis of unsigned overflow.",If only I was told that to copypaste multibyte character to docker console you have to run it with different arguments...,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,I've made sure character classes for mulitbyte characters are set correctly.,Slightly confident,"I've tested it. Also, I've tested case of case insensitive search (-i) and fixed it too.",,"Yes, in principle a tool might be able to fix this error reliably.",,more than 40 minutes
grep.3220317a,8/9/2016 23:55:30,MGFkYmExOT,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,10 - 20 minutes,dfa.c:498,dfa.c:697,dfa.c:166,,,"FETCH_WC at dfa.c:498 returns -1 because wc cannot be represented as one byte. c is then passed to setbit_case_fold() as unsigned, thus causing the segfault in setbit() dfa.c:166.",Very confident,,"In a coredump I found that c is -1 at dfa.c:697.
After stepping through the parse_bracket_exp() I noticed that FETCH_WC returns EOF.",,"Yes, in principle a tool might be able to explain this error.",Seems easy. Wide character cant't be represented as byte and value of EOF handled incorrectly.,Moderately difficult,10 - 20 minutes,"I noticed that the EOF case is handled later and assumed that it is safe just to skip the setbit_case_fold() in this case. Anyway I think is should do nothing in case of when a whole mb char is copied further to work_mbc.

Also, I assume that you meant a '[É]' in your test case, not '[é]'. (Or `grep -i` in that case).",Slightly confident, ,,"No, there will never be a tool that can fix this error reliably.",We will never know if that automatic fix is reliable.,10 to 20 minutes
grep.3220317a,8/10/2016 18:47:47,MDUyYzIwMz,Slightly familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,dfa.c:697-698,dfa.c:245,dfa.c:168,dfa.c:498,,Oob access at dfa.c:168 due to EOF at dfa.c:498,Very confident,,"run gdb and do a backtrace.
add logging because values are optimized out",c is error condition,"Yes, in principle a tool might be able to explain this error.",it is an error value that is -1 leading to ooh access after cast to unsigned. should be easy to catch,Very difficult,20 - 30 minutes,Just skip the call if c is EOF. not confident about this fix. It seems like FETCH_WC is broken due to use of wctob. Probably need major fixing,Not at all confident,ran a few test cases with different flags. compare output with output from 8bit characters,,"No, there will never be a tool that can fix this error reliably.",seems like this bug is caused by some major code revisions that is still in progress. Might need significant rewriting to make it a proper patch.,10 to 20 minutes
grep.db9d6340,3/22/2016 20:04:58,OWUwOTY1N2,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,src/search.c:638-642,src/search.c:644,src/search.c:632,,,"When pattern was matched in the middle of multibyte character, the searching was reset to start over from the beginning of the buffer",Very confident,,"1. run with gdb until it hangs. Ctrl-C

2. `finish` functions until one of them hangs. it was Fexecute function

3. check Fexecute source for possible infinite loops; I traced it and found that at src/search.c:638-642 the for loop is reset to its initial state",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,do not reset the search; just skip a match in the middle of mb character instead,Moderately confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.db9d6340,3/23/2016 15:16:28,MjYyZjkxNm,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",editplus(editor),10 - 20 minutes,src/grep.c:1073-1118,src/grep.c:1028-1066,src/search.c:613-695,,,Infinite loop because control variables are modified outside the for statement,Moderately confident,,"First I put some printf statements to follow the program execution and detect where we have the infinite loop.
Then doing this I reached the function EXECUTE_FCT(Fexecute) at search.c module.
Then analize the loops present at this function with more printf statements
Finally I detected the faulty loop",It is enough with current description in my opinion to detect this bug,"Yes, in principle a tool might be able to explain this error.","If this tool can detect infinite loops with maybe some configurable time controlling the execution of the program, of course",Slightly difficult,10 - 20 minutes,I added a new variable to control the loop itself and avoid infinite loop,Moderately confident,"Run scenario that previously failed, compare execution with built-in grep command at Linux, run the test case associated with this bug",,"Yes, in principle a tool might be able to fix this error reliably.","If this tool can detect loop variables modification outside the loop; I mean within the statements enclosed within the loop itself, yes it could be possible to have a tool",5 to 10 minutes
grep.db9d6340,3/24/2016 16:20:49,YmI4MGM3ND,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, eclipse",30 - 40 minutes,src/search.c:632,src/search.c:638-642,src/search.c:228-256,,,"In case of multi-byte characters in matching string, loop in the Fexecute function never ends because of ""end-of-loop"" condition never evaluated to true src/search.c:638-642) (beg pointer always stays the same, not moving); this is happened because of ""beg"" pointer evaluated as base of ""mb_start"", but mb_start doesn't gen ever modified as it supposed in ""is_mb_middle"" function.",Moderately confident,,"1. started app with gdb, see it hangs, breaked it, checked the stack;
2. repeated (1) few times to make sure it hangs in single place;
3. located the buggy region by analyzing code and tracing in debugger;",,"Yes, in principle a tool might be able to explain this error.","probably some tool like static analyzer could warn about inside ""is_mb_middle"" function",Moderately difficult,20 - 30 minutes,"modified output variable as it supposed to be output (char **) but never get modified within ""is_mb_middle"" function; ",Slightly confident,"I'm still not 100% sure if this correct fix, while it passed the test output still differs from normal grep",,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.db9d6340,4/20/2016 3:09:45,ZGU4Yjc1ZG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",50 - 60 minutes,src/search.c:632-642,src/search.c:640,src/search.c:632,,,"For -F, checking for patterns is executed in kwsexec() called from the loop at src/search.c:632-642. Function kwsexec() returns the offset and the size of the match, offset = -1 means no match. If the match is part of a multibyte character then this it is an invalid match (the whole character should be matched). Thus, at src/search.c:640 the program tries to skip it considering the definition of the loop at src/search.c:632 which has beg++. However, line at src/search.c:640 is wrong and it does not succesfuly skip the invalid match.",Very confident,,"First found out the infinite loop. Then I tried to understand the meaning of different variables involved in the calculation (beg, start_prt, mb_start, offset, kwsmatch). I changed the line at src/search.c:640 by adding offset. The proposed test case passes. Then I created and checked other (more complicated) test cases involving the match in the middle of character. All test passes and thus I was convinced that changing the line at src/search.c:640 is the solution. However, I was not sure about the optimal solution, yet.",,"Yes, in principle a tool might be able to explain this error.",There sequence of actions involving in the infinite loop can be given. This would be some kind of the explanation.,Slightly difficult,10 - 20 minutes,I have changed a formula to calculate the number of bytes that must be skipped.,Very confident,The given and some my test cases passed.,,"No, there will never be a tool that can fix this error reliably.",The tool cannot reliable adds/changes the functionality in this kind of a project.,20 to 30 minutes
grep.db9d6340,4/25/2016 13:21:37,ZWM2ODBmOG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",50 - 60 minutes,grep/src/search.c:632,grep/src/search.c:640,grep/src/search.c:638,,,Within for() loop (grep/src/search.c:632) body its variable counter 'beg' is decreased (grep/src/search.c:640) when it points to middle of a multibyte character (grep/src/search.c:638).,Extremely confident,,"I ran program using gdb with corresponding arguments. After it apparently gone to infinite loop, I interrupted program execution to see program source code where it loops. I checked local variable values and execution trace to determine reason of infinite loop.",this bug is easy to find already,"Yes, in principle a tool might be able to explain this error.",A tool can determine what variable value changes causing infinite loop.,Slightly difficult,2 - 5 minutes,I removed loop counter variable decrease within loop body.,Slightly confident,It works. I made some use case tests and did not noticed any incorrect behaviour.,,"No, there will never be a tool that can fix this error reliably.",It need to imagine whole algorithm logic to understand what must be fixed and why. Explaining it to a tool is the same as completely rewrite program.,10 to 20 minutes
grep.db9d6340,4/29/2016 6:38:40,OWMzNDk3N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",60 minutes or more,search.c:612-695,search.c:638-642,search.c:644-644,search.c:229-256,,"Wrong logic in main loop in region #1 (in region #2).
If is_mb_middle() function return true that we must reassign beg to mb_start, instead to mb_start - 1, and we must to delete 'continue' operator from region #2.",Moderately confident,,"Debug step by step and insert some printf().
Then look to region #1, then to region #2 and region #4 and I got that logic is broken in region #2.",,"No, there will never be a tool that can explain this error.",,Slightly difficult,5 - 10 minutes,Fix logic in loop.,Moderately confident,Tests finished successfully/,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.db9d6340,6/13/2016 20:38:43,NTM3Y2E1MW,Extremely familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",Didnt use any tool,2 - 5 minutes,src/search.c:637-639,src/search.c:677-680,src/search.c:693-695,,,"The previous grep bugs helped me solve this bug quickly. I had seen through the is_mb_middle() code and the way to solve the bug.
The idea was to restrict the code in to going through an infinte loop when it searches for an incomplete non-prefix part of a multi byte char",Extremely confident,,I didnt take much time though. I had an idea how to solve this since I had seen through the code. ,,"No, there will never be a tool that can explain this error.",I am not sure about this,Slightly difficult,2 - 5 minutes,I made sure that the code doesnt go through an infinte loop when it searches for an incomplete non-prefix part of a multi byte character.,Very confident,Applied the patch. It doesnt go through an infinite loop now.,,"No, there will never be a tool that can fix this error reliably.",,less than 5 minutes
grep.db9d6340,7/28/2016 20:26:37,MDliMzQ4OT,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,src/search.c:640,src/grep.c:1046,src/grep.c:1081,,,"The cause of error is when we're in the middle of string and we found multibyte character, the current string index is rewound backwards, whereas the loop goes forwards, so the loop stucks at the start of multibyte character.",Moderately confident,,I've attached to running program and stepped it until I've found a place where it gets stuck.,,"Yes, in principle a tool might be able to explain this error.","Theoretically, and automated tool could detect an infinite loop and present the places in source code where loop index is changed.",Slightly difficult,2 - 5 minutes,I've made sure program does not get stuck on multibyte characters.,Slightly confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.db9d6340,7/31/2016 19:11:45,ZmU3ZTExOW,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,prints",30 - 40 minutes,src/search.c:242,src/grep.c:1202,src/search.c:634,src/grep.c:1180,,"same as find10, handled on few case, it might come other case which should be handled. so every time it was returning same thing and nothing was progressing in for loop hence for loop went in infinite loop.",Moderately confident,,first found the exact infinite loop using prints. then found the problem inside where for loop is going infinitely then again it was calling one method which gives same result every time because the case coming was not handled properly and for loop just hangs.,,"No, there will never be a tool that can explain this error.",,Slightly difficult,10 - 20 minutes,handled all possible case.,Moderately confident,by running provided test script and checking functional impacts.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.db9d6340,8/10/2016 16:37:15,MDUyYzIwMz,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,search.c:639-640,noother.c:0,noother.c:0,,,resetting beg to start of string in loop,Slightly confident,,"1. gdb
2. p beg at search.c:634",,"Yes, in principle a tool might be able to explain this error.",iterating over same memory all the time. easy to detect.,Not at all difficult,5 - 10 minutes,do not reset beg to mb_start,Slightly confident,tested with larger file and some Mb characters,,"Yes, in principle a tool might be able to fix this error reliably.",iterating over same memory. should be easy to find a mutation that stripes over it instead.,5 to 10 minutes
grep.db9d6340,8/12/2016 1:09:10,MGFkYmExOT,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,src/search.c:638,src/search.c:640,src/search.c:632,,,is_mb_middle() at src/search.c:638 returns true and beg pointer reset to something like start of the character (but actually not). It then gets matched again.,Moderately confident,,I was familiar a little with this is_mb_middle() function and checked it from the start,,"No, there will never be a tool that can explain this error.",,Extremely difficult,30 - 40 minutes,"Skip the whole character if we got match in the middle.

I do not know much about multibyte characters and thought that if we got match at the middle we should skip that char. Because maybe there is the case when we can find some arbitrary string like 'abc' in the middle of some very long and complicated multibyte character.
So I decided to skip that character completely.
I do not quite understand the intent of original mb_start - 1, so I've ignored it. We can do just mb_start + 1 so skip one char, but if we got match way past the one byte of, say, 4 bytes multibyte char it will spin in infinity loop again. So we need to skip the whole char staring from last good mb char, i.e. md_start. I've decided to return the pointer to the next char from is_mb_middle() and point beg straight to it.

But there is a problem. My system's grep actually detects a match and prints Ａ to the console. So actually I should have been fix to process the match and display it. But I think it's even more complicated than skipping the char.",Slightly confident, ,,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.c96b0f2c,3/21/2016 6:29:34,OWUwOTY1N2,Slightly familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,60 minutes or more,src/grep.c:1081,src/grep.c:1091,src/grep.c:1060,src/search.c:386-387,src/grep.c:898,"dfaexec function with pattern '^$' returns empty match at the beginning of non-empty strings, while it should not.",Moderately confident,,"1. starting from `grepbuf` function, I traced calls of `do_execute` and `prtext` to check when prtext function is called.

2. turned out that do_execute returns an empty match in the case of empty string pattern ""^$"" on non-empty string and prtext is called to output empty portion of source data, which led to an extra increment and output of the line counter at print_line_head function

3. i traced down into EGexecute and dfaexec function and found that dfaexec returns an invalid match while it should return NULL.","prtext, prline, print_line_head function specifications","No, there will never be a tool that can explain this error.",,Extremely difficult,20 - 30 minutes,"this is a dirty workaround to not call prtext in the case when the matched line doesn't contain anything, even '\n'",Not at all confident,manual tests,"At first I supposed wrong hypothesis about the cause of the bug. I though that was a bug in prtext or one of its subfunctions. I spent too much time analyzing that part of the sources before I understood that the error was somewhere else.

I didn't investigate much into dfaexec function as I've already spent too much time for this issue, so I just added a workaround for the bug into the part of code I'm already familiar with.","No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.c96b0f2c,3/24/2016 23:52:22,YmI4MGM3ND,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","eclipse, gdb",20 - 30 minutes,src/grep.c:1081-1121,src/grep.c:1045-1065,src/search.c:326-522,,,"Code within src/grep.c:1045-1065, while loop doesn't check if any string matched, but prints result; error doesn't happened with ""C"" locale because ""do_execute"" goes in different branch, searches in whole input buffer and always returns  non zero ""match_size""",Moderately confident,,"1. set breakpoint to ""grepbuf"" function that do match and print results;
2. traced app in for both locales (C, UTF8), figured out the difference;
3. figured out the code prints buffer even if match_size = 0;",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,"added extra check - do not process results if there were no matches, just go to next iteration",Moderately confident,"used test, but probably there could be a better fix",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.c96b0f2c,4/15/2016 14:34:25,ZGU4Yjc1ZG,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,src/grep.c:1045,src/grep.c:1087-1088,src/grep.c:1091-1092,,,"If UTF8 mode is set then variable MB_CUR_MAX != 1. Threfore, function do_execute() proceeds diferently, see src/grep.c:1045. Without UTF8 mode, the whole input buffer is consumed at once but for UTF8 mode, input is consumed line by line. In the first case, checking for the end of the buffer after the call to do_execute, see src/grep.c:1087-1088, is always successful. In the second case, the function proceeds further but it is wrong, that this automaticaly means a matched line. Variable match_size must be checked before calling prtext() and incrementing the number of recognized lines, see src/grep.c:1091-1092.",Very confident,,"First, I compared the trace for the given testcases for both configurations. I have made many comparisons (very unfamiliar with the code) and found significant differences. However, for none of the differences I was able to decide wheter it is a bug or a feature. Then I observed only the wrong trace and checked near the line where the extra line is printed out. I found out the part of the code which looks strange, i.e. calling prtext() with strange arguments (the start and the end of the buffer is the same). Finally, additional tests quickly confirmed the location of the bug. The name of variable ""match_size"" helped a bit.",I am very unfamiliar with the algorithms used in grep,"Yes, in principle a tool might be able to explain this error.","The tool can give you details of the wrong trace. It could also evaluate arguments in all call to functions. However, this would be usable only if extra information about the algorithm is given to the tool. The most helpful would be a formal model, but this is probably not applicable to such kind of C projects.",Very difficult,60 minutes or more,If have added a missing if-statement which prevents executing a particular part of the code when it should not be called.,Moderately confident,"Test cases are working. Morevor, considering comments and variable names, the fix looks logical.",,"No, there will never be a tool that can fix this error reliably.",This is about a changing the functionality which is the same as adding new functionality. Not possible without a detailed model of the program and thus not possible for such kind of C projects.,30 to 40 minutes
grep.c96b0f2c,4/27/2016 9:08:27,ZWM2ODBmOG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",60 minutes or more,grep/src/grep.c:1048-1063,grep/src/grep.c:1081,grep/src/grep.c:1087,,,"Program invokes do_execute() function for search a match (grep/src/grep.c:1081). For C locale this function searches in whole buffer but for unicode locales it breaks text into a lines and looking for match in each line separately (grep/src/grep.c:1048-1063). That is why do_execute() function not returns once if whole text contains no match but reporting each line of input text. Due there is no test for unmatched line, -n command line option prints out line number for each line for unicode locale. 8bit locales returns once and leaves loop immediately (grep/src/grep.c:1087).",Extremely confident,,"First I ran program using gdb. Catching 'write' syscall and do backtrace, I found where this function is invoked from. Next, I ran program using gdb with 8bit and UTF-8 locales. Looking at program execution trace and inspecting local variables I found why UTF-8 locale causing handling of each non-matched line.",high level execution diagram may be helpful,"No, there will never be a tool that can explain this error.","Comparing execution trace of program for both correct and incorrect cases, a tool can decide why undesirable output happens.",Slightly difficult,20 - 30 minutes,I did skip of non-matched lines only if they don't required for inverted output.,Moderately confident,It looks like it works. I did some use case tests. Although there is probability that it can affect some modes. It need to do more use case tests to be sure.,,"Yes, in principle a tool might be able to fix this error reliably.",I a tool can alter the source code to avoid undesirable execution traces. ,10 to 20 minutes
grep.c96b0f2c,4/28/2016 23:25:23,OWMzNDk3N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",50 - 60 minutes,search.c:386-387,search.c:388-388,search.c:354-501,,,Incomplete condition in range #2.,Moderately confident,,"Debug step by step in range #3
Add some printf()
I noticed that next_beg may be equal to buflim after range #1
Add extra condition to range #2
Test it",,"No, there will never be a tool that can explain this error.",,Slightly difficult,2 - 5 minutes,Add extra condition,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.c96b0f2c,6/12/2016 19:19:12,NTM3Y2E1MW,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,50 - 60 minutes,src/search.c:323-522,src/dfa.c:2748-2920,src/grep.c:2297-2299,src/grep.c:2308-2309,,A check in the error condition was missing. The code to check if we have matched the sentinel is missing. Phew! Took a lot of amount to detect.,Extremely confident,,"As always, I took the help of gdb. I tried the find out the execution of the program. I took the latest program and compared the execution of that with the buggy program. I ran through the statements and finally understood what was wrong",,"No, there will never be a tool that can explain this error.",,Very difficult,20 - 30 minutes,I added a check to break if it matched a sentinel also which was missing and hence the bug was resulting.,Very confident,Applied the patch. Verified the correctness. The test cases seem to be working,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.c96b0f2c,7/30/2016 18:51:59,MjYyYzZkN2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,30 - 40 minutes,src/grep.c:1060,src/search.c:386,src/dfa.c:2728,,,The hack for multibyte multiline search strings (explained in the comment above region 1) was written wrong: it had off-by-one error in length. So the wrong search string was propagated further (regions 2 and 3).,Slightly confident,,"I've used trace-based debugging to poke around function EGexecute and then found out it got wrong search string (to be precise, wrong length). So I've examined where it comes from and found a code and a comment about splitting multibyte string line-by-line. I've tried to correct its string length detection, and it worked.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,1 minute or less,I've made sure search string length is calculated correctly for multibyte multiline strings.,Slightly confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,30 to 40 minutes
grep.c96b0f2c,8/1/2016 3:15:31,ZmU3ZTExOW,Moderately familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,printf",40 - 50 minutes,src/grep.c:1860,src/grep.c:1062,src/dfa.c:2212,,,Invalid sequence was handled in wrong way. If invalid sequence program should just quit.,Moderately confident,,first started to find code flow with gdb and started putting prints to see what is happening.and then finally I found that if invalid sequence is there we should just exit instead of handling.,,"No, there will never be a tool that can explain this error.",,Moderately difficult,20 - 30 minutes,correct way of handling invalid sequence,Slightly confident,by running provided script and checking functional impact.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.c96b0f2c,8/11/2016 14:11:59,MDUyYzIwMz,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",none,40 - 50 minutes,search.c:394-412,dfa.c:2729-2920,noother.c:0,,,Failed to find in time allocated (45 min),Not at all confident,Not sufficient understanding of code.,Did some logging. Trying to understand code but failed.,,"No, there will never be a tool that can explain this error.",Did not find bug so dont know.,Extremely difficult,1 minute or less,Nothing,Not at all confident,Not at all,Did not find bug.,"No, there will never be a tool that can fix this error reliably.",Because I do not know.,10 to 20 minutes
grep.c96b0f2c,8/12/2016 3:57:06,MGFkYmExOT,Slightly familiar,Extremely difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,src/search.c:339,src/search.c:386,src/search.c:390,,,"Didn't understand this one at all. Why they just memcpy original buffer to case_bug at src/search.c:339? Where case converion applied and how/why it's interfered with result? Why dfaexec() returns not NULL at src/search.c:386? Maybe regexp was parsed incorrectly in the first place? Why it returns pointer past the buffer? Does it mean that there is no match? Can we just check for it somewhere at src/search.c:390? If not, then where is the error? In dfaexec()? But then how it relates to the -i flag?
I am completely lost.",Not at all confident,, ,,"No, there will never be a tool that can explain this error.",,Extremely difficult,1 minute or less, ,Not at all confident, ,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.8f08d8e2,3/20/2016 6:40:33,OWUwOTY1N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,50 - 60 minutes,src/search.c:397-399,src/search.c:408-417,src/grep.c:1007,src/grep.c:997,,"EGexecute function was returning the pattern match itself, instead of the line containing that match",Moderately confident,,"1. find a place where the text is printed. this was done with breaking on 'write' syscall (without -w option yet to workaround line buffering; with this bug no eol character is printed in the test case)

2. compare what does prtext function print with and without -w option at src/grep.c:1007

3. check the values returned by execute function at src/grep.c:1007 (they are not correct for the case of -w option on)",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,copy-paste behaviour from (!match_lines && !match_words) case to match_words case in EGexecute function,Moderately confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.8f08d8e2,3/25/2016 5:02:22,YmI4MGM3ND,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","printf, gdb, eclipse",20 - 30 minutes,src/grep.c:997-998,src/search.c:388-400,src/search.c:388-446,,,"probably cause of error is that ""execute"" function in src/grep.c:997-998 returns match_size equals to only two first words, but I couldn't find where exact line with error code, probably related to regex parser",Slightly confident,,"1. examined ""grepbuf"" code, figured out it calls execute which returns ""match_size"" used for printing results;
2. traced program in both cases: with ""-w"" and without ""-w"" options, figures out it returned different ""match_size"" (equals two firsts words if called with ""-w"" option)
3. analyzed and traced ""execute"" (src/search.c:388-400, src/search.c:388-446) and figures out the code flow goes in different branches in ""-w"" passed.",,"No, there will never be a tool that can explain this error.",,Extremely difficult,30 - 40 minutes,"changed code flow so it calculates match_size same way as it does without ""-w"" option.",Slightly confident,"most likely it's not a good fix because root cause is still not clear for me, but test passed",not enough time to understand corresponding program logic,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.8f08d8e2,3/25/2016 18:09:16,MjYyZjkxNm,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",5 - 10 minutes,src/grep.c:990-1034,src/grep.c:920-978,src/grep.c:862-890,src/search.c:300-488,,"At section 1 we use an incorrect value for line limit value and this is then wrongly used at sections 2 and 3, printing an invalid line value (truncated).
This line limit is wrongly calculated at section 4 when doing regex match",Moderately confident,,"First I run the gdb putting a breakpoint at prline function that is in charge of printing output lines for this command (used to this after several bugs).
Then I printed there the backtrace, it showed this:

#0  prline (beg=beg@entry=0x624000 ""foo foo bar\n"", lim=lim@entry=0x624007 "" bar\n"", sep=sep@entry=58) at grep.c:862
#1  0x00000000004046b0 in prtext (beg=0x624000 ""foo foo bar\n"", lim=lim@entry=0x624007 "" bar\n"", nlinesp=nlinesp@entry=0x0) at grep.c:978
#2  0x0000000000404771 in grepbuf (beg=<optimized out>, lim=lim@entry=0x62400c """") at grep.c:1007
#3  0x0000000000404e40 in grep (stats=0x61c5c0 <stats_base>, file=0x7fffffffe66a ""in"", fd=3) at grep.c:1117
#4  grepfile (file=0x7fffffffe66a ""in"", stats=stats@entry=0x61c5c0 <stats_base>) at grep.c:1248
#5  0x0000000000402414 in main (argc=<optimized out>, argv=<optimized out>) at grep.c:2218

Here we see that lim of the line when calling prline() function and it can only print a truncated line.

Then went backwards to review the calling stack and understand who was putting the invalid value there.

Finally I found that was generated by the EGexecute() function at section 4, we must ensure there that we return the whole line length and not truncated length",Output line truncation,"Yes, in principle a tool might be able to explain this error.","Can be possible if we know the expected result, this button could say ""Line truncation"" and explain the cause",Slightly difficult,10 - 20 minutes,Ensure that the right len is returned (from start till eol) when a match is found instead of the length till the end of matched pattern,Moderately confident,"I repeatead the failing scenario, run the test case, tested it against multiple lines file and compare output with built-in grep command present at Linux box

/root/Desktop/grep6/test/test.sh /root/Desktop/grep6/grep
root@carlos-ubuntu:~/Desktop/grep6# echo $?
0

Tested against multiple lines input file like this:

$ cat in
foo foo bar
foo
kk
foo 1232
foi

$ echo ""foo foo bar"" | ./grep -w '\(foo\) \1'
foo foo bar

",,"No, there will never be a tool that can fix this error reliably.","Complicated to create a tool that detects this, it should know about the logic and nowadays this is impossible",10 to 20 minutes
grep.8f08d8e2,4/17/2016 5:24:48,ZGU4Yjc1ZG,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",30 - 40 minutes,src/grep.c:997-998,src/grep.c:1007,src/search.c:411-414,,,"For -w function execute() when called at src/grep.c:997-998 returns the size of recognized pattern and not the whole line. Therefore, only a part of the line is printed out at src/grep.c:1007. The root cause of the error is in the block at src/search.c:411-414, where the program checks if the pattern was found. In the case of success the part of the program labelled with ""assess_pattern_match"" can be executed. During the test at src/search.c:411-414, variable len keeps the size of the pattern because it must be checked if after the pattern there are correct characters. Butif the pattern is confirmed then the whole line is confirmed and thus variable len should be changed to contain the length of the whole line.  This is missing.",Very confident,,"First I made some test and I found out that -w is the only problematic argument and that LOCALE is not important for this bug. Then I traced the program back from prtext() to find out, why only the part of the line is printed out. I found out, that execute() returns wrong length. Then I traced this function with different test cases (I have compared -w and -e) and also noticed src/search.c:398. Finaly I found out that adding the same line in the other block solves the problem with the given test case.",WCHAR does not denotes wide chars :-),"Yes, in principle a tool might be able to explain this error.","In principle, if the tool would know, what are the correct values for variables at some point it could trace back to see, where the wrong value come from. This would be a kind of explanation.",Slightly difficult,10 - 20 minutes,I have set the value of one variable to the correct value in the right moment.,Moderately confident,Test cases are working.,,"No, there will never be a tool that can fix this error reliably.",To fix this error he tool needs a model of the algorithm and this is not applicable to this kinf of C projects.,20 to 30 minutes
grep.8f08d8e2,4/27/2016 4:24:05,ZWM2ODBmOG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",20 - 30 minutes,grep/src/search.c:448,grep/src/grep.c:882,grep/src/search.c:388,,,Variable 'len' assigned value of regexp match length (grep/src/search.c:388). This value is returned as found match length (grep/src/search.c:448) and used to print out amount of bytes (grep/src/grep.c:882) instead of actual line length. ,Extremely confident,,"I ran program using gdb. Catching 'write' system call, I found that lenght of bytes passed to output is incorrect. Using backtrace and browsing source code I found where this value come from.",High level data diagram may be helpful,"Yes, in principle a tool might be able to explain this error.","Although in strict terms this is not an error, a tool can trace where wrong value is come from if only we can explain to it why output result is bad. ",Slightly difficult,5 - 10 minutes,I passed whole line length instead of regexp pattern match length as return value.,Slightly confident,I did some use case tests. It seems it works but it need a lot of tests to be sure due it could have side effects.,,"Yes, in principle a tool might be able to fix this error reliably.",Unsure if a tool can imagine what result we expecting but if we have a way to explain that it can evaluate expecting line length value.,10 to 20 minutes
grep.8f08d8e2,7/31/2016 13:05:52,ZmU3ZTExOW,Moderately familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb where, prints",30 - 40 minutes,src/grep.c:866,src/grep.c:976,src/grep.c:1116,,,"according to me,correct length was not passed to print so though string was there but we were not printing it as we passed wrong length.",Slightly confident,,"first tried to understand code flow, found everything good, then started printing lines and found that line was correct but we were not printing it as we were passing wrong length. ",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,passing correct length to print.,Slightly confident,by testing via provided script and checking function impacts,,"No, there will never be a tool that can fix this error reliably.",I dont think we can check strlen and made decision based on that only everytime.,5 to 10 minutes
grep.8f08d8e2,8/10/2016 15:26:33,MDUyYzIwMz,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,40 - 50 minutes,search.c:408-452,grep.c:997-1034,grep.c:918-982,grep.c:707-858,,"bad readability of code leading to oversights from the programmer.
",Slightly confident,,"A lot of logging and comparing the execution with and without -w
",,"Yes, in principle a tool might be able to explain this error.","I honestly think the main cause is the readability. Thus it should be easy to create a tool that raises some alarm. Not so sure about explaining the error, but I think with guidance from developer it might be possible",Very difficult,5 - 10 minutes,"added even more spaghetti code.
Jump to correct target if match_words is set",Slightly confident,Run test case with modified input. As in more lines etc pp,,"No, there will never be a tool that can fix this error reliably.",You need semantic knowledge.,10 to 20 minutes
grep.8f08d8e2,8/12/2016 21:02:16,MGFkYmExOT,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,src/search.c:408,src/search.c:414,src/search.c:448,src/search.c:388,src/search.c:398,"When grep finds a match it finally checks for the word boundaries here src/search.c:408. Because there is no special things in our string it takes goto here src/search.c:414, and another goto here src/search.c:448. By this time `len` is 7 as it was at src/search.c:388. So returned match is a sub-string of the whole string. (i.e. ret_val and match_size). And later only this sub-string is printed.
",Moderately confident,,"Nothing special, just a lot of tracing in gdb.",,"No, there will never be a tool that can explain this error.",There should be nothing wrong in the program behavior from the tool's point of view.,Slightly difficult,2 - 5 minutes,"I thought it was ok to return a sub-string from EGexecute (because how -o works then?), but apparently it should always return a whole string, not only the portion that matched. They would adjust `len` to the whole string at src/search.c:398, and moreover -o flag is not broken then we return a whole string. (I wonder how it works then, because I saw they call the same execute() in print_line_middle() for -o)

So I just decided to adjust len to the whole string, it can be done by modifying goto to the line where they adjust `len` to the whole string.",Moderately confident,Checked -o at least.,,"No, there will never be a tool that can fix this error reliably.",Too complicated explanation.,10 to 20 minutes
grep.7aa698d3,3/21/2016 7:14:39,OWUwOTY1N2,Extremely familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,src/grep.c:1060-1062,src/search.c:382-396,src/search.c:388,,,"I with dot' lowered takes 1 less byte, and grep is anaware of such possibility, so it miscalculates the match length for unlowered string.",Very confident,,"This seems to be exactly the same bug that in the 2nd task, so I blindly tried the same fix, and it worked.",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,forced returned match length to be the same as the source line,Very confident,provided test script,,"No, there will never be a tool that can fix this error reliably.",,less than 5 minutes
grep.7aa698d3,3/24/2016 3:43:25,MjYyZjkxNm,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",5 - 10 minutes,src/grep.c:964-1026,src/grep.c:1074-1091,src/grep.c:893-934,,,"Wrong use of lim variable at section 2, when converting to lower case we half its value, but we must continue using the original one for printing",Moderately confident,,"First I went to the prline function that is in charge of printing each line on screen
Then I noticed that there the lim value was incorrect
Finally went backwards through calling functions till detected error at section 2",Wrong line printing,"No, there will never be a tool that can explain this error.","In my opinion it is something complicated to explain with a simple button, debugging depends on programmer ability never compared with a button :-)",Slightly difficult,10 - 20 minutes,Used the right value at lim parameter when printing text and lines,Moderately confident,"Tested scenario that previously failed, run test case supplied, compared output with built-in grep command (grep installed at Linux box)",,"No, there will never be a tool that can fix this error reliably.","Again, and of course in my opinion, debugging is almost an art, unless you force programmers to code using an standard, codes like this will never possible to be fixed with a button, it is so ravelled that I can not believe a tool can solve the complexity of the human mind :-).",10 to 20 minutes
grep.7aa698d3,3/24/2016 4:10:13,YmI4MGM3ND,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, eclipse",20 - 30 minutes,src/grep.c:1071-1119,src/grep.c:1028-1065,src/search.c:385-401,,,"""do_execute"" actual implementation (src/search.c:385-401) returns  match_size (length of matched string in bytes) calclated by lowercased string and it's length in bytes is twice less than original string (because lowecased string using single byte per character)",Very confident,,"Fisrt: narrowed down to the code that prints match (prtext within grepbuf function (src/grep.c:1071-1119))
Second: figured out that it prints output depending on ""match_size"" returned by ""do_execute"" (src/grep.c:1028-1065)
Finally: checked ""do_execute"" actual implementation (src/search.c:385-401) and figured out that match_size returned after source string lowercased and it's length in byte is twice less;",,"No, there will never be a tool that can explain this error.",,Moderately difficult,20 - 30 minutes,"added flag telling if there were lowercase conversion. at the end of ""do_execute"" function added correction for ""match_size"" by doubling it if lowercase correction happened before.",Slightly confident,"most likely it's not a good fix but workaround (quirk), but test passed with this patch",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.7aa698d3,4/16/2016 22:23:34,ZGU4Yjc1ZG,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,src/grep.c:1081-1085,src/search.c:388,src/grep.c:1091,,,"Function do_execute() check buffer for a match and returns the size of the match, see src/grep.c:1081-1085. This information (variable match_size) is then used to print out the matched line and also to guide following searches (there could be more than one line in the buffer at once). But for UTF-8, if -i is used then during the search for a match then current line is transformed to lowercase letters, see src/search.c:388 and for some characters the length in bytes differ from the original. In such cases, variable match_size will contain number of bytes in the transformed line, not in the original line and prtext at src/grep.c:1091 will print out wrong text. Regarding the root cause, the situation was already explained in the bug description but the solution is not obvious. During the transformation to lowercase letters no info about mapping is recorded and, indeed, it could not be recovered by simply reverse action (i.e. change to uppercase).",Moderately confident,,First I spent quite a lot of time to understand the description of the bug. I am not familiar with UTF-8 and all that functions on wide characters. First I was trying to detect a wrong part of code which caused that the length of temporal line is returned from do_execute() instead of the length of original line. But I could not find any bad part of the code. Finaly I decided that the original code should not be changed (i.e. it would require a total reorganization) but some additional code should be added to resolve the bad situation after the call of do_execute().,variable match_size is used also to guide following searches,"No, there will never be a tool that can explain this error.","If you can mark the wrong situation than the tool can give you a trace. However, for this bugthe trace is not very helpful in explaining the error because, basically, the error is a missing functionality which can be implemented in many different ways.",Very difficult,60 minutes or more,If have adapted the value of one variable (by adding code which recalculates the size of matched string) in those situations where the original program gives wrong result.,Moderately confident,Test cases are working.,,"No, there will never be a tool that can fix this error reliably.",This is about a missing/wrong functionality and it is hard to describe the correct behaviour with a formal model in such type of C projects.,30 to 40 minutes
grep.7aa698d3,4/26/2016 8:32:51,ZWM2ODBmOG,Very familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",10 - 20 minutes,grep/src/search.c:384-392,grep/src/grep.c:926,grep/src/search.c:557,grep/src/grep.c:1085,,"On case insensitive search, program lowering case of input string (grep/src/search.c:384-392). Length of pattern found is returned as match_size (grep/src/search.c:557). This value used to calculate length of buffer to print (grep/src/grep.c:1085). Program prints out such number of bytes (grep/src/grep.c:926). Lowering case of some unicode characters make them single-byte. So match_size is regarding to length of lowered case string, it not always be equal to length of source line which have to be printed out. That is why output string may contain different number of characters than input string has.",Extremely confident,,"First I ran program using gdb. Caught 'write' system call I found that number of bytes to be printed is not equal to actual length of line in buffer. Using backtrace, browsing source code and executing program with gdb to inspect local variable values, I found reason why incorrect number of bytes passed.",perhaps a tool keeping variables changing history and diagram may help,"Yes, in principle a tool might be able to explain this error.",A tool can trace program execution back to see where incorrect value is come from.,Moderately difficult,10 - 20 minutes,I did number of bytes returned matching to input line instead of  lowercased line.,Slightly confident,I did some use case tests. It seems working. Although it need to do a lot of tests to be sure due the patch deeply affects to program execution.,,"No, there will never be a tool that can fix this error reliably.",Knowing how many bytes have to be printed out seems require deep understanding of program application.,10 to 20 minutes
grep.7aa698d3,4/28/2016 22:02:51,OWMzNDk3N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",60 minutes or more,search.c:388-388,search.c:391-391,search.c:555-555,,,"In region 1 we create new string with lower case, in 2 region we override pointer to origin string. And in 3 region we count length of origin sting in terms of new lower case string. But when we move from upper to lower case size of chars and size of string would be changed, so we can not do it like in region #3.",Moderately confident,,"Debug step by step
Insert some printf()
Read EXECUTE_FCT(EGexecute) function",,"No, there will never be a tool that can explain this error.",,Extremely difficult,10 - 20 minutes,I could not fix this bug,Not at all confident,I could not fix this bug,"It is so difficult, and I think that this project needs to change work with Unicode cardinally. Need global refactoring.","No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.7aa698d3,6/13/2016 15:41:20,NTM3Y2E1MW,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,40 - 50 minutes,src/grep.c:2240-2242,src/searh.c:387-388,src/searchutils.c:60-113,,,The problem I figured was in the mbtolower() function. mbtolower adds a NUL byte at the end. I am guessing this must be the problem.,Moderately confident,,I used gdb to understand the code execution. This process was cumbersome. I had to literally step through all the lines and see how it worked. I understood that there is something amiss with the mbtolower() eventually.,,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,"I have removed the mbtolower()  function and just allocatted space for case_buf and used memcpy(). I am guessing the mbtolower() adds a null byte at the end and this may be the reason.
",Moderately confident,"
This fix might create some other bugs. I am not sure if it's a clean fix.
But the test case is working.",,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.7aa698d3,7/30/2016 14:59:26,ZmU3ZTExOW,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,prints",20 - 30 minutes,src/search.c:94,src/search.c:119,src/grep.c:2004,,,wrong use of condition. coder has assumed only cases to go in if condition but user can enter anything so if condition was not put properly.,Very confident,,"first I started wit hcode flow. Checked the differece between putting -i and not putting. Put some print and check the size of variable then found that only the 3 sizes were taken care of, other size were not checked. ",,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,10 - 20 minutes,proper use of if condition,Very confident,by running provided test script and checking functional impact.,,"Yes, in principle a tool might be able to fix this error reliably.",because if condition check was with size that can be coded and tested.,5 to 10 minutes
grep.7aa698d3,8/1/2016 23:19:43,MjYyYzZkN2,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c)",ack-grep,10 - 20 minutes,src/grep.c:1091,src/grep.c:1060,src/search.c:388,,,"When printing matching line (region 1), the length of string to be printed is determined by function execute (region 2), which, in this case, transforms string to lower case using mbtolower (region 3) thus losing information about bizzare characters which occupy different memory sizes in lower case and upper case.",Slightly confident,,"I've grepped where the matched string is printed (using trace-based debugging), which led me to EGexecute() function returning wrong size. I've examined its source more closely and found out the bug right at its start.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,30 - 40 minutes,I've made sure string length for multibyte character strings are calculated correctly in case of case insensitive search.,Slightly confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,
grep.7aa698d3,8/4/2016 18:39:38,MDUyYzIwMz,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,40 - 50 minutes,search.c:374-570,grep.c:1040-1071,grep.c:892-920,,,Honestly I have no idea. You said I should stop after 45 mins. So I did.,Not at all confident,"Cryptic code 
not sufficient documentation
Not able to understand the workflow of the code","1. gdb
2. fprintf
3. Code inspection",,"No, there will never be a tool that can explain this error.",I have no idea because i did not find the bug.,Not at all difficult,1 minute or less,I have no idea because i did not find the bug.,Not at all confident,I have no idea because i did not find the bug.,,"No, there will never be a tool that can fix this error reliably.",I have no idea because i did not find the bug.,less than 5 minutes
grep.5fa8c7c9,3/20/2016 4:58:27,OWUwOTY1N2,Slightly familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,src/kwsearch.c:103-122,src/searchutils.c:117-145,src/main.c:1019,src/main.c:998,,"empty match is a degenerate case when `is_mb_middle` always returns true, which was not accounted in Fexecute function.",Moderately confident,,"1. trace with gdb to find where an infinite loop takes place (Fexecute function)

2. trace this function to see which part is repeated (src/kwsearch.c:103-122). I traced it twice, with empty pattern and with non-empty pattern.

3. the difference turned out to be mbrlen function was returning non-zero with len=0, which led to the infinite loop",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,"skipped is_mb_middle check if len=0. this is not the most efficient way though, we could just check for existance of an empty pattern and output each source line without matching at all.",Very confident,manual tests,,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
grep.5fa8c7c9,3/23/2016 21:46:45,YmI4MGM3ND,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, eclipse",10 - 20 minutes,src/kwsearch.c:80,src/kwsearch.c:101,src/kwsearch.c:108,src/searchutils.c:117,,"src/kwsearch.c:101 loop never ends because  variable used in ""loop finish"" condition get re-initialized in case ""no match"";",Moderately confident,,"1. started program under gdb, see it hangs, paused it, see stacktrace, repeated few times to make sure faulty function is located approximately (kwsearch.c:Fexecute);
2. traced loop inside this function to make sure it never ending;
3. located faulty code (kwsearch.c:108-122)",,"Yes, in principle a tool might be able to explain this error.",static analyzer could probably help here,Slightly difficult,10 - 20 minutes,"added check for ""zero match"" so loop can finish",Moderately confident,"Not really sure if it 100% good fix, but test passed. Another fix is to move check for ""match length"" into is_mb_middle function",,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.5fa8c7c9,3/25/2016 19:27:32,MjYyZjkxNm,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",10 - 20 minutes,src/main.c:1010-1057,src/kwsearch.c:136-152,src/kwsearch.c:101-122,,,Infinite loop at logic of FExecute function within section 3,Moderately confident,,"First I put a breakpoint at grepbuf() function and executed step by step this function noticing that there was an infinite loop at do_execute()
Then I debugged step by step this function to detect the calls it does
Then I found that the root cause was at sections 2 or 3
Finally I isolated the root cause at section 3, something is wrong there with the loop that generates an inifinite loop",I think that is OK the current description of the error,"Yes, in principle a tool might be able to explain this error.","This type of errors (inifinite loop) can be easily explained by the push of the button, of course the final root cause it is complicated to detect with tools (I mean the error at loop) but the at least we can easily detect that it is an inifinite loop.",Moderately difficult,20 - 30 minutes,0 length scenario was not treated properly when doing search and caused inifinite loop,Moderately confident,"Repeated tests that previously failed, run test case supplied and tested $? is now 0, compared output with built-in grep command present at Linux. Created some regression scenarios using multiple lines file, with matching and non-matching conditions",,"No, there will never be a tool that can fix this error reliably.","If we can create a tool that checks for every possible value returned in this case for the border effect of 0 values we can fix this type of errors, but it is really difficult because we should know also which logic to apply for 0 value scenario",20 to 30 minutes
grep.5fa8c7c9,4/18/2016 5:54:19,ZGU4Yjc1ZG,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",20 - 30 minutes,src/kwsearch.c:101-155,src/kwsearch.c:106,src/kwsearch.c:108,src/searchutils.c:116-146,src/kwsearch.c:113-121,"For -F, loop at src/kwsearch.c:101-155 is being executed. First, a call to kwsexec() is used to check for matching. If there is a match, variable len gets the size of the match, see src/kwsearch.c:106. Then, if using UTF-8 mode, a specific test is made to check whether the match is a part of multibyte character, see  src/kwsearch.c:108. This test includes a call to is_mb_middle() implemented at src/searchutils.c:116-146. In the case of len=0 (which happens when matching with """" which by definition matches anything) this function returns true but actions performed at src/kwsearch.c:113-121 are wrong for len = 0,",Very confident,,"First I find out where is the infinite loop. I have quickly find out that for pattern="""" function is_mb_middle() gets len=0. First I was thinking that the loop in function is_mb_middle() is problematic but then I find out that this loop finishes but the function is_mb_middle() is called over and over. Thus I checked the part of code which calls this function and I found out that function is_mb_middle() returns true even for situations where there are no wide characters involved and that the result of actions performed after function is_mb_middle() is not always in line with the written comment. Because """" is not a wide character, I got the idea to simply avoid the problematic part of code for pattern="""". Because the given test and also my tests with wide characters passed I was satisfied with this solution and did not looked further.",,"No, there will never be a tool that can explain this error.",The tool can detect infinite loop and it can show you a trace. In this situation two states are exchanged forever and thus this trace would be quite short. But I think that it would not explain a root cause of the problem which is that this part of code should not be execute at all.,Slightly difficult,5 - 10 minutes,I changed one decision in such a way that a particular part of the code is not executed when it would be wrong to do this.,Moderately confident,The given test and also my additional tests passed.,,"No, there will never be a tool that can fix this error reliably.",The tool cannot change a functionality without having a model of the expected behaviour.,30 to 40 minutes
grep.5fa8c7c9,4/26/2016 12:20:31,ZWM2ODBmOG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",20 - 30 minutes,grep/src/kwsearch.c:101-121,grep/src/searchutils.c:145,grep/src/kwsearch.c:108,,,Program goes to infinite loop (grep/src/kwsearch.c:101-121) due is_mb_middle() function invoked (grep/src/kwsearch.c:108) always returns 'true' for 0 length value (grep/src/searchutils.c:145). So program decides that it is in middle of multibyte character but can not advance due there are no bytes character at all.,Extremely confident,,"First, I ran program with gdb. After it goes to infinite loop, I interrupted it. By tracing execution and inspecting local variables I found that is_mb_middle() function always returns 'true' what is apparently wrong.",this bug is easy to find already,"No, there will never be a tool that can explain this error.",A tool must have common sense imagination to know why it is unable to be in a middle of non-existent multibyte character.,Not at all difficult,2 - 5 minutes,I disabled to check if it is a middle of multibyte character if it have zero length,Extremely confident,This is simple and obvious. ,,"No, there will never be a tool that can fix this error reliably.",I am not sure how a tool can decide why zero length multibyte character have no middle position.,5 to 10 minutes
grep.5fa8c7c9,4/28/2016 18:09:33,OWMzNDk3N2,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",40 - 50 minutes,kwsearch.c:101-155,kwsearch.c:118-118,kwsearch.c:101-101,,,Wrong instruction,Moderately confident,,"Debug
Pause, find that program hand in region #1.
Read region #1
Printf 'beg' values in region #1
Find that 'beg' value is set in region #2
Remove region #2",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,Remove wrong instruction,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.5fa8c7c9,6/1/2016 7:15:11,ZjZhNTVkNj,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",kdbg,60 minutes or more,grep/src/kwsearch.c:121,grep/src/kwsearch.c:121,grep/src/kwsearch.c:121,,,An erroneous continue statement circumvented the intended execution path.,Moderately confident,,"1) Ran the program
2) Attached to the running process using kdbg
3) Identified the loop that ran infinitely",,"No, there will never be a tool that can explain this error.",It is hardly to draw meaning from the statement that caused the infinite loop.,Moderately difficult,20 - 30 minutes,Removed line number 121 from kwsearch.c,Moderately confident,It produced the expected output and it passed the automated test,,"No, there will never be a tool that can fix this error reliably.",It would be really hard to detect the cause of an infinite loop like this.,5 to 10 minutes
grep.5fa8c7c9,6/13/2016 5:19:21,NTM3Y2E1MW,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,src/main.c:1019-1020,src/main.c:982-984,src/kwsearch.c:100-155,src/searchutils.c:116-146,,"Well, to be honest , I did not quite understand everything about the bug
is_mb_middle was returning true for when it wasn't supposed in turn making the for loop to become infinite",Moderately confident,,"Using gdb, I tried to understand where it getting stuck.
I figured out the for loop in the Fexecute() eventually
I realized that the function is_mb_middle was returning true when it wasnt supposed which was leading to the loop running infinite times",,"No, there will never be a tool that can explain this error.",,Slightly difficult,10 - 20 minutes,I changed the is_mb_middle return statement accordingly.,Slightly confident,Applied the patch. Not running in infinite loop. Working as expected.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.5fa8c7c9,7/28/2016 20:11:02,MDliMzQ4OT,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,src/kwsearch.c:120,src/kwsearch.c:116,src/main.c:984,,,There were no checking for search string being empty in case of multibyte characters (region 1).,Slightly confident,,I've attached to running program and went the control flow step-by-step until noticing the comment about advancing and infinite loops and noticing the beg pointer isn't advanced at all.,,"No, there will never be a tool that can explain this error.",,Not at all difficult,1 minute or less,I've made sure mulitbyte character case of empty search string is processed correctly.,Slightly confident,I've tested it.,,"No, there will never be a tool that can fix this error reliably.",,20 to 30 minutes
grep.5fa8c7c9,7/30/2016 22:44:20,ZmU3ZTExOW,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,printf",20 - 30 minutes,find/kwsearch.c:33,find/kwsearch.c:73,find/kwsearch.c:166,find/kwsearch.c:101,,only one case was taken care of. multibyte character may be size of -1 or 0 or <0 and so on but condition was only for -2. so it was going in loop if we dont handle other sizes. ,Very confident,,first found the code flow. There is one bug in find utility with same case So I had bit idea and I found exactly same error here.,,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,10 - 20 minutes,handled more possible cases. ,Very confident,by running provided test script.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.5fa8c7c9,8/10/2016 16:15:38,MDUyYzIwMz,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,kwsearch.c:115,noother.c:0,noother.c:0,,,Infinite loop due to resetting beg to mb_start,Very confident,,"1. gdb
2. bt
3. inspect some variables
4. add some logging
5. read code and understand it",,"Yes, in principle a tool might be able to explain this error.",Integrating over the same memory all the time. should be easy to catch,Moderately difficult,20 - 30 minutes,Do not reset beg to mb_start,Moderately confident,tested with larger file.,,"Yes, in principle a tool might be able to fix this error reliably.",Bug iterates over same memory. removing line fixes this. Good candidate for automatic fix.,10 to 20 minutes
grep.5fa8c7c9,8/10/2016 22:31:07,MGFkYmExOT,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,kwsearch.c:108,kwsearch.c:120,kwsearch.c:101,,,"is_mb_middle() returns true at src/kwsearch.c:108, but we are not in the middle of the multibyte char, so it ends up at the start of the string at kwsearch.c:120.",Moderately confident,,Hit ctrl+c in gdb while hang. End up in for loop at kwsearch.c:101,,"No, there will never be a tool that can explain this error.","Tool might think that it's a normal behavior of a program. Maybe it can point to where it hangs, but I doubt it can say that it's because a non-multibyte char handled as part of multibyte char causing it.",Slightly difficult,10 - 20 minutes,"Added check for an empty match in is_mb_middle().

I do not know if we actually may enter in is_mb_middle() with empty match string and on middle of a mb char. So maybe it should be handled in outer loop somehow. Or somehow completely differently.",Slightly confident, ,,"Yes, in principle a tool might be able to fix this error reliably.",But without explanation it will be worthless.,5 to 10 minutes
grep.58195fab,3/19/2016 4:31:40,OWUwOTY1N2,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,src/grep.c:2139,src/grep.c:2264-2273,lib/exclude.c:417-427,lib/exclude.c:445-487,,"Basically, the ability to specify filename glob patterns for --include option was not turned on.",Very confident,,"1. find place in the code responsible for include/exclude behavior: src/grep.c:2264-2273

2. specifying different --include & --exclude combinations and using some debug output I've found that --include option is generally ignored inside lib/exclude.c:417-427 (excluded_file_name function)

3. I traced that function. there are two ways to check for the pattern: via exclude_pattern flag and via exclude_hash flag. When checking inclusion pattern, every time exclude_hash was used (so a hash table was tested to contain current file name, but this just couldn't work for glob patterns containing * character), so I supposed that grep cmdline parsing works incorrectly.

4. found the place where --include and --exclude options are parsed: src/grep.c:2139. I investigated add_exclude function which is called there (lib/exclude.c:445-487) and found that (options & EXCLUDE_WILDCARDS) is applied. But EXCLUDE_WILDCARD options is not passed to this function for --include patterns.",--include option doesn't work generally with any glob pattern,"No, there will never be a tool that can explain this error.",,Not at all difficult,5 - 10 minutes,I've turned on EXCLUDE_WILDCARDS option for --include cmdline argument,Very confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.58195fab,3/25/2016 3:30:25,YmI4MGM3ND,Slightly familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",eclipse,30 - 40 minutes,src/grep.c:2135,src/grep.c:2115,src/grep.c:2258-2285,lib/exclude.c:398-440,lib/exclude.c:445-487,"1. included_patterns initialized without ""EXCLUDE_WILDCARDS"" flag - getting matched in wrong way (src/grep.c:2135)
2. loop in ""main"" function src/grep.c:2258-2285 handling ""excludes"" and ""includes"" in wrong way. especially, when checking ""excluded_file_name"" there's no need to invert result as it handled internally with EXCLUDE_INCLUDE flag",Moderately confident,,"1. traced main loop which iterating over include/exclude options - figured out it was wrongly implemented;
2. traced excluded_file_name, figured out it returned wrong result because include wildcards should be processed in ""exclude_pattern"" branch;
3. traced add_exclude, figured out it requires EXCLUDE_WILDCARDS flag for wildcards;
4. in main loop (), when checking ""excluded_file_name"" with ""included_patterns"" - there's no need to invert result as it handled internally with EXCLUDE_INCLUDE flag",,"Yes, in principle a tool might be able to explain this error.",,Moderately difficult,20 - 30 minutes,"fixed couple logic errors: missed ""wildcard"" flag for includes and wrong logic while processing includes/excludes
",Moderately confident,"run the test, run on test data manually",,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
grep.58195fab,3/26/2016 1:55:25,MjYyZjkxNm,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",30 - 40 minutes,src/grep.c:2136-2140,src/grep.c:2136-2140,lib/exclude.c:399-440,,,"Not added support to wildcards correctly at --include option at section 1,",Moderately confident,,"First I run the buggy scenario
Then added some traces/printf at sections of code where it is evaluated the result (Section 2)
Finally detected that WILDCARD option was not passed to the exclude struct and that was the reason of the error and not to treat the patterns properly",Wrong exclude options,"No, there will never be a tool that can explain this error.","Impossible, it depends on how the code it is implemented",Very difficult,50 - 60 minutes,Exclude options initialization was wrong.,Moderately confident,"Run the buggy scenario again, run the test case again, Compare output with built-in grep command.
Run new scenarios changing settings, like doing grep with no match, with different include/exclude options (kind of regression test)",,"No, there will never be a tool that can fix this error reliably.","It depends on code options and how they are implemented, impossible for a button.",10 to 20 minutes
grep.58195fab,4/16/2016 6:00:00,ZGU4Yjc1ZG,Slightly familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",60 minutes or more,src/grep.c:2136-2140,src/grep.c:2267-2269,src/grep.c:2274,,,"For --include, the program call add_exclude() with wrong arguments, see src/grep.c:2136-2140. In the original program, wildcard patterns were simply ignored and files get added with wrong options (i.e it will be recognized in the way as if they are in --exclude). Because of wrong information stored in variable included_patterns, files are not correctly classified at src/grep.c:2267-2269. Thus, wrong files go for evaluation in src/grep.c:2274.",Moderately confident,,"First I found out that --include is wrong regardless of --exclude and that --exclude is in fact correct.  Then I found the loop, where the files are selected for evaluation. I could not immediately see the bug, but I considered function excluded_file_name() as correct because it is outside of the project. I made many tests with different patterns for --include and I also compared information stored for --include and --exclude. Finaly, I have decided that the bug is about missing or wrong flag given to excluded_file_name() and, maybe also  in evaluation of info obtained from excluded_file_name().",where and how are checked arguments given to --include and what is the meaning of flags used in excluded_file_name(),"No, there will never be a tool that can explain this error.",It is about wrong/missing flags and the tool cannot know what is missing.,Very difficult,60 minutes or more,I have changed wrong flag in a call to a particular function .,Moderately confident,Test cases are working.,,"No, there will never be a tool that can fix this error reliably.",This is about changing functionality and the tool cannot do this automatically for such type of  projects.,30 to 40 minutes
grep.58195fab,4/26/2016 23:14:48,ZWM2ODBmOG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",20 - 30 minutes,grep/src/grep.c:2267-2269,grep/lib/exclude.c:417-431,grep/lib/exclude.c:449-450,grep/src/grep.c:2139,,"Program tests input file name on include/exclude list match (grep/src/grep.c:2267-2269).  Depended on command line option, file matched to a exact name or to a wildcard pattern (grep/lib/exclude.c:417-431). Wildcard pattern rule is added only when EXCLUDE_WILDCARDS option passed to add_exclude() function. But add_exclude function invoked on command line parsing have no such option passed (grep/src/grep.c:2139). ",Extremely confident,,"First I ran program using gdb. Executing program step-by-step I found lines of code corresponding for decision about does it handle a file or not. Invoking excluded_file_name() function with various arguments I found that inlcuded_patterns does not works but returns the same value for any file name. Tracing function execution I found that it trying to test file name against exact name, not wildcard as ough to be. Next, I found code area where this rule was added. Using breakpoint and tracing add_exclude() function execution I found, that wildcard handling is disabled due options argument passed. ",not sure if there can be a tool to help in this case,"No, there will never be a tool that can explain this error.","In strict terms, this is not an error. A tool can not determine if wildcard usage disabled in this case either by at will or by error.",Not at all difficult,2 - 5 minutes,I enabled wildcars usage for --include command option.,Extremely confident,This is simple and obvious. It works and has no side effects.,,"No, there will never be a tool that can fix this error reliably.","If only a tool can guess what it have to do, it can add corresponding flag. But exact flag placement is depend on high level logic. That is why the option passed as function argument instead of removing its check in function or add it to function as constant value. Maybe function specification passed to a tool could help tool to choose correct decision.",10 to 20 minutes
grep.58195fab,4/29/2016 1:30:03,OWMzNDk3N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",60 minutes or more,grep.c:2136-2139,lib/exclude.c:450-451,grep.c:2115-2118,,,"Missed argument in range #1, must be like in range #3:

add_exclude (included_patterns, optarg, EXCLUDE_INCLUDE | EXCLUDE_WILDCARDS);
instead of
add_exclude (included_patterns, optarg, EXCLUDE_INCLUDE);",Moderately confident,,"Debug step by step
Insert some printf
Then look to range #1 and range #2 and compare it, also in range #2 we check up for EXCLUDE_WILDCARDS and we in test case also using wildcards, so I suppose that EXCLUDE_WILDCARDS argument is missed.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,1 minute or less,Add missed argument,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.58195fab,6/13/2016 17:04:26,NTM3Y2E1MW,Slightly familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,src/grep.c:2129-2141,lib/exclude.c:444-487,lib/exclude.c:114-135,,,The option EXCLUDE_WILDCARDS was missing in the included option and hence this was including all the files other than those with .e ,Very confident,, I saw that the output was the same in  the 2.12 version as well. I couldn't quite figure out why this piece of information was given. I saw that the grep was including all the files irrespective of the wildcard and hence I eventually found out the fix,"I dont know why 2.12 version info was given..I personally couldnt figure out much from that clue. In fact, I wasted some time and I couldn't  find anything. And also some extra test cases could have been helpful like ./grep --include=""*.e""  abc * , this also fails to give the correct output","No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,"I added the option EXCLUDE_WILDCARDS option in the included pattern so as to take care of the regexpression while  including the files.
",Moderately confident,I applied the patch.It is working as expected,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.58195fab,8/1/2016 2:59:02,ZmU3ZTExOW,Moderately familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, prints",40 - 50 minutes,src/grep.c:2267,lib/exclude.c:457,lib/exclude.c:465,,,* pattern is not getting recognised by program. So wildcard entries are not working.,Not at all confident,,found the code flow using prints but couldnt find any bug. I found one where where it should be negation used in if condition and gnulib should have correct behaviours of wildcard patterns. Without wildcard behaviour it is working.,,"No, there will never be a tool that can explain this error.",,Extremely difficult,20 - 30 minutes,changing correct argument in if condition. ,Not at all confident,I have done fix from my side. I think still needs to be done in library because wildcard patterns are not working but direct file name is working now.,Dependency on library. Because wildcard patterns are not working but if I give directory name It is working so lib should be updated. I have done fix from my side in src folder. Still it needs to be fixed.,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.58195fab,8/1/2016 21:21:10,MjYyYzZkN2,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,src/grep.c:2139,src/grep.c:2268,gnulib/lib/exclude.c:419,,,"When filling include pattern structure from command line (region 1), it was missing type flag EXCLUDE_WILDCARDS, so then, when choosing to exclude/include file in search (region 2) and calling corresponding function, the pattern was interpreted incorrectly (region 3 - it went on second switch case, even though it should've go first). So plain file include pattern worked alright, but the regex one (including asterisks etc) was screwed.",Very confident,,"I've debugged around region 2 to understand the bizzare logic, then I got conclusion that excluded_file_name function is working incorrectly. I've debugged around it for different cases and found out that in the example provided pattern recognised as plain exclude_hash, even though it should be recognised as exclude_pattern. I've got back to region 1 to understand how command line parameters are translated in internal structures and soon found out the missing flag for --include.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,I've made sure the case of wildcard include pattern works correctly.,Very confident,I've tested it around.,,"No, there will never be a tool that can fix this error reliably.",,
grep.58195fab,8/8/2016 23:28:06,MGFkYmExOT,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,grep.c:2139,exclude.c:449,grep.c:2118,,,"Forgotten EXCLUDE_WILDCARDS at grep.c:2139. After calling add_exclude exclude.c:449 without EXCLUDE_WILDCARDS it treats ""*.e"" as a filename, not as a pattern. So it behaves like --include is omitted.",Very confident,,"Find word 'exclude' in sources. noticed add_exclude() function. Looked at it in gdb, noticed that for --include option it does not pass EXCLUDE_WILDCARDS. Read comments in gnulib/lib/exclude.h. Tried quickly fixing the bug by appending necessary flag. Spent another 5 minutes checking everything.",--include option should be *always* treated as wildcard,"Yes, in principle a tool might be able to explain this error.",Looks like simple forgotten bit in function's argument.,Not at all difficult,1 minute or less,Added forgotten flag in function's argument.,Very confident,Spent some looking for any errors caused by this fix. Didn't find any.,,"Yes, in principle a tool might be able to fix this error reliably.",,10 to 20 minutes
grep.58195fab,8/10/2016 17:22:47,MDUyYzIwMz,Not at all familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,grep.c:2137-2139,grep.c:2268,noother.c:0,,,the include pattern is basically the same as the exclude pattern. except that we negate the return value of excluded_file_name. however at grep.c:2139 we say that the include patterns are actually include patterns. but then wildcards are not supported ,Moderately confident,,"1. search for ""include""
2. Find the include patterns.
3. add a lot of logging
4. try to understand exclude.h
",,"No, there will never be a tool that can explain this error.",no because this bug could also be a feature,Slightly difficult,2 - 5 minutes,"The include patterns do not support wildcards. since the include patterns are used in the same way as the exclude patterns, we should support wildcards. ",Very confident,run the test case. seems to be trivial.,,"No, there will never be a tool that can fix this error reliably.",because it could be a feature,5 to 10 minutes
grep.54d55bba,3/18/2016 3:52:18,OWUwOTY1N2,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,lib/savedir.c:51,lib/savedir.c:45-67,lib/savedir.c:45-67,,,"a typo in the variable. at lib/savedir:51 it was intended to remove trailing slashes from the directory name (variable dir), but variable path (possibly not allocated yet) was used instead.",Extremely confident,,"1. reproduce bug with gdb, check backtrace
2. find what function `isdir1` is intended to do
3. check the line that caused a segfault",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,1 minute or less,fix condition to use correct variable name,Extremely confident,a few manual tests,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.54d55bba,3/22/2016 16:12:32,YmI4MGM3ND,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,10 - 20 minutes,src/grep.c:1361,lib/savedir.c:123,lib/savedir.c:51,,,using wrong (uninitialized) variable (path instead of dir),Very confident,,"started grep with test command line, observed segfault",,"Yes, in principle a tool might be able to explain this error.",static code analyzer could be useful for that error,Not at all difficult,5 - 10 minutes,changed path -> dir (as path used here by mistake),Very confident,"started tescase, manually compared output, also run testcase against system grep",,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.54d55bba,3/23/2016 14:21:05,MjYyZjkxNm,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",2 - 5 minutes,src/grep.c:1361-1361,lib/savedir.c:79-163,lib/savedir.c:48-66,,,We are accesing and indexing memory not initialized,Very confident,,"First I run the debugger (taking care to add lib sources to the sources path and see whole code) with the option that crashes showing this:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040e883 in isdir1 (dir=dir@entry=0x7fffffffe661 ""/home/carlos"", file=file@entry=0x635ef3 "".ICEauthority"") at savedir.c:51
51        while (dirlen && path[dirlen - 1] == '/')
(gdb) where
#0  0x000000000040e883 in isdir1 (dir=dir@entry=0x7fffffffe661 ""/home/carlos"", file=file@entry=0x635ef3 "".ICEauthority"") at savedir.c:51
#1  0x000000000040ea1f in savedir (dir=dir@entry=0x7fffffffe661 ""/home/carlos"", name_size=4096, included_patterns=0x0, excluded_patterns=0x0, excluded_directory_patterns=0x629fe0) at savedir.c:123
#2  0x0000000000405001 in grepdir (dir=0x7fffffffe661 ""/home/carlos"", stats=0x628660 <stats_base>) at grep.c:1361
#3  0x00000000004058a9 in grep (stats=0x628660 <stats_base>, file=0x7fffffffe661 ""/home/carlos"", fd=3) at grep.c:1105
#4  grepfile (file=0x7fffffffe661 ""/home/carlos"", stats=0x628660 <stats_base>) at grep.c:1291
#5  0x000000000040319d in main (argc=<optimized out>, argv=<optimized out>) at grep.c:2300

Then I reviewed the function isdir1() at savedir.c file
Finally I noticed that the path variable was not properly managed there, we were using it before its initialization

",Unitialized variable usage,"Yes, in principle a tool might be able to explain this error.","This type of scenarios can probably detected easier than others, if we can detect somehow unitialized memory",Not at all difficult,5 - 10 minutes,Used the suitable variable to calculate the length and index data,Very confident,"Ensure that now the command works correctly running the failing scenario:

./grep -rl --exclude-dir=foo NEEDLE $HOME
/home/carlos/debugstudy/debugstudy/source_find/find11/find/autom4te.cache/traces.0
/home/carlos/debugstudy/debugstudy/source_find/find11/find/autom4te.cache/output.1
/home/carlos/debugstudy/debugstudy/source_find/find11/find/autom4te.cache/output.0
/home/carlos/debugstudy/debugstudy/source_find/find11/find/autom4te.cache/output.2
/home/carlos/debugstudy/debugstudy/source_find/find11/find/autom4te.cache/traces.2
/home/carlos/debugstudy/debugstudy/source_find/find11/find/configure
/home/carlos/debugstudy/debugstudy/source_find/find11/find/gnulib-git/gnulib/m4/memmem

Compared output with built-it command (grep that comes with Linux).",,"Yes, in principle a tool might be able to fix this error reliably.",I think that this type of errros can be detected with tools if we are able to detect memory not initialized access scenarios,5 to 10 minutes
grep.54d55bba,4/17/2016 1:30:44,ZGU4Yjc1ZG,Slightly familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd",30 - 40 minutes,lib/savedir.c:122-123,lib/savedir.c:51,src/grep.c:1361-1362,,,"For the given combination of arguments, function savedir() is called at src/grep.c:1361-1362. This function then call isdir1() at lib/savedir.c:122-123. There is a variable path global for savedir.c which is supposed to get a value in function isdir1(). However, variable path is used wrong at lib/savedir.c:51 before it has been initialized.",Very confident,,"I used debugger to found the place of segmentation fault. It was in file ../lib/savedir.c and I was first thinking that the error cannot be in this file because it is not directly from the project ""grep"". Then I checked the trace in detail and tried to find how to call savedir() to avoid segmentation fault. I could not find the solution by changing grep.c and thus I decided to repair ../lib/savedir.c.  I looked over the file if there is some function which is supossed to allocate memory for variable path but I could not find any. Finally, I decided that the usage of path at lib/savedir.c:51 is wrong despite that I still do not really understand why variable path is used for.",the error can be outside src/,"Yes, in principle a tool might be able to explain this error.",The usage of uninitialized variable can be reported by the tool.,Slightly difficult,30 - 40 minutes,I have changed the variable used in the condition of while loop.,Very confident,Test cases are working.,,"No, there will never be a tool that can fix this error reliably.","The tool can see, that variable is used uninitialized. But the tool does not know if variable should be initialized before the usage or it should not be used at all.",20 to 30 minutes
grep.54d55bba,4/19/2016 14:12:38,YmExODY3Yj,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, snavigator",20 - 30 minutes,lib/savedir.c:47,lib/savedir.c:51,lib/savedir.c:47,,,null pointer deference,Moderately confident,,"online gdb session, followed by check up the call stack on how the result is used",,"Yes, in principle a tool might be able to explain this error.","might be, it's a crash and the fix is pretty simple",Not at all difficult,5 - 10 minutes,checked the null pointer deference and returned early on error,Moderately confident,ran the test,,"Yes, in principle a tool might be able to fix this error reliably.","again, the null pointer deference has an easy fix usually. however if the context of using the pointer later would not support that fix.. it will complicate things for automatic fixing",less than 5 minutes
grep.54d55bba,4/27/2016 5:35:13,ZWM2ODBmOG,Moderately familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, vim",10 - 20 minutes,grep/lib/savedir.c:51,grep/src/grep.c:1361,grep/lib/savedir.c:112,,,Program invokes savedir() function (grep/src/grep.c:1361). Function savedir() invokes isdir1() (grep/lib/savedir.c:112). Function isdir1() accessing NULL pointer at first time (grep/lib/savedir.c:51) causing segfault. ,Extremely confident,,First I ran program using gdb. Browsing code and inspecting local variables I determined that NULL pointer dereference occurs.,this bug is easy to find already,"Yes, in principle a tool might be able to explain this error.",NULL dereference pointer dereference is quite obvious things.,Not at all difficult,2 - 5 minutes,"This line of code apparently used to remove trailing slash from directory path. path[] variable obviously used instead of dir[] variable by error. Also, it need to change ~/Desktop/grep14/test/test.sh test script by that way. It shows test result incorrectly due grep handles test files not in the same way as printf command printed out.

117 printf ""x/1.e:xaSFasdkl\nx/2.e:xaSFasdkl\n"" | sort > exp
118 $versiondir/src/grep -r --include=""*.e"" xaSFasdkl x | sort > out
",Extremely confident,It works and have no side effects. I did some use case test to be sure.,,"No, there will never be a tool that can fix this error reliably.",Unsure if a tool can guess why it need to remove trailing slash from directory path string.,10 to 20 minutes
grep.54d55bba,4/28/2016 17:03:46,OWMzNDk3N2,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",10 - 20 minutes,savedir.c:51-51,savedir.c:60-60,savedir.c:48-49,,,Wrong comparison in first region.,Moderately confident,,"Debug
Find segmentation fault place in code
See to code
Find wrong condition",,"No, there will never be a tool that can explain this error.",,Slightly difficult,5 - 10 minutes,Fix condition,Moderately confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.54d55bba,5/13/2016 8:16:35,ZjZhNTVkNj,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,20 - 30 minutes,grep/lib/savedir.c:51-52,grep/lib/savedir.c:51-52,grep/lib/savedir.c:51-52,,,"There were 3 errors:

1) Attempting to access the contents of an uninitialized string. In this case the path variable.

2) The == comparison operator needed to negated in second condition of the while loop

3) Braces needed to be placed around the dirlen-- decrement statement to complete the while statement.",Moderately confident,,"1) Executed the application to reproduce the error and generate a core file
2) Loaded the application and core file into gdb
3) Ran the application in gdb until crash
4) Checked the stack to inspect the function in which the crash occurred
5) Set a breakpoint just before the statement that caused the crash
6) Reran the application in gdb and stopped at the breakpoint just before the crash
7) Inspected the function parameters and local & global state variables",,"No, there will never be a tool that can explain this error.",The of the three errors I described above only the first might be identified by a tool such as valgrind. The other two require a tool that understands the semantics of the comparison operation in the while loop. AI is not smart enough to do this yet.,Moderately difficult,10 - 20 minutes,"1) Corrected the string in the while loop comparison from path to dir.
2) Negated the comparison operation which went from == to !=
3) Enclosed the only statement in the while statement in braces.",Very confident,It produced the expected output when inputting with know inputs.,,"No, there will never be a tool that can fix this error reliably.",AI is not sophisticated enough to automatically generate a solution to this problem yet.,10 to 20 minutes
grep.54d55bba,6/12/2016 22:34:26,NTM3Y2E1MW,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,src/grep.c:1360-1362,lib/savedir.c:122-124,lib/savedir.c:50-52,,,path[dirlen - 1] == '/' . This is leading to the segmentation fault. Since path is not pointing to any valid memory location yet when this call is made.,Extremely confident,,"First , I ran the test case. A core was generated. I made use of gdb to understand where it was crashing. I figured out that it was illegal memory access which was causing the error.",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,10 - 20 minutes,I modified the code so that it doesnt make an illegal memory access. I replaced path with dir which should have been the case in the first place.,Extremely confident,Applied the patch. It is not crashing now and generating the required output.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.54d55bba,7/28/2016 19:22:07,MDliMzQ4OT,Not at all familiar,Not at all difficult,Post-Mortem or Offline Debugging (using core dumps and stack traces),gdb,2 - 5 minutes,lib/savedir.c:51,lib/savedir.c:122,src/grep.c:1361,,,The cause of error was using global pointer variable before its initialization.,Very confident,,I've examined core dump and then studied faulty function source.,,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,I've added missing check for global variable being initialized before its use.,Very confident,I've tested it.,,"Yes, in principle a tool might be able to fix this error reliably.","This might be feasible for an automated tool if it is able to detect a ""lazy variable initialization"" pattern.",5 to 10 minutes
grep.54d55bba,7/31/2016 13:54:07,ZmU3ZTExOW,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb where,printf",30 - 40 minutes,src/grep.c:1291,src/grep.c:1105,src/grep.c:1361,lib/savedir.c:123,lib/savedir.c:51,different path name given mistakenly which was not even defined yet. ,Very confident,,"first started with gdb, run command where so it showed stack and where segfault was happened. started through code flow but in src dir everything was fine then found lib dir and found exact place where it was happening and found that pathname was given wrong.",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,correct directory name to follow.,Moderately confident,I have checked that no segfault is coming and output is exactly same as real bug free utility.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.54d55bba,8/10/2016 17:44:37,MDUyYzIwMz,Not at all familiar,Not at all difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,2 - 5 minutes,savedir.c:51,grep.c:1361,noother.c:0,,,Unchecked Null pointer,Extremely confident,,run gdb and bt,,"Yes, in principle a tool might be able to explain this error.",Null pointers are trivial,Slightly difficult,2 - 5 minutes,check for Null before access. If null will execute xrealloc,Extremely confident,run the test case. this seems to be a trivial fix.,,"Yes, in principle a tool might be able to fix this error reliably.",It is a NULL pointer. easy easy easy,5 to 10 minutes
grep.54d55bba,8/15/2016 4:04:49,MGFkYmExOT,Not at all familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,5 - 10 minutes,lib/savedir.c:51,none.c:0,none.c:0,,,Just a typo.,Very confident,,"gdb pointed on lib/savedir.c:51. I noticed that while they finding '/' in `path` they use strlen(dir) as a constraint and `path` is 0. So I thought that it's just a typo. Spent some time checking if I maybe wrong, didn't find anything.",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,2 - 5 minutes,Fixed a typo.,Very confident, ,,"Yes, in principle a tool might be able to fix this error reliably.",,less than 5 minutes
grep.3c3bdace,3/22/2016 7:29:27,OWUwOTY1N2,Not at all familiar,Slightly difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,src/dfa.c:1728,src/dfa.c:1917,src/dfa.c:1685-1918,,,"in dfaanalyze function, buffer allocated for merging position_sets is too short",Moderately confident,,"1. check backtrace of the segfault: it happens in free(merged.elems) call

2. trace merged.elems and watch merged.elems pointer. it is not changed until the end

3. so I supposed that the bug is with internal structure of libc malloc engine which could happen because user code overwrites internal malloc data",,"Yes, in principle a tool might be able to explain this error.",,Not at all difficult,10 - 20 minutes,allocate some more space for merged.elems,Slightly confident,manual tests,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.3c3bdace,3/24/2016 0:30:01,MjYyZjkxNm,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",30 - 40 minutes,src/dfa.c:1689-1923,src/dfa.c:1462-1495,src/dfa.c:1572-1634,,,"The coredump is generated because we are trying to deallocate a region of memory whose size is higher that initial size allocated with malloc(). This normally is due to we are indexing memory out of the initial size.
At region 1 we allocate it and at regions 2 and 3 we index the different positions.
At region 3 we are not indexing it OK, because we do not reset nelem value",Very confident,,"First I run the crashing scenario with debugger to locate the root cause:

#5  0x000000000040b062 in dfaanalyze (d=d@entry=0x6188a0 <dfa>, searchflag=searchflag@entry=1) at dfa.c:1917
#6  0x000000000040d586 in dfacomp (s=s@entry=0x619fe0 ""(^| )*( |$)"", len=6400144, len@entry=11, d=d@entry=0x6188a0 <dfa>, searchflag=searchflag@entry=1) at dfa.c:3000
#7  0x0000000000405647 in GEAcompile (pattern=0x619fe0 ""(^| )*( |$)"", size=11, syntax_bits=2145052) at search.c:271
#8  0x000000000040288d in main (argc=<optimized out>, argv=<optimized out>) at grep.c:2251

Then I determine that the problem is managing the merged.elems memory.
Then I put some traces to debug how it is managed along the sections 2 and 3 (functions epsclosure() and merge())
Finally I detected that the point of failure was at epsclosure() function",It is OK with current information from my point of view,"No, there will never be a tool that can explain this error.","It is complicated to create a tool that detects this type of errors, I had to trace completely a couple of functions to find it :-)",Very difficult,30 - 40 minutes,We were not initializing the nelem value and old value was kept. This way the insert() functions inserts new items out of bounds. I just did the value initialization t 0.,Very confident,"Repeated failing scenarios, run test case and compare output with built-in grep command to ensure that results are OK now",,"Yes, in principle a tool might be able to fix this error reliably.","If we are able to detect that we are using memory out of bounds, it could be possible to fix for a tool to fix it",10 to 20 minutes
grep.3c3bdace,3/25/2016 5:51:28,YmI4MGM3ND,Slightly familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb, eclipse",40 - 50 minutes,src/search.c:271,src/dfa.c:3002-3005,src/dfa.c:1917,,,"if case ""*"" (star) in pattern, ""free"" call crashes the app with SIGSEGV/SIGABRT. 
couldn't find why this happened",Not at all confident,I don't have enough knowledge on how  DFA stuff implemented here and not enough time to trace it step-by-step,"run under gdb, found crash site (""free"" call at end of ""dfanalyze""), traced dfanalyze and functions called from dfanalyze",,"Yes, in principle a tool might be able to explain this error.",tool like valgrind cold probably help here as well,Extremely difficult,40 - 50 minutes,N/A,Not at all confident,N/A,"not familiar with DFA stuff used in grep, too few time.","No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.3c3bdace,4/21/2016 5:08:18,ZGU4Yjc1ZG,Not at all familiar,Extremely difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, ddd, valgrind",60 minutes or more,src/dfa.c:1885-1889,src/dfa.c:1419-1427,src/dfa.c:1591,src/dfa.c:1621-1625,,"At src/dfa.c:1885-1889, structure ""d->follows[i]"" is copied to temporal structure ""merged"", then epsclosure() is called for this temporal structure and then its content is copied back to d->follows[i]. I found 2 problems inside this operations. First, ""d->follows[i]"" may need more memory as currently reserved for ""merged"" and because function copy() does not serve this, see src/dfa.c:1419-1427, the program should extend memory block used for ""merged"" when necessary. But, then the second problem arises. Function epsclosure() may delete and insert elements and it may insert more elements as it deletes, see src/dfa.c:1591 and src/dfa.c:1624. Thus, if this problem is not already considered during the previous extension of memory block for ""merged"" it has to be addressed at least before src/dfa.c:1621-1625.",Very confident,,"First, I trace the program to the segmentation fault. The error was in free() and first I checked if there is some easy explanation, e.g. a forgoten or mailformed malloc(). I could not find anything like this and then I used valgrind to detect the location of memory corruption. The first error was reported in function insert(). I have checked that part of code in details and I found out that it tries to write more elements as there are reserved memory (I do not know how to check this with a tool and thus I spent some time to discover this manually). Then I change memory allocation of ""merged"" with a quite large initial number and test passes. This confirms the location of the bug but I still had to find out optimal values and optimal locations for needed realloc(). And to be honest, between this successful steps I spent a lot of time by doing unsuccessful steps, e.g. I tried to understand the algorithm implemented in dfaanalyze(), especially I traced the program many times because I was thinking that the error is a result of wrong logic which does not preserve the requested ordering of elements.",merged is used only for temporary results and not only once,"Yes, in principle a tool might be able to explain this error.",The tool could start with the result from valgrind and gives a  backtrace to the point where is the last memory (re)allocation for the problematic variable and it could also showed the size of the reserved memory block and explained why it is to short.,Moderately difficult,20 - 30 minutes,I have extended memory block reserved for temporary structure in those situation when the current memory block is to small.,Very confident,"Test cases pases. Also, for the given test cases valgrind does not find any problem with the repaired program.",,"No, there will never be a tool that can fix this error reliably.","I do not know if it is possible to observe and fix this error using static analysis of the program. Probably not. Thus, the tool can only add calls to memory reallocations to the points detected by running given test cases. But this does not guarantee that also other test cases will pass.",30 to 40 minutes
grep.3c3bdace,4/26/2016 10:11:18,ZWM2ODBmOG,Moderately familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, valgrind, vim",60 minutes or more,grep/src/dfa.c:1728,grep/src/dfa.c:1453,grep/src/dfa.c:1494,grep/src/dfa.c:1455,grep/src/dfa.c:11917,"Memory allocated for merged.elems array (grep/src/dfa.c:1728) but number of elements inserted to it can grow twice to array size allocated (grep/src/dfa.c:1455). Memory corruption caused by accessing elements out of array boundary (grep/src/dfa.c:1453), (grep/src/dfa.c:1494) leads to segfault when memory frees (grep/src/dfa.c:11917).",Extremely confident,,"First I used valgrind to determine memory allocation problems. Next, I determined variable responsible for such big array indices. Using hardware watch for assigning this variable value I determined place where its value grows so big. Browsing source code I determined that memory requirements for this array is fair enough and it can grow twice than allocated.",not sure if there can be a tool to help in this case,"Yes, in principle a tool might be able to explain this error.",A tool can be explain this case by tracing back memory allocation errors. Although I am not sure if a tool can sort out if the memory corruption caused by either real array size insufficient or incorrectly calculated index.,Not at all difficult,2 - 5 minutes,I allocated twice more memory for a dynamic array.,Very confident,It is simple and obvious. Although there still be probability that there are algorithm implementation errors. ,,"No, there will never be a tool that can fix this error reliably.",Unsure if a tool can sort out if array have to be expanded or array index calculated wrong. Maybe a tool can try various approaches and using use case tests it check if approach is working but it can take a lot of time and can be bothered by another bugs.,10 to 20 minutes
grep.3c3bdace,4/28/2016 5:01:33,OWMzNDk3N2,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf(), valgrind",60 minutes or more,dfa.c:1917-1917,dfa.c:1452-1455,dfa.c:1728-1728,,,"In 3 region memory allocated for merged.elems, but in 2 block this memory did not enough and we get memory corruption.",Very confident,,"Debug, find region 1
Use valgrind to determine where memory allocated and stack trace to wrong memory writing
",,"Yes, in principle a tool might be able to explain this error.",Valgrind do like something this,Very difficult,5 - 10 minutes,I encrease memory allocated for merged.elems,Slightly confident,"Tests finished successfully.
But this fix of bug is very temporary solution, because we could get input data, and this memory would not be enough, again. To fix this bug correctly we must add filed to position_set struct, that contains number of allocated elements, and if we would need more elements we could realloc buffer.",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.3c3bdace,6/13/2016 2:30:32,NTM3Y2E1MW,Not at all familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb), Post-Mortem or Offline Debugging (using core dumps and stack traces)",gdb,40 - 50 minutes,src/dfa.c:1727-1729,src/dfa.c:1910-1917,src/dfa.c:2999-3000,,,"I think that there is some kind of a heap overflow happening here
MALLOC(merged.elems, position,   d->nleaves);

dfaanalyze() inserts more positions than the number of d->nleaves for expressions like the one given in the test
",Very confident,,"GDB is very handy when there is a coredump. I analyzed why there was a seg fault. 
I understood that there was a memory overwrite and hence there was a need to allocate more space.",,"Yes, in principle a tool might be able to explain this error.",,Slightly difficult,5 - 10 minutes,"I allocated more space in the malloc function i.e 
MALLOC(merged.elems, position,  2 * d->nleaves);
allocated positions 2 times the number of leaves so that there is no heap overflow.",Extremely confident,Applied the patch. Tested the code. Works as expected.,,"Yes, in principle a tool might be able to fix this error reliably.",,5 to 10 minutes
grep.3c3bdace,7/30/2016 18:13:52,MjYyYzZkN2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Post-Mortem or Offline Debugging (using core dumps and stack traces)","gdb,valgrind",60 minutes or more,src/dfa.c:1728,src/dfa.c:1453,src/dfa.c:1494,,,"The array allocated at region 1 was not large enough to endure all further manipulations (e.g. insert in region 2), so there was a heap corruption.",Slightly confident,,I've examined coredump and realised that heap corruption takes place (because in the coredump program was failing to malloc 48 bytes). Then I've run program under valgrind and examined suspicios places it pointed out. Then I've tried to enlarge array buffer being overwritten and that helped: program stopped crashing.,,"Yes, in principle a tool might be able to explain this error.",I can easily imagine automated tool better than valgrind: its output is barely readable.,Not at all difficult,1 minute or less,I've made sure no heap corruption occurs by enlarging buffer size twice.,Not at all confident,"Well, at least it does not segfault, so that's good enough for me.",,"Yes, in principle a tool might be able to fix this error reliably.",,more than 40 minutes
grep.3c3bdace,7/31/2016 22:38:04,ZmU3ZTExOW,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb where, printf",40 - 50 minutes,src/dfa.c:1908,src/dfa.c:157,src/search.c:271,src/dfa.c:1624,,index was not passed properly. And wrong use of function at the place where it shouldn't be called.,Not at all confident,,first tried with gdb where and gdb bt to find exact places and found that 0 index is creating problem so changed that and in other place function is calling outside as well so it should be called at that place because I think arguments are not ready at that point.,,"No, there will never be a tool that can explain this error.",,Very difficult,20 - 30 minutes,corrected index value and preventing function calling at unnecessary places.,Not at all confident,by running provided test script and matching behaviour with original bug free utility.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.3c3bdace,8/10/2016 19:51:40,MDUyYzIwMz,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,30 - 40 minutes,dfa.c:1460-1478,dfa.c:1436-1454,noother.c:0,,,the nelem field is wrong leading to oob,Moderately confident,,"gdb
then lots of logging 
took a while until I thought about git log",,"No, there will never be a tool that can explain this error.",Not really sure. actually I m not even sure about the root cause. as a fix I just rolled back,Very difficult,10 - 20 minutes,"rollback dfa.c to prev commit.
actually I tied to fix the new code, but was unable to do so in the time permitted. lost a bit of time during initial bug finding.",Very confident,rollback and works. test cases run. thus it is as good as the prev commit.,,"Yes, in principle a tool might be able to fix this error reliably.","not sure about the root cause due to time constraints. just rolled back. Assuming you have a test case, should be easy to do for a piece of software as well",5 to 10 minutes
grep.3c3bdace,8/12/2016 22:31:51,MGFkYmExOT,Not at all familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, addresssanitizer",30 - 40 minutes,src/dfa.c:1453,src/dfa.c:1624,src/dfa.c:1886,src/dfa.c:1728,,"AddressSanitizer gave me the line in the insert() function src/dfa.c:1453 that causes the heap overflow, which, I suppose, leads to the bad free() and segfault later.
Comment on this insert() function states that s->elems must point to an array large enough to hold the resulting set. So, let's check the caller - epsclosure() at src/dfa.c:1624. Again the comment states that s->elems must be large enough. This function called from dfaanalyze() at src/dfa.c:1886, and that s->elems is actually ours merged.elems, which causes the segfault later.
It looks like merged.elems is malloc'ed once at the beginning of dfaanalyze() at src/dfa.c:1728.
I do not quite sure how it's size ends up being not enough for this particular case, but the easiest workaround would be just allocating some bigger buffer for merged.elems. I do not have enough time to dig into dfa code, so I decide to stick to this explanation/workaround.",Slightly confident,,"Compiled with addressanitizer, backtraced to the dfaanalyze() function.",,"Yes, in principle a tool might be able to explain this error.",Maybe partially. Like my explanation. It would be hard to understand the real cause of a bug.,Slightly difficult,5 - 10 minutes,Increased the buffer to eliminate the heap overflow.,Not at all confident, ,,"No, there will never be a tool that can fix this error reliably.","Maybe it can enlarge buffer just like me according to it's explanation, but it's totally unreliable.",10 to 20 minutes
grep.2be0c659,3/21/2016 7:03:30,OWUwOTY1N2,Very familiar,Not at all difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,src/grep.c:1060-1062,src/search.c:382-396,src/search.c:388,,,"with -i mode, grep lowers the source string to match it over lowered pattern. The character 'I with dot' lowered takes 1 byte less in UTF-8 (1 byte vs 2 bytes), but no function in the sources is aware of this possiblity.",Very confident,,"1. with gdb, trace into do_execute -> EGexecute functions to see when the source buffer data changes.

2. Turned out that the buffer is not changed, but replaced with another buffer with the lowered text.

3. Tracing 'EGexecute' function inputs and output, I've found that returned size is 1 less than the size of the source string.

4. tracing EGexecute again, I've found that mbtolower() function returns string 1 byte shorter than its input.",,"No, there will never be a tool that can explain this error.",,Not at all difficult,2 - 5 minutes,force to return the source line length as a matched size.,Moderately confident,manual tests,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.2be0c659,3/22/2016 15:25:30,MjYyZjkxNm,Not at all familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, editplus(editor)",10 - 20 minutes,src/grep.c:1829-2284,src/grep.c:1258-1375,src/grep.c:1127-1255,src/grep.c:891-936,src/search.c:355-564,"When we convert chars to lower case to do -i option the length is modified and we continue using the original length of the UTF-8 input text, this way we obtain longer output strings and buffers with rubbish that causes the issue",Slightly confident,,"First I took my time to study completely the code (newbye at these sources)
Then I debugged with gdb the buffers size at each step and the addresses at each point noticing that when converting to lower case the size is reduced by the pointer keeps pointing to the latest char of the original string.",Lowercase conversion changes size,"No, there will never be a tool that can explain this error.","At all, very difficult for a tool to detect this issue and determine the root cause.",Very difficult,40 - 50 minutes,"Wrong pointer was used when calculating buffer size after case management, longer size was taken than expected",Slightly confident,"Repeated test cases and failure scenarios described at first part when reporting the bug, compared output with built-in grep command",,"No, there will never be a tool that can fix this error reliably.","It is a pointer issue, I think that is unable to detect for tools.",10 to 20 minutes
grep.2be0c659,3/24/2016 18:33:32,YmI4MGM3ND,Slightly familiar,Moderately difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, eclipse",10 - 20 minutes,src/grep.c:1081,src/grep.c:1060,src/search.c:384-398,,,"do_execute implementation returns match_size after source string lowercased, and in case wide char string it less than original string",Slightly confident,,"1. traced the code to figure out where ""match_icase"" flag (set to 1 if ""-i"" passed) analyzed during program run;
2. found that in search.c:384-398 ""match_size"" variable overwritten with value for lowercased string
3. figured out that ptrtext function in ""grepbuf"" prints string which end pointer calculated with ""match_size"" value, which could be  wrong for original string (calculated by lowercased string)",,"No, there will never be a tool that can explain this error.",,Moderately difficult,10 - 20 minutes,returning size of original string in case any matches found,Slightly confident,"This is not a good fix but quirk/workaround, but at least test passed.",,"No, there will never be a tool that can fix this error reliably.",,10 to 20 minutes
grep.2be0c659,4/20/2016 4:57:13,ZGU4Yjc1ZG,Extremely familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,10 - 20 minutes,src/grep.c:1081,src/search.c:626,src/search.c:86-140,,,"Function grepbuf() calls function do_execute() until the complete buffer is checked, src/grep.c:1081. In the case of UTF-8 and -i,  function do_execute() returns wrong size of the matched text. It reports number of bytes after the transformation to lowercase, see src/search.c:626 and src/search.c:86-140, but the reported number could be different as the number of bytes of the original text. When necessary, this should be adapted after the call of function do_execute()  and this is missing.",Very confident,,"I have immediatelly recognized that the error is very similar to the one I already solved before. Then I tried to get a trace for the given test case. Unfortunatelly, ddd is not working correctly for LC_ALL=tr_TR.utf8 :-( Because tracing without GUI is not pleasant, I gave up and skiped this step by simply trying out the same solution which worked for the similar problem before. All test cases passes and thus I am quite sure, that the problem was the same.",how to use ddd with LC_ALL=tr_TR.utf8,"No, there will never be a tool that can explain this error.",The tool cannot know what is the coorect behaviour.,Not at all difficult,2 - 5 minutes,I have adapted the value of the variable which denotes the end of matched line which was wrong if multibyte character is used for which the lengh in bytes is different for lowercase and uppercase variant.,Moderately confident,Test cases passed. I have reported low times and very low difficulty because I simply used the solution from one old example.,,"No, there will never be a tool that can fix this error reliably.",The tool does not know what is the correct behaviour.,20 to 30 minutes
grep.2be0c659,4/26/2016 5:29:11,ZWM2ODBmOG,Moderately familiar,Slightly difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, grep, vim",30 - 40 minutes,grep/src/search.c:384-392,grep/src/search.c:555-557,grep/src/grep.c:1085,grep/src/grep.c:926,,"For case insensitive search, input text case has to be lowered (grep/src/search.c:384-392). After lowering case, 8-bit characters are converted to unicode multibyte characters. After finding a match, function returns length of match (grep/src/search.c:555-557) but it corresponding to lowercase multibyte string, not original string. This value used to calculate end point of buffer to print out (grep/src/grep.c:1085). So result string printed out having wrong size, usually larger than ough to be (grep/src/grep.c:926). ",Extremely confident,,"I used gdb to run program and caught write() syscall. Looking at its arguments, I see that size of string is larger than number of characters in output buffer.",High level data diagram may be helpful,"Yes, in principle a tool might be able to explain this error.","Maybe a tool can catch buffer bounds exceeding state on printing out and trace down how the buffer size variable did assigned. I am not sure in this case. For C language, we need to look at amount of data actually placed into the buffer, not allocated memory size. ",Very difficult,50 - 60 minutes,I changed size of match found to actual input line length.,Slightly confident,"I did some use case tests, it works. Due this change affects very basis of program execution, I am not fully sure that this will cause problems in other cases.",,"No, there will never be a tool that can fix this error reliably.",I do not know how a tool can calculate buffer size which a human may want to see.,10 to 20 minutes
grep.2be0c659,4/28/2016 20:40:29,OWMzNDk3N2,Slightly familiar,Very difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb, printf()",60 minutes or more,search.c:382-396,search.c:112-112,search.c:131-131,,,"When UTF char converting to lower case its size may change, but this is not handle in code.
I found that code in 2 and 3 regions can get different sizes of chars, then I apply this knowledge to region 1.",Slightly confident,,"Debug, step by step
Found region #2 and #3
Got that sizes of chars are different
Found function that call mbtolower() function
Read it
Try to add new variable for size for lower string.
Run and found that it fixes the bug.",,"No, there will never be a tool that can explain this error.",,Very difficult,5 - 10 minutes,Add new variable for size of new string in lower case.,Slightly confident,Tests finished successfully,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.2be0c659,7/31/2016 18:20:56,ZmU3ZTExOW,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)","gdb,prints",20 - 30 minutes,src/grep.c:2004,src/search.c:87-140,src/search.c:180,,,only few cases were taken care of. It may possible that other case come so proper use of if condition was not done.,Moderately confident,,traverse through code using print and found code that actually should handle case coming case but it was handled in else case instead of that it should go in if case so corrected it.,,"No, there will never be a tool that can explain this error.",,Slightly difficult,10 - 20 minutes,handled more possible cases.,Moderately confident,by running provided test script.,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.2be0c659,8/10/2016 21:55:58,MGFkYmExOT,Not at all familiar,Very difficult,"Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,50 - 60 minutes,search.c:388,search.c:112,search.c:131,,,"mbtolower() returns length of the ""lower-cased"" string here search.c:388. But lowercase character sometimes occupy more bytes than original (search.c:112 and search.c:131).",Moderately confident,Already spent almost 60 minutes on it,"Traced in gdb almost from the beginning, tracking down where buffer is expanded to 15 bytes.",,"No, there will never be a tool that can explain this error.",,Very difficult,1 minute or less,"nothing.

I assume that that incorrect length of lowercase string is used somewhere to calculate the number of bytes to write to stdout. But I do not know how to reliably fix this bug. Maybe the caller of mbtolower() must recompute the length of the actual string and act accordingly. Maybe some workaround needed in mbtolower() (like returning both lengths original and lowercased), but then you need to properly fix all calls to it. I am not sure that I can do it in reasonable time, so I just give up.",Not at all confident, ,,"No, there will never be a tool that can fix this error reliably.",,5 to 10 minutes
grep.2be0c659,8/11/2016 15:51:34,MDUyYzIwMz,Moderately familiar,Moderately difficult,"Trace-based Debugging (using printing; e.g., println, log4c), Interactive or Online Debugging (using breakpoints; e.g., gdb, jdb)",gdb,20 - 30 minutes,search.c:387-393,grep.c:1081-1114,nother.c:0,,,"After changing the string to lower case, the string is shorter. Thus the returned match_size is wrong because it uses the match len of the lower case string.",Moderately confident,,"1. Use gdb to verify bt
2. Add some logging to understand different variables at search.c:391
3. Realize that the size changes.
4. Get stuck and obsess about the fact that mbtolower replaces the \n with an \0
5. Realize that the size change is the vital clue
6. Play around and track difference in size.
7. Realize that the match_size at search.c:560 has to be changed.",That the repalcement of \n with \0 does not matter,"Yes, in principle a tool might be able to explain this error.",We calculate a offset using one string and then use it on a different string. That smells.,Moderately difficult,10 - 20 minutes,Track the difference in size and add it to the match_size,Moderately confident,Run test case.,,"No, there will never be a tool that can fix this error reliably.",I believe while detecting might be possible fixing needs understanding of the code.,10 to 20 minutes