Java segfault in predict.c

Java segfault in predict.c

[Bryce McKinlay]

Hi,

The following Java code (extracted from xerces) results in a segfault 
with the current mainline in estimate_probability at -O. This seems to 
be a recent regression, certainly it does not fail with GCC 3.1. You 
should be able to reproduce it with "gcj -c -O Crash.java"

regards

Bryce.


public class Crash
{
  public void checkXMLLangAttributeValue(String lang)
  {
      int offset = -1;
      if (lang.length() >= 2) {
          char ch0 = lang.charAt(0);
      }
      if (offset > 0) {
          char ch = lang.charAt(offset++);
          if (ch != '-') {
              offset = -1;
          } else {
              while (true)
          {
                if (ch == '-')
                  ch = lang.charAt(offset++);
                ch = lang.charAt(offset++);
              }
          }
      }
  }
}

Program received signal SIGSEGV, Segmentation fault.
0x082bbcf4 in estimate_probability (loops_info=0xbffff5f0)
    at ../../gcc/predict.c:431
431             if (TEST_BIT (loop->nodes, bb->index))
(gdb) bt
#0  0x082bbcf4 in estimate_probability (loops_info=0xbffff5f0)
    at ../../gcc/predict.c:431
#1  0x0832e893 in rest_of_compilation (decl=0x4019dee0)
    at ../../gcc/toplev.c:2952
#2  0x08071921 in source_end_java_method () at ../../gcc/java/parse.y:7474
#3  0x080746cf in java_expand_method_bodies (class=0x4019dc40)
    at ../../gcc/java/parse.y:8152
#4  0x08079553 in java_expand_classes () at ../../gcc/java/parse.y:9083
#5  0x080ec7dc in java_parse_file (set_yydebug=0)
    at ../../gcc/java/jcf-parse.c:1155
#6  0x0832c88d in compile_file () at ../../gcc/toplev.c:2089
#7  0x0833277f in do_compile () at ../../gcc/toplev.c:5188
#8  0x083327e3 in toplev_main (argc=13, argv=0xbffff914)
    at ../../gcc/toplev.c:5220
#9  0x0810649b in main (argc=-2, argv=0xfffffffe) at ../../gcc/main.c:35
#10 0x4003e647 in __libc_start_main (main=0x8106480 <main>, argc=13,
    ubp_av=0xbffff914, init=0x80492d4 <_init>, fini=0x8443300 <_fini>,
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff90c)
    at ../sysdeps/generic/libc-start.c:129

Re: Java segfault in predict.c

[Zdenek Dvorak]

Hello.

> The following Java code (extracted from xerces) results in a segfault 
> with the current mainline in estimate_probability at -O. This seems to 
> be a recent regression, certainly it does not fail with GCC 3.1. You 
> should be able to reproduce it with "gcj -c -O Crash.java"

This fixes the bug.

Zdenek Dvorak

Changelog:
	* cfgloop.c (flow_loops_find): Correctly initialize loop->first and
	loop->last.

Index: cfgloop.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cfgloop.c,v
retrieving revision 1.12
diff -c -3 -p -r1.12 cfgloop.c
*** cfgloop.c	28 May 2002 20:44:09 -0000	1.12
--- cfgloop.c	29 May 2002 08:32:50 -0000
*************** flow_loops_find (loops, flags)
*** 644,650 ****
    sbitmap *dom;
    int *dfs_order;
    int *rc_order;
!   basic_block header;
  
    /* This function cannot be repeatedly called with different
       flags to build up the loop information.  The loop tree
--- 644,650 ----
    sbitmap *dom;
    int *dfs_order;
    int *rc_order;
!   basic_block header, bb;
  
    /* This function cannot be repeatedly called with different
       flags to build up the loop information.  The loop tree
*************** flow_loops_find (loops, flags)
*** 768,777 ****
  	     These are often the same as the loop header and
  	     loop latch respectively, but this is not always
  	     the case.  */
! 	  loop->first
! 	    = BASIC_BLOCK (sbitmap_first_set_bit (loop->nodes));
! 	  loop->last
! 	    = BASIC_BLOCK (sbitmap_last_set_bit (loop->nodes));
  
  	  flow_loop_scan (loops, loop, flags);
  	}
--- 768,782 ----
  	     These are often the same as the loop header and
  	     loop latch respectively, but this is not always
  	     the case.  */
! 
! 	  FOR_BB_BETWEEN (bb, BASIC_BLOCK (sbitmap_first_set_bit (loop->nodes)),
! 		ENTRY_BLOCK_PTR, prev_bb)
! 	    if (TEST_BIT (loop->nodes, bb->index))
! 	      loop->first = bb;
! 	  FOR_BB_BETWEEN (bb, BASIC_BLOCK (sbitmap_last_set_bit (loop->nodes)),
! 		EXIT_BLOCK_PTR, next_bb)
! 	    if (TEST_BIT (loop->nodes, bb->index))
! 	      loop->last = bb;
  
  	  flow_loop_scan (loops, loop, flags);
  	}

Re: Java segfault in predict.c

[Geoff Keating]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> public class Crash
> {
>   public void checkXMLLangAttributeValue(String lang)
>   {
>       int offset = -1;
>       if (lang.length() >= 2) {
>           char ch0 = lang.charAt(0);
>       }
>       if (offset > 0) {
>           char ch = lang.charAt(offset++);
>           if (ch != '-') {
>               offset = -1;
>           } else {
>               while (true)
>           {
>                 if (ch == '-')
>                   ch = lang.charAt(offset++);
>                 ch = lang.charAt(offset++);
>               }
>           }
>       }
>   }
> }

Can you add this as a testcase?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Java segfault in predict.c

[Richard Henderson]

On Wed, May 29, 2002 at 10:54:38AM +0200, Zdenek Dvorak wrote:
> ! 	  FOR_BB_BETWEEN (bb, BASIC_BLOCK (sbitmap_first_set_bit (loop->nodes)),
> ! 		ENTRY_BLOCK_PTR, prev_bb)
> ! 	    if (TEST_BIT (loop->nodes, bb->index))
> ! 	      loop->first = bb;
> ! 	  FOR_BB_BETWEEN (bb, BASIC_BLOCK (sbitmap_last_set_bit (loop->nodes)),
> ! 		EXIT_BLOCK_PTR, next_bb)
> ! 	    if (TEST_BIT (loop->nodes, bb->index))
> ! 	      loop->last = bb;

Seems like

	FOR_ALL_BB (bb)
	  if (TEST_BIT (loop->nodes, bb->index))
	    break;
	loop->first = bb;

	FOR_ALL_BB_REVERSE (bb)
	  if (TEST_BIT (loop->nodes, bb->index))
	    break;
	loop->last = bb;

actually searches fewer blocks, and is clearer.

Again, this seems like a real opportunity to want to rely on
monotonicly increasing indicies...



r~

Re: Java segfault in predict.c

[Zdenek Dvorak]

Hello.

> > ! 	  FOR_BB_BETWEEN (bb, BASIC_BLOCK (sbitmap_first_set_bit (loop->nodes)),
> > ! 		ENTRY_BLOCK_PTR, prev_bb)
> > ! 	    if (TEST_BIT (loop->nodes, bb->index))
> > ! 	      loop->first = bb;
> > ! 	  FOR_BB_BETWEEN (bb, BASIC_BLOCK (sbitmap_last_set_bit (loop->nodes)),
> > ! 		EXIT_BLOCK_PTR, next_bb)
> > ! 	    if (TEST_BIT (loop->nodes, bb->index))
> > ! 	      loop->last = bb;
> 
> Seems like
> 
> 	FOR_ALL_BB (bb)
> 	  if (TEST_BIT (loop->nodes, bb->index))
> 	    break;
> 	loop->first = bb;
> 
> 	FOR_ALL_BB_REVERSE (bb)
> 	  if (TEST_BIT (loop->nodes, bb->index))
> 	    break;
> 	loop->last = bb;
> 
> actually searches fewer blocks, and is clearer.

OK.

> Again, this seems like a real opportunity to want to rely on
> monotonicly increasing indicies...

Why?

Zdenek

Re: Java segfault in predict.c

[Richard Henderson]

On Wed, May 29, 2002 at 09:29:07PM +0200, Zdenek Dvorak wrote:
> > Again, this seems like a real opportunity to want to rely on
> > monotonicly increasing indicies...
> 
> Why?

So that we don't have to search for the start, obviously. 
It'll be the lowest numbered block.


r~

Re: Java segfault in predict.c

[Zdenek Dvorak]

Hello.

> > > Again, this seems like a real opportunity to want to rely on
> > > monotonicly increasing indicies...
> > 
> > Why?
> 
> So that we don't have to search for the start, obviously. 
> It'll be the lowest numbered block.

Even sbitmap_first_set_bit searches whole bitmap from start; I agree it
is significantly faster then searching the chain. But this is invoked
once per each loop found and I would be very surprised if it was
performance critical.

But what is more interesting: first and last fields are not used for
anything meaningful anywhere (for dumping info about loops in cfgloop
and loop.h; the only place where it plays any role is in predict.c to
make iterating over loop in estimate_probability faster -- and it will
be removed once (if?) we merge the loop changes from cfgbranch.

Zdenek

Re: Java segfault in predict.c

[Zdenek Dvorak]

Hello.

> > > Again, this seems like a real opportunity to want to rely on
> > > monotonicly increasing indicies...
> > 
> > Why?
> 
> So that we don't have to search for the start, obviously. 
> It'll be the lowest numbered block.

But if you want this, it should be sufficient to put compact_blocks
to the begining of flow_loops_find (the loop discovery code does not
change basic blocks).

Zdenek

Re: Java segfault in predict.c

[Richard Henderson]

On Wed, May 29, 2002 at 10:06:01PM +0200, Zdenek Dvorak wrote:
> But what is more interesting: first and last fields are not used for
> anything meaningful anywhere (for dumping info about loops in cfgloop
> and loop.h; the only place where it plays any role is in predict.c to
> make iterating over loop in estimate_probability faster -- and it will
> be removed once (if?) we merge the loop changes from cfgbranch.

Now that _is_ interesting.  In which case, leave the search
loop for now, and we'll see if we can get rid of them entirely.
I hope to get to the patches Jan has posted soon...


r~

Re: Java segfault in predict.c

[Bryce McKinlay]

Geoff Keating wrote:

>>public class Crash
>>{
>>  public void checkXMLLangAttributeValue(String lang)
>>  {
>>      int offset = -1;
>>      if (lang.length() >= 2) {
>>          char ch0 = lang.charAt(0);
>>      }
>>      if (offset > 0) {
>>          char ch = lang.charAt(offset++);
>>          if (ch != '-') {
>>              offset = -1;
>>          } else {
>>              while (true)
>>          {
>>                if (ch == '-')
>>                  ch = lang.charAt(offset++);
>>                ch = lang.charAt(offset++);
>>              }
>>          }
>>      }
>>  }
>>}
>>    
>>
>
>Can you add this as a testcase?
>

I added it as libjava.compile/T20020529.java

regards

Bryce.

Re: Java segfault in predict.c

[Zdenek Dvorak]

Hello.

> Seems like
> 
> 	FOR_ALL_BB (bb)
> 	  if (TEST_BIT (loop->nodes, bb->index))
> 	    break;
> 	loop->first = bb;
> 
> 	FOR_ALL_BB_REVERSE (bb)
> 	  if (TEST_BIT (loop->nodes, bb->index))
> 	    break;
> 	loop->last = bb;
> 
> actually searches fewer blocks, and is clearer.

I'm committing this for now.

> Again, this seems like a real opportunity to want to rely on
> monotonicly increasing indicies...

Zdenek