This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange, elusive bug in boolean return values with latest fetch from cvs


> Simplest for us would be if you made a small self-contained program
> which we could run which prints a clearly incorrect result.

I had to mess with it for a while, but I got a small test case to exhibit
the problem.  I compiled BugJune3.java using the attached mkbj3 script,
producing the executable BugJune3.dynamic.  Running it, I get:
    bug.seeIfItsTrue returned false
    bug.seeIfItsTrue returned false
It should be:
    bug.seeIfItsTrue returned false
    bug.seeIfItsTrue returned true
If you compile straight from the java source, it's fine (the problem occurs
when compiling to a native binary from class files).  If you interpret it
(either with Sun or gcj), it's fine.  If you change the optimization level
from -O2 to -O0, it always returns true instead of always returning false.

Before I got the test case to work, I did some disassembly to investigate
the problem.  Details follow...

Here is the functional version of the code (i.e. it works as expected, even
when compiled to a native binary):
public final boolean isSelected ()
{
  boolean returnValue = false;
  if (buttonGroup != null)
    returnValue = buttonGroup.isSelected (this);
  return returnValue;
}

Here is the version that always returns zero, but only when compiled into my
huge application (works fine interpreted).
public final boolean isSelected ()
{
   return (buttonGroup==null) ? false : buttonGroup.isSelected (this);
}

I have attached some exerpts from disassemblies.  The ones starting with
"yesbug" are from the first version of the source code, and the ones with
"nobug" are from the other one.  I compiled the source code with Sun's
javac, then compiled a big jar file containing those classes with gcj.  I
then disassembled the class files with javap, and the gcj-generated object
file with objdump.  I exerpted the isSelected code and put it in the
attached text files.

The javap-disassembled classes both look right to me.  They ought to, since
both work fine when compiled with the old gcj or interpreted (even with the
newest gcc code, when interpreted).  The problem is in the
objump-disassembled code.  I didn't analyze them too closely, but I think
there's an obvious error in yesbug_isSelected.disasm.txt.  At 2d99, eax is
cleared (xor %eax,%eax), even if a call was made to ButtonGroup.isSelected.
That obliterates the return value.  The other version doesn't do that, so it
keeps the return value from ButtonGroup.isSelected.

So it appears to be a code generation problem, present only when compiling
class files.  Any ideas?

Attachment: yesBug_isSelected_javap.txt
Description: Text document

Attachment: noBug_isSelected_javap.txt
Description: Text document

Attachment: yesbug_isSelected.disasm.txt
Description: Text document

Attachment: nobug_isSelected.disasm.txt
Description: Text document

Attachment: BugJune3.class
Description: Binary data

Attachment: BugJune3$LittleThing.class
Description: Binary data

Attachment: BugJune3.java
Description: Binary data

Attachment: mkbj3.dat
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]