search

YosysHQ / yosys

Yosys Open SYnthesis Suite
https://yosyshq.net/yosys/
ISC License
3.37k stars 874 forks source link

Double free on exit when design is saved (pyosys+gcc LTO only) #4535

Open ACharlyR opened 1 month ago

ACharlyR commented 1 month ago

Version

Yosys 0.44 (git sha1 80ba43d26, g++ 14.2.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto -fPIC -O3

On which OS did this happen?

Linux

Reproduction Steps

Git clone https://aur.archlinux.org/packages/yosys-git

Build and test

makepkg -s

The test also segfaults with the latest commit on main:

Yosys 0.44+9 (git sha1 4b9f45273, g++ 14.2.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto -fPIC -O3)

I only run in to this issue on arch:

uname -r
6.10.4-arch2-1

There are no issues when following the same steps on another PCs running manjaro 5.10 and manjaro 6.6.

Expected Behavior

No segfaults

Actual Behavior

yosys/tests/techmap/run-test.sh segfaults. I have attached some debug infromation:

GDB traceback of coredump

``` $ gdb /tmp/yosys/src/yosys/yosys core.yosys.1005.56a485c5546940dd905acc28937a15c1.190234.1723536931000000 GNU gdb (GDB) 15.1 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /tmp/yosys/src/yosys/yosys... [New LWP 190234] This GDB supports auto-downloading debuginfo from the following URLs: Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Downloading separate debug info for /usr/lib/libpython3.12.so.1.0 Downloading separate debug info for /usr/lib/libm.so.6 Downloading separate debug info for /usr/lib/libboost_python312.so.1.83.0 Downloading separate debug info for /usr/lib/libboost_system.so.1.83.0 Downloading separate debug info for /usr/lib/libboost_filesystem.so.1.83.0 Downloading separate debug info for /usr/lib/libreadline.so.8 Downloading separate debug info for /usr/lib/libffi.so.8 Downloading separate debug info for /usr/lib/libz.so.1 Downloading separate debug info for /usr/lib/libc.so.6 Downloading separate debug info for /lib64/ld-linux-x86-64.so.2 Downloading separate debug info for /usr/lib/libboost_atomic.so.1.83.0 Downloading separate debug info for /usr/lib/libncursesw.so.6 Downloading separate debug info for system-supplied DSO at 0x799866583000 [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `/tmp/yosys/src/yosys/yosys -ql abc9.log -e select out of bounds abc9.ys'. Program terminated with signal SIGSEGV, Segmentation fault. Downloading source file /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc #0 std::local_Rb_tree_rotate_left (__x=0x59ae53a5fd80, __root=@0x59ae1c8055d0: 0x59ae539f59e0) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc:145 warning: 145 /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc: No such file or directory (gdb) up #1 std::_Rb_tree_rebalance_for_erase (__z=__z@entry=0x59ae5399ea60, __header=...) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc:400 400 in /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++98/tree.cc (gdb) #2 0x000059ae1b9e613b in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase_aux (this=, __position=...) at /usr/include/c++/14.2.1/bits/stl_tree.h:2485 2485 _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>:: (gdb) #3 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase_aux (this=, __first={...}, __last={...}) at /usr/include/c++/14.2.1/bits/stl_tree.h:2506 2506 _M_erase_aux(__first++); (gdb) #4 std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::erase (__x=@0x59ae5399ea28: 1675043264, this=) at /usr/include/c++/14.2.1/bits/stl_tree.h:2517 2517 _M_erase_aux(__p.first, __p.second); (gdb) #5 std::map, std::allocator > >::erase ( this=, __x=@0x59ae5399ea28: 1675043264) at /usr/include/c++/14.2.1/bits/stl_map.h:1118 1118 { return _M_t.erase(__x); } (gdb) #6 Yosys::RTLIL::Wire::~Wire (this=, this=) at kernel/rtlil.cc:3453 3453 RTLIL::Wire::get_all_wires()->erase(hashidx_); (gdb) up #7 0x000059ae1b9cb7e7 in Yosys::RTLIL::Module::~Module (this=, this=) at kernel/rtlil.cc:939 939 delete pr.second; (gdb) #8 0x000059ae1bb3c038 in Yosys::AST::AstModule::~AstModule (this=, this=) at frontends/ast/ast.cc:1461 1461 } (gdb) #9 Yosys::AST::AstModule::~AstModule (this=, this=) at frontends/ast/ast.cc:1461 1461 } (gdb) #10 0x000059ae1b9c6dc4 in Yosys::RTLIL::Design::~Design (this=, this=) at kernel/rtlil.cc:638 638 delete pr.second; (gdb) #11 0x000059ae1bbd44c2 in Yosys::DesignPass::~DesignPass (this=, this=) at passes/cmds/design.cc:33 33 delete it.second; (gdb) Downloading source file /usr/src/debug/glibc/glibc/stdlib/exit.c #12 0x000079986569d891 in __run_exit_handlers (status=0, listp=0x799865845680 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 108 cxafct (arg, status); (gdb) #13 0x000079986569d95e in __GI_exit (status=) at exit.c:138 138 __run_exit_handlers (status, &__exit_funcs, true, true); (gdb) Downloading source file /usr/src/debug/glibc/glibc/csu/../sysdeps/nptl/libc_start_call_main.h #14 0x0000799865683e0f in __libc_start_call_main (main=main@entry=0x59ae1b824480 , argc=argc@entry=6, argv=argv@entry=0x7ffca7f79418) at ../sysdeps/nptl/libc_start_call_main.h:74 74 exit (result); ```

ldd

``` ldd /tmp/yosys/src/yosys/yosys linux-vdso.so.1 (0x00007a274b6df000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007a274a000000) libpython3.12.so.1.0 => /usr/lib/libpython3.12.so.1.0 (0x00007a2749800000) libm.so.6 => /usr/lib/libm.so.6 (0x00007a2749f11000) libboost_python312.so.1.83.0 => /usr/lib/libboost_python312.so.1.83.0 (0x00007a274a318000) libboost_system.so.1.83.0 => /usr/lib/libboost_system.so.1.83.0 (0x00007a274a313000) libboost_filesystem.so.1.83.0 => /usr/lib/libboost_filesystem.so.1.83.0 (0x00007a274a2ef000) libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007a274a297000) libffi.so.8 => /usr/lib/libffi.so.8 (0x00007a274a28c000) libz.so.1 => /usr/lib/libz.so.1 (0x00007a2749ef8000) libtcl8.6.so => /usr/lib/libtcl8.6.so (0x00007a274964f000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007a2749eca000) libc.so.6 => /usr/lib/libc.so.6 (0x00007a274945e000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007a274b6e1000) libboost_atomic.so.1.83.0 => /usr/lib/libboost_atomic.so.1.83.0 (0x00007a2749ec0000) libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007a2749e51000) ```

povik commented 1 month ago

no issues when following the same steps on another PCs running manjaro 5.10 and manjaro 6.6.

I take it those are Arch versions.

The crash is strange, we are crashing within the map erase call inside the Wire destructor. This is related to the Python binding, so disabling that may avoid the crash, but still, it's not clear to me how we could be misusing the std::map container to cause the crash.

ACharlyR commented 1 month ago

no issues when following the same steps on another PCs running manjaro 5.10 and manjaro 6.6.

I take it those are Arch versions.

These are Linux kernel versions, I forgot to specify that.

widlarizer commented 2 weeks ago

Successfully reproduced in archlinux docker on up to date nixos. Hard to get debuginfod to work in docker though so I'll try on my manjaro laptop.

yosys -V: Yosys 0.44+60 (git sha1 0fc5812dc, g++ 14.2.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/root/yosys-git/src=/usr/src/debug/yosys-git -flto=auto -fPIC -O3)

uname -a: Linux 111c80ac5f1c 6.6.47 #1-NixOS SMP PREEMPT_DYNAMIC Mon Aug 19 04:04:32 UTC 2024 x86_64 GNU/Linux

widlarizer commented 2 weeks ago

Manjaro laptop is a bit out of date and didn't reproduce.

yosys -V: Yosys 0.44+60 (git sha1 0fc5812dc, g++ 14.1.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -fPIC -O3)

uname -a: Linux emil-xps15 6.8.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 21:35:54 +0000 x86_64 GNU/Linux

widlarizer commented 2 weeks ago

To reproduce, it's sufficient to build with gcc, LTO, PYOSYS, and then run yosys -p "design -save orig"

widlarizer commented 2 weeks ago

I can't put more time into this, but the core issue is that DesignPass and all_designs get destroyed in the "wrong" order. It seems resolving it isn't very easy, register.cc may have to be involved, as well as misc/py_wrap_generator.py. For AUR maintainers, I don't have a better solution than disable pyosys. Disabling tests would allow yosys to be used though it would still double free and crash at exit in cases where designs are saved