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

[Aurelien Jarno <aurelien@aurel32.net>]

On Wed, Oct 22, 2014 at 10:31:45PM +0200, Torbjörn Granlund wrote:
> 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:

Ok, let's do it.

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

You refused to provide the information I asked.

> 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.

I later tried to reproduce it with version 2.1.0. I arrived to the same
conclusion that the bug is not reproducible.

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

The bug is not reproducible, so that's not something possible.

> 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.)

In that case, please provide:
- The QEMU binary you have built.
- The image to reproduce the issue.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net