-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Output strerror from xo_warn #14
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rysto32
pushed a commit
to rysto32/freebsd
that referenced
this pull request
Dec 26, 2014
Released on October 23rd, 2014. * Restored the atf(7) manual page to serve as a reference to all the other manual pages shipped by ATF. * Added the -s flag to atf-sh to support specifying the shell interpreter to be used. * Removed ATF_WORKDIR. The only remaining consumers have been converted to use the standard TMPDIR environment variable. As a benefit, and because Kyua forces the TMPDIR to live within the test case's work directory, any stale files left behind by ATF will be automatically cleaned up. * Documented the environment variables recognized by each component in the relevant manual pages. This information was lost with the atf-config(1) removal. * Added a new "require.diskspace" metadata property to test cases so that they can specify the minimum amount of disk space required for the test to run. * Renamed the atf-{c,c++,sh}-api(3) manual pages to atf-{c,c++,sh}(3) for discoverability purposes. Symbolic links are provided for the time being to still make the old names visible. * Issue freebsd#5: Recommend the (expected, actual) idiom for calls to the test macros in the manual pages. * Issue freebsd#7: Stopped catching unhandled exceptions in atf-c++ tests. This propagates the crash to the caller, which in turn allows it to obtain proper debugging information. In particular, Kyua should now be able to extract a stacktrace pinpointing the problem. * Issue freebsd#8: Fixed atf-c/macros_test:use test failures spotted by the clang that ships with FreeBSD 11.0-CURRENT. * Issue freebsd#12: Improved documentation of atf-sh(3) and atf-check(1) by better explaining how they relate to each other. * Issue freebsd#14: Stopped setting 'set -e' in atf-sh. This setting was initially added as a way to enable a "strict" mode in the library and to make test cases fail fast when they run unprotected commands. However, doing so in the library is surprising as the responsibility of enabling 'set -e' should be on the user's code. Also, 'set -e' introduces inconsistent behavior on subshells and users do not expect that. * Issue freebsd#15: Fixed atf_utils_{fork,wait} to support nested calls. * Issue freebsd#16: Fixed test failures (by removing a long-standing hack) on systems that lack \e support in printf(1). * Issue freebsd#19: Removed stale references to atf-config and atf-run.
The upstream repo is at https://github.com/juniper/libxo |
ghost
referenced
this pull request
in NextBSD/NextBSD
Sep 11, 2015
(kgdb) bt #0 doadump (textdump=0) at pcpu.h:219 #1 0xffffffff803575be in db_dump (dummy=<value optimized out>, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff8035709d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80356e14 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80359920 in db_trap (type=<value optimized out>, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a0ffb1 in kdb_trap (type=12, code=0, tf=<value optimized out>) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80e27b3c in trap_fatal (frame=0xfffffe085d6724a0, eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0xffffffff80e27ecc in trap_pfault (frame=0xfffffe085d6724a0, usermode=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:677 #8 0xffffffff80e274ee in trap (frame=0xfffffe085d6724a0) at /usr/src/sys/amd64/amd64/trap.c:426 #9 0xffffffff80e097b2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:235 #10 0xffffffff809b4af1 in __mtx_lock_sleep (c=0xffffffff817c9930, tid=18446735278713196544, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:429 #11 0xffffffff80c88812 in swap_reserve_by_cred (incr=20480, cred=<value optimized out>) at /usr/src/sys/vm/swap_pager.c:209 #12 0xffffffff80c9e64b in vm_map_insert (map=0xfffff80041d27a28, object=0xfffff801f55cf000, offset=339968, start=42813591552, end=42813612032, prot=3 '\003', cow=10) at /usr/src/sys/vm/vm_map.c:1200 #13 0xffffffff80c9f435 in vm_map_fixed (map=<value optimized out>, object=<value optimized out>, offset=<value optimized out>, start=<value optimized out>, length=<value optimized out>, prot=<value optimized out>, max=<value optimized out>, cow=<value optimized out>) at /usr/src/sys/vm/vm_map.c:1424 #14 0xffffffff80ca4b0e in vm_mmap (map=0xfffff80041d27a28, addr=0xfffffe085d672948, size=20480, prot=0 '\0', maxprot=7 '\a', flags=262162, handle_type=<value optimized out>, handle=<value optimized out>, foff=339968) at /usr/src/sys/vm/vm_mmap.c:1678 #15 0xffffffff80ca3ecc in sys_mmap (td=0xfffff800415dd000, uap=<value optimized out>) at /usr/src/sys/vm/vm_mmap.c:456 #16 0xffffffff80e285dd in amd64_syscall (td=0xfffff800415dd000, traced=0) at subr_syscall.c:133 #17 0xffffffff80e09a9b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 Frame 15, sys/vm/vm_mmap.c:456 is the line right after our pax_aslr_mmap call. ` uname -a` is: FreeBSD hbsd-dev-local 11.0-CURRENT FreeBSD 11.0-CURRENT #9 27a2fa4(hardened/current/master)-dirty: Fri Dec 19 11:10:01 EST 2014 shawn@hbsd-dev-local:/usr/obj/usr/src/sys/LATT-SEC amd64 Reported-by: Shawn Signed-off-by: Oliver Pinter <[email protected]> (cherry picked from commit a520a38) HBSD: fix typo, the stop should be end Signed-off-by: Oliver Pinter <[email protected]> (cherry picked from commit 183e42f)
uqs
pushed a commit
that referenced
this pull request
Oct 26, 2015
The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 #1 0xffffffff80606762 at vpanic+0x182 #2 0xffffffff806067e3 at panic+0x43 #3 0xffffffff8084eef1 at trap_fatal+0x351 #4 0xffffffff8084f0e4 at trap_pfault+0x1e4 #5 0xffffffff8084e82f at trap+0x4bf #6 0xffffffff80830d57 at calltrap+0x8 #7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb #8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 #9 0xffffffff8042dcad at ata_dmaload+0x11d #10 0xffffffff8042df7e at ata_begin_transaction+0x7e #11 0xffffffff8042c18e at ataaction+0x9ce #12 0xffffffff802a220f at xpt_run_devq+0x5bf #13 0xffffffff802a17ad at xpt_action_default+0x94d #14 0xffffffff802c0024 at adastart+0x8b4 #15 0xffffffff802a2e93 at xpt_run_allocq+0x193 #16 0xffffffff802c0735 at adastrategy+0xf5 #17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s git-svn-id: svn+ssh://svn.freebsd.org/base/head@290005 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Oct 26, 2015
The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 #1 0xffffffff80606762 at vpanic+0x182 #2 0xffffffff806067e3 at panic+0x43 #3 0xffffffff8084eef1 at trap_fatal+0x351 #4 0xffffffff8084f0e4 at trap_pfault+0x1e4 #5 0xffffffff8084e82f at trap+0x4bf #6 0xffffffff80830d57 at calltrap+0x8 #7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb #8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 #9 0xffffffff8042dcad at ata_dmaload+0x11d #10 0xffffffff8042df7e at ata_begin_transaction+0x7e #11 0xffffffff8042c18e at ataaction+0x9ce #12 0xffffffff802a220f at xpt_run_devq+0x5bf #13 0xffffffff802a17ad at xpt_action_default+0x94d #14 0xffffffff802c0024 at adastart+0x8b4 #15 0xffffffff802a2e93 at xpt_run_allocq+0x193 #16 0xffffffff802c0735 at adastrategy+0xf5 #17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s
Seems correct with recent CURRENT:
(Ok, that's probably not ideal but the error message is complete.) |
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Nov 1, 2016
The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 freebsd#1 0xffffffff80606762 at vpanic+0x182 freebsd#2 0xffffffff806067e3 at panic+0x43 freebsd#3 0xffffffff8084eef1 at trap_fatal+0x351 freebsd#4 0xffffffff8084f0e4 at trap_pfault+0x1e4 freebsd#5 0xffffffff8084e82f at trap+0x4bf freebsd#6 0xffffffff80830d57 at calltrap+0x8 freebsd#7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb freebsd#8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 freebsd#9 0xffffffff8042dcad at ata_dmaload+0x11d freebsd#10 0xffffffff8042df7e at ata_begin_transaction+0x7e freebsd#11 0xffffffff8042c18e at ataaction+0x9ce freebsd#12 0xffffffff802a220f at xpt_run_devq+0x5bf freebsd#13 0xffffffff802a17ad at xpt_action_default+0x94d freebsd#14 0xffffffff802c0024 at adastart+0x8b4 freebsd#15 0xffffffff802a2e93 at xpt_run_allocq+0x193 freebsd#16 0xffffffff802c0735 at adastrategy+0xf5 freebsd#17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s git-svn-id: https://svn.freebsd.org/base/svnadmin@290005 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
rkojedzinszky
pushed a commit
to rkojedzinszky/freebsd
that referenced
this pull request
Dec 16, 2016
Add a -D option to cause it to not call daemon() during startup.
Closing. This appears to be in -current already. Please submit a new request if I'm in error. |
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Mar 10, 2017
Released on October 23rd, 2014. * Restored the atf(7) manual page to serve as a reference to all the other manual pages shipped by ATF. * Added the -s flag to atf-sh to support specifying the shell interpreter to be used. * Removed ATF_WORKDIR. The only remaining consumers have been converted to use the standard TMPDIR environment variable. As a benefit, and because Kyua forces the TMPDIR to live within the test case's work directory, any stale files left behind by ATF will be automatically cleaned up. * Documented the environment variables recognized by each component in the relevant manual pages. This information was lost with the atf-config(1) removal. * Added a new "require.diskspace" metadata property to test cases so that they can specify the minimum amount of disk space required for the test to run. * Renamed the atf-{c,c++,sh}-api(3) manual pages to atf-{c,c++,sh}(3) for discoverability purposes. Symbolic links are provided for the time being to still make the old names visible. * Issue freebsd#5: Recommend the (expected, actual) idiom for calls to the test macros in the manual pages. * Issue freebsd#7: Stopped catching unhandled exceptions in atf-c++ tests. This propagates the crash to the caller, which in turn allows it to obtain proper debugging information. In particular, Kyua should now be able to extract a stacktrace pinpointing the problem. * Issue freebsd#8: Fixed atf-c/macros_test:use test failures spotted by the clang that ships with FreeBSD 11.0-CURRENT. * Issue freebsd#12: Improved documentation of atf-sh(3) and atf-check(1) by better explaining how they relate to each other. * Issue freebsd#14: Stopped setting 'set -e' in atf-sh. This setting was initially added as a way to enable a "strict" mode in the library and to make test cases fail fast when they run unprotected commands. However, doing so in the library is surprising as the responsibility of enabling 'set -e' should be on the user's code. Also, 'set -e' introduces inconsistent behavior on subshells and users do not expect that. * Issue freebsd#15: Fixed atf_utils_{fork,wait} to support nested calls. * Issue freebsd#16: Fixed test failures (by removing a long-standing hack) on systems that lack \e support in printf(1). * Issue freebsd#19: Removed stale references to atf-config and atf-run. git-svn-id: https://svn.freebsd.org/base/vendor/atf/dist@273869 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Dec 29, 2019
With WITNESS enabled we see the following warning: lock order reversal: (sleepable after non-sleepable) 1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297 2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137 stack backtrace: #0 0xffffffc0002a579e at witness_checkorder+0xb72 #1 0xffffffc0002a5556 at witness_checkorder+0x92a #2 0xffffffc000254c7a at _sx_slock_int+0x66 #3 0xffffffc00025537a at _sx_slock+0x8 #4 0xffffffc000123022 at clk_get_freq+0x38 #5 0xffffffc0005463e4 at __clzdi2+0x2bb8 #6 0xffffffc00014af58 at randomdev_getkey+0x76e #7 0xffffffc0001278b0 at simplebus_add_device+0x7ee #8 0xffffffc00027c9a8 at device_attach+0x2e6 #9 0xffffffc00027c634 at device_probe_and_attach+0x7a #10 0xffffffc00027d76a at bus_generic_attach+0x10 #11 0xffffffc00014aab0 at randomdev_getkey+0x2c6 #12 0xffffffc00027c9a8 at device_attach+0x2e6 #13 0xffffffc00027c634 at device_probe_and_attach+0x7a #14 0xffffffc00027d76a at bus_generic_attach+0x10 #15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52 #16 0xffffffc000278b3e at config_intrhook_establish+0x146 #17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe The clock topology lock can sleep, which means we cannot attempt to acquire it while holding the non-sleepable mutex. Fix that by retrieving the clock speed once, during attach and not every time during SPI transaction setup. Submitted by: kp Sponsored by: Axiado git-svn-id: svn+ssh://svn.freebsd.org/base/head@356166 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Dec 29, 2019
With WITNESS enabled we see the following warning: lock order reversal: (sleepable after non-sleepable) 1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297 2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137 stack backtrace: #0 0xffffffc0002a579e at witness_checkorder+0xb72 #1 0xffffffc0002a5556 at witness_checkorder+0x92a #2 0xffffffc000254c7a at _sx_slock_int+0x66 #3 0xffffffc00025537a at _sx_slock+0x8 #4 0xffffffc000123022 at clk_get_freq+0x38 #5 0xffffffc0005463e4 at __clzdi2+0x2bb8 #6 0xffffffc00014af58 at randomdev_getkey+0x76e #7 0xffffffc0001278b0 at simplebus_add_device+0x7ee #8 0xffffffc00027c9a8 at device_attach+0x2e6 #9 0xffffffc00027c634 at device_probe_and_attach+0x7a #10 0xffffffc00027d76a at bus_generic_attach+0x10 #11 0xffffffc00014aab0 at randomdev_getkey+0x2c6 #12 0xffffffc00027c9a8 at device_attach+0x2e6 #13 0xffffffc00027c634 at device_probe_and_attach+0x7a #14 0xffffffc00027d76a at bus_generic_attach+0x10 #15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52 #16 0xffffffc000278b3e at config_intrhook_establish+0x146 #17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe The clock topology lock can sleep, which means we cannot attempt to acquire it while holding the non-sleepable mutex. Fix that by retrieving the clock speed once, during attach and not every time during SPI transaction setup. Submitted by: kp Sponsored by: Axiado
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Jan 6, 2020
With WITNESS enabled we see the following warning: lock order reversal: (sleepable after non-sleepable) 1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297 2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137 stack backtrace: #0 0xffffffc0002a579e at witness_checkorder+0xb72 freebsd#1 0xffffffc0002a5556 at witness_checkorder+0x92a freebsd#2 0xffffffc000254c7a at _sx_slock_int+0x66 freebsd#3 0xffffffc00025537a at _sx_slock+0x8 freebsd#4 0xffffffc000123022 at clk_get_freq+0x38 freebsd#5 0xffffffc0005463e4 at __clzdi2+0x2bb8 freebsd#6 0xffffffc00014af58 at randomdev_getkey+0x76e freebsd#7 0xffffffc0001278b0 at simplebus_add_device+0x7ee freebsd#8 0xffffffc00027c9a8 at device_attach+0x2e6 freebsd#9 0xffffffc00027c634 at device_probe_and_attach+0x7a freebsd#10 0xffffffc00027d76a at bus_generic_attach+0x10 freebsd#11 0xffffffc00014aab0 at randomdev_getkey+0x2c6 freebsd#12 0xffffffc00027c9a8 at device_attach+0x2e6 freebsd#13 0xffffffc00027c634 at device_probe_and_attach+0x7a freebsd#14 0xffffffc00027d76a at bus_generic_attach+0x10 freebsd#15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52 freebsd#16 0xffffffc000278b3e at config_intrhook_establish+0x146 freebsd#17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe The clock topology lock can sleep, which means we cannot attempt to acquire it while holding the non-sleepable mutex. Fix that by retrieving the clock speed once, during attach and not every time during SPI transaction setup. Submitted by: kp Sponsored by: Axiado git-svn-id: https://svn.freebsd.org/base/head@356166 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Aug 22, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 git-svn-id: svn+ssh://svn.freebsd.org/base/head@364480 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Aug 22, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
bdrewery
pushed a commit
to bdrewery/freebsd
that referenced
this pull request
Sep 25, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread freebsd#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 freebsd#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 freebsd#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 freebsd#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 freebsd#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 freebsd#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 freebsd#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 freebsd#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 freebsd#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 freebsd#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 freebsd#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 git-svn-id: svn+ssh://svn.freebsd.org/base/head@364480 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Oct 31, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
uqs
pushed a commit
that referenced
this pull request
Oct 31, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Nov 28, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread freebsd#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 freebsd#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 freebsd#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 freebsd#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 freebsd#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 freebsd#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 freebsd#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 freebsd#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 freebsd#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 freebsd#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 freebsd#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 git-svn-id: https://svn.freebsd.org/base/stable/11@367228 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Nov 28, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread freebsd#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 freebsd#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 freebsd#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 freebsd#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 freebsd#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 freebsd#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 freebsd#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 freebsd#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 freebsd#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 freebsd#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 freebsd#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 git-svn-id: https://svn.freebsd.org/base/stable/12@367228 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Dec 30, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
uqs
pushed a commit
that referenced
this pull request
Dec 30, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
freebsd-git
pushed a commit
that referenced
this pull request
Apr 6, 2021
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 Approved by: so Security: FreeBSD-EN-21:07.lldb (cherry picked from commit eb41eed)
dnelson-1901
pushed a commit
to dnelson-1901/freebsd-src
that referenced
this pull request
Mar 23, 2023
Under certain loads, the following panic is hit: panic: page fault KDB: stack backtrace: #0 0xffffffff805db025 at kdb_backtrace+0x65 freebsd#1 0xffffffff8058e86f at vpanic+0x17f freebsd#2 0xffffffff8058e6e3 at panic+0x43 freebsd#3 0xffffffff808adc15 at trap_fatal+0x385 freebsd#4 0xffffffff808adc6f at trap_pfault+0x4f freebsd#5 0xffffffff80886da8 at calltrap+0x8 freebsd#6 0xffffffff80669186 at vgonel+0x186 freebsd#7 0xffffffff80669841 at vgone+0x31 freebsd#8 0xffffffff8065806d at vfs_hash_insert+0x26d freebsd#9 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#11 0xffffffff8065a28c at lookup+0x45c freebsd#12 0xffffffff806594b9 at namei+0x259 freebsd#13 0xffffffff80676a33 at kern_statat+0xf3 freebsd#14 0xffffffff8067712f at sys_fstatat+0x2f freebsd#15 0xffffffff808ae50c at amd64_syscall+0x10c freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8 The page fault occurs because vgonel() will call VOP_CLOSE() for active vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While here, define vop_open for consistency. After adding the necessary vop, the bug progresses to the following panic: panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1) cpuid = 17 KDB: stack backtrace: #0 0xffffffff805e29c5 at kdb_backtrace+0x65 freebsd#1 0xffffffff8059620f at vpanic+0x17f freebsd#2 0xffffffff81a27f4a at spl_panic+0x3a freebsd#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40 freebsd#4 0xffffffff8066fdee at vinactivef+0xde freebsd#5 0xffffffff80670b8a at vgonel+0x1ea freebsd#6 0xffffffff806711e1 at vgone+0x31 freebsd#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d freebsd#8 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#10 0xffffffff80661c2c at lookup+0x45c freebsd#11 0xffffffff80660e59 at namei+0x259 freebsd#12 0xffffffff8067e3d3 at kern_statat+0xf3 freebsd#13 0xffffffff8067eacf at sys_fstatat+0x2f freebsd#14 0xffffffff808b5ecc at amd64_syscall+0x10c freebsd#15 0xffffffff8088f07b at fast_syscall_common+0xf8 This is caused by a race condition that can occur when allocating a new vnode and adding that vnode to the vfs hash. If the newly created vnode loses the race when being inserted into the vfs hash, it will not be recycled as its usecount is greater than zero, hitting the above assertion. Fix this by dropping the assertion. FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700 Reviewed-by: Andriy Gapon <[email protected]> Reviewed-by: Mateusz Guzik <[email protected]> Reviewed-by: Alek Pinchuk <[email protected]> Reviewed-by: Ryan Moeller <[email protected]> Signed-off-by: Rob Wing <[email protected]> Co-authored-by: Rob Wing <[email protected]> Submitted-by: Klara, Inc. Sponsored-by: rsync.net Closes #14501
dnelson-1901
pushed a commit
to dnelson-1901/freebsd-src
that referenced
this pull request
Jun 15, 2023
Under certain loads, the following panic is hit: panic: page fault KDB: stack backtrace: #0 0xffffffff805db025 at kdb_backtrace+0x65 freebsd#1 0xffffffff8058e86f at vpanic+0x17f freebsd#2 0xffffffff8058e6e3 at panic+0x43 freebsd#3 0xffffffff808adc15 at trap_fatal+0x385 freebsd#4 0xffffffff808adc6f at trap_pfault+0x4f freebsd#5 0xffffffff80886da8 at calltrap+0x8 freebsd#6 0xffffffff80669186 at vgonel+0x186 freebsd#7 0xffffffff80669841 at vgone+0x31 freebsd#8 0xffffffff8065806d at vfs_hash_insert+0x26d freebsd#9 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#11 0xffffffff8065a28c at lookup+0x45c freebsd#12 0xffffffff806594b9 at namei+0x259 freebsd#13 0xffffffff80676a33 at kern_statat+0xf3 freebsd#14 0xffffffff8067712f at sys_fstatat+0x2f freebsd#15 0xffffffff808ae50c at amd64_syscall+0x10c freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8 The page fault occurs because vgonel() will call VOP_CLOSE() for active vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While here, define vop_open for consistency. After adding the necessary vop, the bug progresses to the following panic: panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1) cpuid = 17 KDB: stack backtrace: #0 0xffffffff805e29c5 at kdb_backtrace+0x65 freebsd#1 0xffffffff8059620f at vpanic+0x17f freebsd#2 0xffffffff81a27f4a at spl_panic+0x3a freebsd#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40 freebsd#4 0xffffffff8066fdee at vinactivef+0xde freebsd#5 0xffffffff80670b8a at vgonel+0x1ea freebsd#6 0xffffffff806711e1 at vgone+0x31 freebsd#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d freebsd#8 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#10 0xffffffff80661c2c at lookup+0x45c freebsd#11 0xffffffff80660e59 at namei+0x259 freebsd#12 0xffffffff8067e3d3 at kern_statat+0xf3 freebsd#13 0xffffffff8067eacf at sys_fstatat+0x2f freebsd#14 0xffffffff808b5ecc at amd64_syscall+0x10c freebsd#15 0xffffffff8088f07b at fast_syscall_common+0xf8 This is caused by a race condition that can occur when allocating a new vnode and adding that vnode to the vfs hash. If the newly created vnode loses the race when being inserted into the vfs hash, it will not be recycled as its usecount is greater than zero, hitting the above assertion. Fix this by dropping the assertion. FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700 Reviewed-by: Andriy Gapon <[email protected]> Reviewed-by: Mateusz Guzik <[email protected]> Reviewed-by: Alek Pinchuk <[email protected]> Reviewed-by: Ryan Moeller <[email protected]> Signed-off-by: Rob Wing <[email protected]> Co-authored-by: Rob Wing <[email protected]> Submitted-by: Klara, Inc. Sponsored-by: rsync.net Closes #14501
freebsd-git
pushed a commit
that referenced
this pull request
Sep 5, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications
freebsd-git
pushed a commit
that referenced
this pull request
Sep 18, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications (cherry picked from commit 3814249)
freebsd-git
pushed a commit
that referenced
this pull request
Sep 19, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH Sponsored by: Chelsio Communications Approved by: re (kib) (cherry picked from commit 3814249) (cherry picked from commit 3287f64)
freebsd-git
pushed a commit
that referenced
this pull request
Jan 25, 2024
Interesting fixes: 03c83f5 add __cxa_init_primary_exception (#23) 5d8a158 Fix two bugs in __cxa_end_cleanup() b00c6c5 Insert padding in __cxa_dependent_exception 45ca8b1 Insert padding in __cxa_exception struct for compatibility f2e5509 Fix unlock in two-word version and add missing comment. 6229590 Add an option for disabling emergency buffers. (#14)
freebsd-git
pushed a commit
that referenced
this pull request
Jan 25, 2024
Interesting fixes (* were already cherry-picked): - 03c83f5 add __cxa_init_primary_exception (#23) * 5d8a158 Fix two bugs in __cxa_end_cleanup() * b00c6c5 Insert padding in __cxa_dependent_exception * 45ca8b1 Insert padding in __cxa_exception struct for compatibility * f2e5509 Fix unlock in two-word version and add missing comment. - 6229590 Add an option for disabling emergency buffers. (#14) MFC after: 2 weeks
freebsd-git
pushed a commit
that referenced
this pull request
Feb 8, 2024
Interesting fixes (* were already cherry-picked): - 03c83f5 add __cxa_init_primary_exception (#23) * 5d8a158 Fix two bugs in __cxa_end_cleanup() * b00c6c5 Insert padding in __cxa_dependent_exception * 45ca8b1 Insert padding in __cxa_exception struct for compatibility * f2e5509 Fix unlock in two-word version and add missing comment. - 6229590 Add an option for disabling emergency buffers. (#14) MFC after: 2 weeks (cherry picked from commit ecf4106)
freebsd-git
pushed a commit
that referenced
this pull request
Feb 8, 2024
Interesting fixes (* were already cherry-picked): - 03c83f5 add __cxa_init_primary_exception (#23) * 5d8a158 Fix two bugs in __cxa_end_cleanup() * b00c6c5 Insert padding in __cxa_dependent_exception * 45ca8b1 Insert padding in __cxa_exception struct for compatibility * f2e5509 Fix unlock in two-word version and add missing comment. - 6229590 Add an option for disabling emergency buffers. (#14) MFC after: 2 weeks (cherry picked from commit ecf4106)
bnovkov
pushed a commit
to bnovkov/freebsd-src
that referenced
this pull request
Aug 23, 2024
PT: More comments, style fixes, and interrupt line sharing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Phabric keeps dropping my diff submissions so I'm putting this here.
Right now xo_warn() causes problems because it doesn't output the error number any longer.
This is what xo_warn should output:
However libxo is broken and only outputs this: