Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

[tg@gmplib.org (Torbjörn Granlund)]

Aurelien Jarno <aurelien@aurel32.net> writes:

  On Fri, Oct 17, 2014 at 08:57:38PM +0200, Torbjörn Granlund wrote:
  > Aurelien Jarno <aurelien@aurel32.net> writes:
  >   
  >   I am using 2.1.2 under GNU/Linux.
  >   
  > Ah, so you're not trying to reproduce the problem!
  
  I do. Well you talked about 2.1.0, the latest stable one is 2.1.2. Now
  if you prefer, we can conclude the problem is solved in 2.1.2.
  
  > Are you passing the -cpu 5Kc argument?
  
  I used:
  
  qemu-system-mips64 -M malta -cpu 5Kc -m 256 \
      -drive file=disk.img,if=virtio,index=0 \
      -net nic,macaddr=52:54:00:13:06:64 -net user,hostfwd=tcp::20008-:22 \
      -kernel boot/vmlinux-3.2.0-4-5kc-malta \
      -initrd boot/initrd.img-3.2.0-4-5kc-malta \
      -append "root=/dev/vda1 console=ttyS0" \
      -nographic -serial null -monitor null
  
  And it's still running the testsuite in a loop.
  
  >   I don't think it's irrelevant, that's why I asked. If you don't provide
  >   this information, we won't be able to check which code paths are
  >   involved
  >   
  >   Given you are the only one to reproduce the issue, please provide a
  >   backtrace of a crash so that we can proceed further.
  > 
  > Really?  Has anybody tried to reproduce the issue?
  
  At least me, and it doesn't crash here.
  
  > My bug report contains all information for trivially reproducing the
  > issue.  I kept the setup around for a long time, but now I have cleaned
  
  Yes, but it doesn't mean it's reproducible.
  
  > it up.  I am very busy in this period and cannot afford to set it up
  > again, also considering that the effort on the developer part seems very
  > very limited wrt reported problems.  (I am not complaining, I have no
  > opinion on how volunteer hackers use their time!)
  
  Ok fine, let's consider the issue fixed. 

You won't like me saying this, but this is not how professional software
development is done.  It is also discouraging to see a detailed bug
report being treated in such a dismissive manner.

Here is an alternative approach:

1. Is the bug report complete?  If not, ask for more information (or
   perhaps chose to ignore it if you conclude it is bogus).

2. Try to reproduce the problem using the information in the bug report.
   This means that you set up an environment as close as possible in all
   relevant aspects.  Clearly, do not use a different version of the
   software being investigated.

3. Isolate the bug and fix it.  As the reporter for feedback.

4. Make some effort in finding similar bugs in the the software package.

It is not safe to conclude that when a different version of the software
seems to work, then the bug is gone.  Why?  There might be some mistake
in reproducing the bug.  There might be a relevant environment
discrepancy.  You might even be running the wrong binary by mistake, or
use the wrong data file by mistake.  (I have been in the game a long
time now, and I have made all these mistakes at some point.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622