On 16 August 2016 at 03:12, Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 08/13/2016 04:26 AM, Sitsofe Wheeler wrote: >> >> With fio-2.12-3-g8a09 I've seen the occasional segfault while running >> a job like this: >> >> ./fio --allow_file_create=0 --randseed=1 --rw=randread --direct=1 >> --iodepth=16 --ioengine=libaio --bs=64k --time_based=1 --runtime=12h >> --random_distribution=zipf:0.8 --name=go --filename /dev/sde >> >> Here's a backtrace: >> Thread 1 (Thread 0x7f8518911740 (LWP 4078)): >> #0 fio_libaio_getevents (td=0x7f850076fa80, min=15, max=15, >> t=<optimized out>) at engines/libaio.c:161 >> #1 0x000000000041a493 in td_io_getevents (td=td@entry=0x7f850076fa80, >> min=15, max=<optimized out>, t=0x0) at ioengines.c:241 [...] > > Huh, weird. Is this a new regression? I don't think it's new. I've seen this with Fedora's older fio-2.6-1.fc24.x86_64 RPM: Stack trace of thread 8294: #0 0x000000000046b458 fio_libaio_getevents (fio) #1 0x000000000041b9a3 td_io_getevents (fio) #2 0x0000000000440509 io_u_queued_complete (fio) #3 0x000000000040cec4 cleanup_pending_aio (fio) #4 0x000000000045f658 thread_main (fio) #5 0x00000000004609ce run_threads (fio) #6 0x0000000000460e4d fio_backend (fio) #7 0x000000000040ddea main (fio) #8 0x00007fa7f1013731 __libc_start_main (libc.so.6) #9 0x000000000040de39 _start (fio) I don't think it happens in the normal course of operation but only when a device mapper device is somehow removed while fio is still using it? So far I've been unable to identify the steps that lead up to it. -- Sitsofe | http://sucs.org/~sits/ -- 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
