John,

Yes, there is indeed a memory corruption problem but extremelly hard to track 
down. GCC issues an ICE, through a tree_check macro, which then tried to print 
a string and fails due to a garbage collection read of 1 byte uninitialized in 
a strlen attempt. This is two bugs in one. First it shouldn't ICE and then once 
it ICEs it shouldn't segfault.

Paulo Matos


> -----Original Message-----
> From: John Regehr [mailto:reg...@cs.utah.edu]
> Sent: 03 October 2013 22:24
> To: Paulo Matos; creduce-dev@flux.utah.edu
> Subject: Re: [creduce-dev] Increase of size during reduction process
> 
> Paulo, it seems to me that if none of the line-based passes can remove
> anything from a 750 KB test case, there is something weird going on.
> 
> My rough guess is that there is a memory corruption problem in the compiler
> and the ICE is a secondary effect of a very coincidental set of
> circumstances.  It is possible that C-Reduce simply cannot help you very
> much here.
> 
> So how about this: rather than doing this reduction, just run the compiler
> using valgrind (using the --follow-children=yes option of course) and see
> if there any any smoking guns.
> 
> John
> 
> 
> 
> On 10/03/2013 07:35 AM, Paulo Matos wrote:
> > Hi,
> >
> > Just to let you guys know of the following: After getting c-reduce git
> HEAD, and running it on the same example I see pass_lines 0 reducing one byte
> at a time starting from ~751000 bytes. Since this would take the rest of my
> life to reduce I decided to remove pass_lines 0 from creduce.in and make
> install as per John's suggestion. Now I see:
> >
> > pmatos@poseidon:~/tmp/builds/creduce-build/creduce$ ./creduce
> > ./min.sh  PsdInfo_6cpe.i
> > ===< 10766 >===
> > running 4 interestingness test(s) in parallel
> > ===< pass_blank :: 0 >===
> > ===< pass_clang_binsrch :: replace-function-def-with-decl >===
> > ===< pass_clang_binsrch :: remove-unused-function >===
> > (0.0 %, 751215 bytes)
> > (0.1 %, 750836 bytes)
> > ===< pass_lines :: 1 >===
> > (-1.7 %, 764127 bytes)
> > ===< pass_lines :: 1 >===
> > (-3.5 %, 777418 bytes)
> > ===< pass_lines :: 1 >===
> > (-5.2 %, 790709 bytes)
> > ===< pass_lines :: 2 >===
> > (-7.0 %, 804073 bytes)
> > ===< pass_lines :: 2 >===
> > (-8.8 %, 817437 bytes)
> > ===< pass_lines :: 2 >===
> > (-10.6 %, 830801 bytes)
> >
> > Will try to remove all pass lines and see what happens.
> >
> > Paulo Matos
> >
> >
> >> -----Original Message-----
> >> From: creduce-dev-boun...@flux.utah.edu [mailto:creduce-dev-
> >> boun...@flux.utah.edu] On Behalf Of John Regehr
> >> Sent: 02 October 2013 15:09
> >> To: creduce-dev@flux.utah.edu
> >> Subject: Re: [creduce-dev] Increase of size during reduction process
> >>
> >> Hi Paulo,
> >>
> >> This is odd behavior, I haven't seen it happen where a temporary size
> >> increase keeps going.
> >>
> >> You can easily disable individual passes that aren't being helpful: just
> >> modify creduce.in and then "make install" again.
> >>
> >> C-Reduce is deterministic so it doesn't take any kind of seed.
> >>
> >> John
> >>
> >>
> >> On 10/02/2013 08:02 AM, Paulo Matos wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: Eitan Adler [mailto:li...@eitanadler.com]
> >>>> Sent: 02 October 2013 14:55
> >>>> To: Paulo Matos
> >>>> Cc: creduce-dev@flux.utah.edu
> >>>> Subject: Re: [creduce-dev] Increase of size during reduction process
> >>>>
> >>>> On Wed, Oct 2, 2013 at 5:41 AM, Paulo Matos <pma...@broadcom.com> wrote:
> >>>>> Hi,
> >>>>
> >>>>> Shouldn't size increase be dismissed?
> >>>>
> >>>> It is possible to get into local minimums which are not global minimums.
> >>>>
> >>>>
> >>>
> >>> This testcase I am trying is driving me nuts.
> >>> It's currently at
> >>> (-3.3 %, 473260 bytes)
> >>>
> >>> Each time a pass_blank starts it increases the size more than it
> decreases
> >> during its process, therefore even though the testcase started with
> >>> ===< pass_blank :: 0 >===
> >>> (0.0 %, 458340 bytes)
> >>> it is now way larger.
> >>>
> >>> Is there a way to set a seed to creduce, so that I can try to avoid those
> >> local minimums?
> >>> Maybe if I can set a seed, I can set up multiple parallel creduce and
> grab
> >> the one that generates the smallest example.
> >>>
> >>> Paulo Matos
> >>>
> >


Reply via email to