Thanks. :) Oh yeah... i did not see i gave a wrong max bs. typo ... oops... sometimes doing something wrong wakes up some issues :) I tried the provided patch and it worked well. I also tried with the right max bs and it all works well now. Thanks for the great support. On Sat, Apr 25, 2015 at 12:39 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 04/24/2015 10:20 AM, Jens Axboe wrote: >> >> On 04/17/2015 03:13 AM, Srinivasa Chamarthy wrote: >>> >>> Received the following crash reports: >>> >>> fio: pid=2847, got signal=6 >>> Jobs: 3 (f=101), CR=1200MB/0B KB/s: [K(1),W(1),K(1),W(2),K(1)] [80.1% >>> done] [0KB/118.1MB/0KB /s] [0/1814/0 iopJobs: 3 (f=97), CR=1200MB/0B >>> KB/s: [K(1),W(1),K(1),W(2),K(1)] [80.2% done] [0KB/40312KB/0KB /s] >>> [0/583/0 iops]*** Error in `fio': >>> double free or corruption (!prev): 0x000000000114d7b0 *** >>> ======= Backtrace: ========= >>> /lib64/libc.so.6(+0x730bf)[0x7fcf25c7e0bf] >>> /lib64/libc.so.6(+0x7892e)[0x7fcf25c8392e] >>> /lib64/libc.so.6(+0x79636)[0x7fcf25c84636] >>> fio(free_io_mem+0x97)[0x42c3e7] >>> fio[0x44dc73] >>> fio[0x450fd9] >>> fio(fio_backend+0xfb)[0x45144b] >>> /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fcf25c2cb05] >>> fio[0x40d3ec] >>> >>> # fio -v >>> fio-2.2.7-9-g4da2 >> >> >> I can't reproduce this. Could you try a make clean and make again? >> Sometimes fio's build system screws up when you pull in changes, some of >> the dependencies are apparently whacked. > > > Actually, I think I see what it is. It's because your max bs isn't a > multiple of the min bs, and fio has a bug in where it rounds up the > blocksize as a multiple of the min bs. So we end up rounding up to 128K, > where the max should be 124K. This causes us to overwrite allocated memory, > and madness ensues. Can you test this patch? > > -- > Jens Axboe > -- Srinivasa R Chamarthy -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
