I am not yet convinced that the problem has anything to do with miscompiled code. I am using exactly the same optimizations and exactly the same compiler as the official FreeBSD builds.
On 22/06/2016 17:03, Igor Kozhukhov wrote: > Hi Andri, > > i have DilOS with gcc-4.8,5 (+ special patches) for illumos builds. > i had some problems with zdb - found it by zfs tests. > > problem has been fixed by disable of optimization : > -fno-aggressive-loop-optimizations > > also, i have added: > -fno-ipa-sra > > but i no remember a story why i have added it ;) > probabbly it was added with another illumos component and new gcc-4.8 > > As you know, illumos still is using gcc-4.4.4 and some newer compilers > can produce new issues with older code :) > > I think, you can try to play with your clang optimization flags too. > i have no experience with clang. > > best regards, > -Igor > > >> On Jun 22, 2016, at 4:21 PM, Andriy Gapon <a...@freebsd.org >> <mailto:a...@freebsd.org>> wrote: >> >> >> I am getting the following panic using the latest FreeBSD head that is >> synchronized with OpenZFS code as of >> illumos/illumos-gate@26455f9efcf9b1e44937d4d86d1ce37b006f25a9. >> >> panic: solaris assert: ba.ba_phys->bt_bytes == 0 (0x400 == 0x0), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bptree.c, >> line: 292 >> cpuid = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe004db9d310 >> vpanic() at vpanic+0x182/frame 0xfffffe004db9d390 >> panic() at panic+0x43/frame 0xfffffe004db9d3f0 >> assfail3() at assfail3+0x2c/frame 0xfffffe004db9d410 >> bptree_iterate() at bptree_iterate+0x35e/frame 0xfffffe004db9d540 >> dsl_scan_sync() at dsl_scan_sync+0x24f/frame 0xfffffe004db9d890 >> spa_sync() at spa_sync+0x897/frame 0xfffffe004db9dad0 >> txg_sync_thread() at txg_sync_thread+0x383/frame 0xfffffe004db9dbb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe004db9dbf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe004db9dbf0 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> >> I have a crash dump, but unfortunately it's hard to work with it, >> because a lot of useful information got "optimized out" by clang. >> >> I can reproduce the panic using a synthetic workload, but I do not have >> a concise reproduction scenario. Every time the panic happens bt_bytes >> is 0x400, I haven't seen any other number there. >> >> Does anyone have an idea what could be causing this? >> I can try any diagnostic code that might shed more light. >> Thank you! >> >> -- >> Andriy Gapon >> >> >> http://www.listbox.com > > *openzfs-developer* | Archives > <https://www.listbox.com/member/archive/274414/=now> > <https://www.listbox.com/member/archive/rss/274414/28133750-22ed9730> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription [Powered by Listbox] <http://www.listbox.com> > -- Andriy Gapon ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
