xfstest: generic/001 fails on pmemfile with SIGABRT
mramotowski opened this issue · comments
Running xftests generic/001 test on pmemfile ends with SIGABRT
#0 syscall_no_intercept () at util.s:76
#1 0x00007fc36574e22b in intercept_routine (nr=14, arg0=2, arg1=140734151356512, arg2=0, arg3=8, arg4=0, arg5=140734151356512, syscall_offset=219005, libpath=0x7fc36685bef8 "/lib/x86_64-linux-gnu/libc.so.6", r
eturn_to_asm_wrapper_syscall=140477199842918, return_to_asm_wrapper=140477199842909, clone_wrapper=0x7fc365987f05 <asm_wrapper_space+113653>, rsp_in_asm_wrapper=140734151355360) at /home/mramotow/repos/syscall_
intercept/src/intercept.c:588
#2 0x00007fc36575863d in backtrace_placeholder_2 () at intercept_template.s:294
#3 0x00007fc365aa277f in __libc_signal_restore_set (set=0x7fff39197060) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#5 0x00007fc365aa437a in __GI_abort () at abort.c:89
#6 0x00007fc364a3cebb in out_fatal (file=0x7fc364a750fb "lane.c", line=108, func=0x7fc364a753d0 <__func__.5984> "lane_info_ht_boot", fmt=0x7fc364a75102 "!os_tls_set") at ../../src/../src/common/out.c:564
#7 0x00007fc364a53596 in lane_info_ht_boot () at lane.c:108
#8 0x00007fc364a54123 in get_lane_info_record (pop=0x7fc325a00000) at lane.c:400
#9 0x00007fc364a54401 in lane_hold (pop=0x7fc325a00000, section=0x7fff391974e8, type=LANE_SECTION_ALLOCATOR) at lane.c:453
#10 0x00007fc364a63a63 in pmalloc_redo_hold (pop=0x7fc325a00000) at pmalloc.c:72
#11 0x00007fc364a63f90 in pfree (pop=0x7fc325a00000, off=0x7fc325a02b48) at pmalloc.c:208
#12 0x00007fc364a6a3d7 in tx_free_vec_entry (pop=0x7fc325a00000, entry=0x7fc325a02b48) at tx.c:311
#13 0x00007fc364a653bf in pvector_pop_back (ctx=0x5557b3948270, cb=0x7fc364a6a3b4 <tx_free_vec_entry>) at pvector.c:287
#14 0x00007fc364a6a615 in tx_clear_undo_log (pop=0x7fc325a00000, undo=0x5557b3948270, flags=(TX_CLR_FLAG_FREE | TX_CLR_FLAG_VG_CLEAN)) at tx.c:363
#15 0x00007fc364a6b49d in tx_abort_set (pop=0x7fc325a00000, tx_rt=0x7fff391978d0, recovery=1) at tx.c:649
#16 0x00007fc364a6bdbc in tx_abort (pop=0x7fc325a00000, lane=0x0, layout=0x7fc325a02800, recovery=1) at tx.c:873
#17 0x00007fc364a6fe5e in lane_transaction_recovery (pop=0x7fc325a00000, data=0x7fc325a02800, length=1024) at tx.c:2189
#18 0x00007fc364a53d9a in lane_recover_and_section_boot (pop=0x7fc325a00000) at lane.c:304
#19 0x00007fc364a5c65c in obj_boot (pop=0x7fc325a00000) at obj.c:733
#20 0x00007fc364a5d9e7 in obj_runtime_init (pop=0x7fc325a00000, rdonly=0, boot=1, nlanes=1024) at obj.c:1100
#21 0x00007fc364a5ee10 in obj_open_common (path=0x7fc3663204c8 <pools+8200> "/dev/dax1.0", layout=0x7fc36513bb62 "pmemfile", cow=0, boot=1) at obj.c:1629
#22 0x00007fc364a5ef2e in pmemobj_openU (path=0x7fc3663204c8 <pools+8200> "/dev/dax1.0", layout=0x7fc36513bb62 "pmemfile") at obj.c:1665
#23 0x00007fc364a5ef53 in pmemobj_open (path=0x7fc3663204c8 <pools+8200> "/dev/dax1.0", layout=0x7fc36513bb62 "pmemfile") at obj.c:1675
#24 0x00007fc365136dbd in pmemfile_pool_resume (pfp=0x5557b38a06a0, pathname=pathname@entry=0x7fc3663204c8 <pools+8200> "/dev/dax1.0") at /home/mramotow/repos/pmemfile/src/libpmemfile-posix/pool.c:343
#25 0x00007fc366056444 in pool_acquire (pool=0x7fc36631e4c0 <pools>) at /home/mramotow/repos/pmemfile/src/libpmemfile/preload.c:152
#26 0x00007fc36605a290 in hook (syscall_return_value=0x7fff39197db0, arg5=140477204731912, arg4=0, arg3=140477206942288, arg2=1, arg1=93835162904208, arg0=11, syscall_number=1) at /home/mramotow/repos/pmemfile/
src/libpmemfile/preload.c:2232
#27 hook_reentrance_guard_wrapper (syscall_number=1, arg0=11, arg1=93835162904208, arg2=1, arg3=140477206942288, arg4=0, arg5=140477204731912, syscall_return_value=0x7fff39197db0) at /home/mramotow/repos/pmemfi
le/src/libpmemfile/preload.c:2285
#28 0x00007fc36574e18b in intercept_routine (nr=1, arg0=11, arg1=93835162904208, arg2=1, arg3=140477206942288, arg4=0, arg5=140477204731912, syscall_offset=1018094, libpath=0x7fc36685bef8 "/lib/x86_64-linux-gnu
/libc.so.6", return_to_asm_wrapper_syscall=140477199920468, return_to_asm_wrapper=140477199920459, clone_wrapper=0x7fc36599adf3 <asm_wrapper_space+191203>, rsp_in_asm_wrapper=140734151360224) at /home/mramotow/
repos/syscall_intercept/src/intercept.c:564
#29 0x00007fc36575863d in backtrace_placeholder_2 () at intercept_template.s:294
#30 0x00007fc365b658f0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:84
#31 0x00007fc365ae78e7 in _IO_new_file_write (f=0x5557b399db20, data=0x5557b38d6690, n=1) at fileops.c:1271
#32 0x00007fc365ae9432 in new_do_write (to_do=1, data=0x5557b38d6690 "\n", fp=0x5557b399db20) at fileops.c:526
#33 _IO_new_do_write (fp=0x5557b399db20, data=0x5557b38d6690 "\n", to_do=1) at fileops.c:502
#34 0x00007fc365aeb6ec in _IO_flush_all_lockp (do_lock=do_lock@entry=0) at genops.c:792
#35 0x00007fc365aeb8b5 in _IO_cleanup () at genops.c:957
#36 0x00007fc365aa7213 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:96
#37 0x00007fc365aa72ca in __GI_exit (status=<optimized out>) at exit.c:105
#38 0x00005557b2d3ca7c in main (argc=<optimized out>, argv=0x7fff39198678) at fill.c:90
Probably someone called abort();, which calls a syscall to raise an abort signal.
Is it reproducible, or happened only once?
Could you try it with this branch of syscall_intercept:
https://github.com/gbuella/syscall_intercept/tree/again_refactor_intercept_template
The hope, this branch allows for more reliable stack unwinding, so we can so more of the backtrace.
Fix merged. Please verify.