Can't run a system command in Windows - windows

The Rust code is
use std::process::Command;
fn main() {
if cfg!(target_os = "windows") {
Command::new("cls").spawn().expect("cls command failed to start");
} else {
println!("Not windows");
}
}
and the error is
PS C:\dev\Rust\testing> cargo run
Compiling testing v0.1.0 (C:\dev\Rust\testing)
Finished dev [unoptimized + debuginfo] target(s) in 0.95s
Running `target\debug\testing.exe`
thread 'main' panicked at 'cls command failed to start: Os { code: 2, kind: NotFound, message: "The system cannot find the file
specified." }', src\main.rs:5:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\testing.exe` (exit code: 101)
with RUST_BACKTRACE="full":
PS C:\dev\Rust\testing> cargo run
Compiling testing v0.1.0 (C:\dev\Rust\testing)
Finished dev [unoptimized + debuginfo] target(s) in 1.12s
Running `target\debug\testing.exe`
thread 'main' panicked at 'cls command failed to start: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', src\main.rs:5:37
stack backtrace:
0: 0x7ff7c9ecf059 - std::backtrace_rs::backtrace::dbghelp::trace
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
1: 0x7ff7c9ecf059 - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
2: 0x7ff7c9ecf059 - std::sys_common::backtrace::_print_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:79
3: 0x7ff7c9ecf059 - std::sys_common::backtrace::_print::{{impl}}::fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:58
4: 0x7ff7c9ee32fb - core::fmt::write
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\fmt\mod.rs:1080
5: 0x7ff7c9ecc598 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\io\mod.rs:1516
6: 0x7ff7c9ed1ae4 - std::sys_common::backtrace::_print
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:61
7: 0x7ff7c9ed1ae4 - std::sys_common::backtrace::print
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:48
8: 0x7ff7c9ed1ae4 - std::panicking::default_hook::{{closure}}
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:208
9: 0x7ff7c9ed16c8 - std::panicking::default_hook
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:227
10: 0x7ff7c9ed239f - std::panicking::rust_panic_with_hook
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:577
11: 0x7ff7c9ed1f05 - std::panicking::begin_panic_handler::{{closure}}
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:484
12: 0x7ff7c9ecf93f - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\sys_common\backtrace.rs:153
13: 0x7ff7c9ed1eb9 - std::panicking::begin_panic_handler
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:483
14: 0x7ff7c9ee2590 - core::panicking::panic_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\panicking.rs:85
15: 0x7ff7c9ee23b3 - core::option::expect_none_failed
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\option.rs:1234
16: 0x7ff7c9ec11c8 - core::result::Result<std::process::Child, std::io::error::Error>::expect<std::process::Child,std::io::error::Error>
at C:\Users\sadic\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\result.rs:933
17: 0x7ff7c9ec5f8f - testing::main
at C:\dev\Rust\testing\src\main.rs:5
18: 0x7ff7c9ec31eb - core::ops::function::FnOnce::call_once<fn(),tuple<>>
at C:\Users\sadic\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227
19: 0x7ff7c9ec1d7b - std::sys_common::backtrace::__rust_begin_short_backtrace<fn(),tuple<>>
at C:\Users\sadic\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys_common\backtrace.rs:137
20: 0x7ff7c9ec40e1 - std::rt::lang_start::{{closure}}<tuple<>>
at C:\Users\sadic\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:66
21: 0x7ff7c9ed25a3 - core::ops::function::impls::{{impl}}::call_once
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\ops\function.rs:280
22: 0x7ff7c9ed25a3 - std::panicking::try::do_call
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:381
23: 0x7ff7c9ed25a3 - std::panicking::try
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:345
24: 0x7ff7c9ed25a3 - std::panic::catch_unwind
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panic.rs:382
25: 0x7ff7c9ed25a3 - std::rt::lang_start_internal
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\rt.rs:51
26: 0x7ff7c9ec40b3 - std::rt::lang_start<tuple<>>
at C:\Users\sadic\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:65
27: 0x7ff7c9ec6000 - main
28: 0x7ff7c9ee76c8 - invoke_main
at d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
29: 0x7ff7c9ee76c8 - __scrt_common_main_seh
at d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
30: 0x7ffef5167034 - BaseThreadInitThunk
31: 0x7ffef617d0d1 - RtlUserThreadStart
error: process didn't exit successfully: `target\debug\testing.exe` (exit code: 101)
in contrast I have a C++ source file doing exactly the same successfully
#include <stdlib.h>
int main() {
system("cls");
}
I installed rustup using rustup_init.exe from rustup.rs and I am using cargo nightly to run the program, the stable branch does the same thing, I also have installed mingw64 and llvm if that helps. I didn't found anyone with the same problem in the internet. So, what it's happening and what do I do to solve this?

The reason it doesn't work is because cls is not an executable on Windows, it's a command of the Windows command line interpreter.
So if you want to execute it, you instead have to execute cmd /c cls.
Command::new("cmd")
.args(&["/c", "cls"])
.spawn()
.expect("cls command failed to start")
.wait()
.expect("failed to wait");
Alternatively, if you just want to clear the screen, you could also use the console crate.
// console = "0.14.0"
let term = console::Term::stdout();
term.clear_screen().expect("failed clearing screen");
Related:
"Clear screen with Windows “cls” command in Java console application"
"Java: Clear the console"
While those questions are not related to Rust, they do elaborate on cls not being an executable.

Related

Linux kernel: Will wait_event_interruptible sleep forever when the preemption happens right after prepare_to_wait_event? [duplicate]

This question already has an answer here:
Will process lost wake-up chance in a preemptive kernel?
(1 answer)
Closed 1 year ago.
I'm a bit confused when reading the kernel's source code on wait_event_interruptible because it does not look safe when taking into account the preemption.
Here is the main logic of the source code:
1: #define ___wait_event(wq_head, condition, state, exclusive, ret, cmd) \
2: ({ \
3: __label__ __out; \
4: struct wait_queue_entry __wq_entry; \
5: long __ret = ret; /* explicit shadow */ \
6: \
7: init_wait_entry(&__wq_entry, exclusive ? WQ_FLAG_EXCLUSIVE : 0); \
8: for (;;) { \
9: long __int = prepare_to_wait_event(&wq_head, &__wq_entry, state);\
10: \
11: if (condition) \
12: break; \
13: \
14: if (___wait_is_interruptible(state) && __int) { \
15: __ret = __int; \
16: goto __out; \
17: } \
18: \
19: cmd; \
20: } \
21: finish_wait(&wq_head, &__wq_entry); \
22: __out: __ret; \
23: })
This macro is not wrapped in a preemption-disabling block, and so I think it's possible that the corresponding process could be switched out in line 10. So under the following scenario:
There is only on wakeup for this sleep.
The aforementioned wakeup occurs in another cpu when this code is in line 8.
An interrupt kicked in at line 10, and this process is switched out as the result.
As a result, this process will stay in TASK_INTERRUPTIBLE forever.
I'm wondering if that is the case or did I miss anything?
The linux code I'm looking at: https://elixir.bootlin.com/linux/v5.13.4/source/include/linux/wait.h#L274
Surely, it would stay hang but next time when process gets schedule and it resumes it would check the condition and would find condition as true and it would break.
Let suppose condition goes bad as other process modified value then it would hang until someone trigger signal to it and this process would check the signal and break out of for loop.

VSCode Rust debugging with lldb and cppvsdbg panics at "NotFound" message

Trying to debug my program written in rust with lldb and cppvsdbg, and after executing a function, that supposed to return either tuple of Result(Protocol, Value), or Box<dyn std::error::Error> it throws this panic:
thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', replay_parser\src\lib.rs:167:55
I.e. it cannot find some file.
Not sure what file it refers to, but here is a full backtrace:
From lldb:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', replay_parser\src\lib.rs:167:55
stack backtrace:
0: 0x7ff78321d28e - std::backtrace_rs::backtrace::dbghelp::trace
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
1: 0x7ff78321d28e - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
2: 0x7ff78321d28e - std::sys_common::backtrace::_print_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:67
3: 0x7ff78321d28e - std::sys_common::backtrace::_print::{{impl}}::fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:46
4: 0x7ff78323422b - core::fmt::write
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\fmt\mod.rs:1078
5: 0x7ff783218ab8 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\io\mod.rs:1517
6: 0x7ff78321ffcd - std::sys_common::backtrace::_print
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:49
7: 0x7ff78321ffcd - std::sys_common::backtrace::print
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:36
8: 0x7ff78321ffcd - std::panicking::default_hook::{{closure}}
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:208
9: 0x7ff78321fa34 - std::panicking::default_hook
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:225
10: 0x7ff7832208de - std::panicking::rust_panic_with_hook
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:591
11: 0x7ff783220401 - std::panicking::begin_panic_handler::{{closure}}
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:497
12: 0x7ff78321dbef - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:141
13: 0x7ff783220359 - std::panicking::begin_panic_handler
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:493
14: 0x7ff783233550 - core::panicking::panic_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\panicking.rs:92
15: 0x7ff783233373 - core::option::expect_none_failed
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\option.rs:1268
16: 0x7ff782fd55e2 - core::result::Result<mpq::archive::Archive, std::io::error::Error>::unwrap<mpq::archive::Archive,std::io::error::Error>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\result.rs:973
17: 0x7ff782fd4600 - replay_parser::parse_replay
at D:\Projects\SC2Emul\SC2Emulator\replay_parser\src\lib.rs:167
18: 0x7ff782fd14d8 - sc2_emulator::main
at D:\Projects\SC2Emul\SC2Emulator\sc2emul\src\main.rs:31
19: 0x7ff782fd174b - core::ops::function::FnOnce::call_once<fn() -> core::result::Result<tuple<>, log::SetLoggerError>,tuple<>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227
20: 0x7ff782fd154b - std::sys_common::backtrace::__rust_begin_short_backtrace<fn() -> core::result::Result<tuple<>, log::SetLoggerError>,core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys_common\backtrace.rs:125
21: 0x7ff782fd17f1 - std::rt::lang_start::{{closure}}<core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:66
22: 0x7ff783220a94 - core::ops::function::impls::{{impl}}::call_once
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\library\core\src\ops\function.rs:280
23: 0x7ff783220a94 - std::panicking::try::do_call
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:379
24: 0x7ff783220a94 - std::panicking::try
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:343
25: 0x7ff783220a94 - std::panic::catch_unwind
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panic.rs:396
26: 0x7ff783220a94 - std::rt::lang_start_internal
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\rt.rs:51
27: 0x7ff782fd17c3 - std::rt::lang_start<core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:65
28: 0x7ff782fd1510 - main
29: 0x7ff78325abbc - invoke_main
at d:\A01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
30: 0x7ff78325abbc - __scrt_common_main_seh
at d:\A01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
31: 0x7ffed1de7034 - BaseThreadInitThunk
32: 0x7ffed1f82651 - RtlUserThreadStart
And from cppvsdbg:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', replay_parser\src\lib.rs:167:55
stack backtrace:
0: 0x7ff78321d28e - std::backtrace_rs::backtrace::dbghelp::trace
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
1: 0x7ff78321d28e - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
2: 0x7ff78321d28e - std::sys_common::backtrace::_print_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:67
3: 0x7ff78321d28e - std::sys_common::backtrace::_print::{{impl}}::fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:46
4: 0x7ff78323422b - core::fmt::write
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\fmt\mod.rs:1078
5: 0x7ff783218ab8 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\io\mod.rs:1517
6: 0x7ff78321ffcd - std::sys_common::backtrace::_print
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:49
7: 0x7ff78321ffcd - std::sys_common::backtrace::print
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:36
8: 0x7ff78321ffcd - std::panicking::default_hook::{{closure}}
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:208
9: 0x7ff78321fa34 - std::panicking::default_hook
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:225
10: 0x7ff7832208de - std::panicking::rust_panic_with_hook
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:591
11: 0x7ff783220401 - std::panicking::begin_panic_handler::{{closure}}
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:497
12: 0x7ff78321dbef - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:141
13: 0x7ff783220359 - std::panicking::begin_panic_handler
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:493
14: 0x7ff783233550 - core::panicking::panic_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\panicking.rs:92
15: 0x7ff783233373 - core::option::expect_none_failed
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\option.rs:1268
16: 0x7ff782fd55e2 - core::result::Result<mpq::archive::Archive, std::io::error::Error>::unwrap<mpq::archive::Archive,std::io::error::Error>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\result.rs:973
17: 0x7ff782fd4600 - replay_parser::parse_replay
at D:\Projects\SC2Emul\SC2Emulator\replay_parser\src\lib.rs:167
18: 0x7ff782fd14d8 - sc2_emulator::main
at D:\Projects\SC2Emul\SC2Emulator\sc2emul\src\main.rs:31
19: 0x7ff782fd174b - core::ops::function::FnOnce::call_once<fn() -> core::result::Result<tuple<>, log::SetLoggerError>,tuple<>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227
20: 0x7ff782fd154b - std::sys_common::backtrace::__rust_begin_short_backtrace<fn() -> core::result::Result<tuple<>, log::SetLoggerError>,core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys_common\backtrace.rs:125
21: 0x7ff782fd17f1 - std::rt::lang_start::{{closure}}<core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:66
22: 0x7ff783220a94 - core::ops::function::impls::{{impl}}::call_once
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\library\core\src\ops\function.rs:280
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', replay_parser\src\lib.rs:167:55
stack backtrace:
0: 0x7ff78321d28e - std::backtrace_rs::backtrace::dbghelp::trace
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
1: 0x7ff78321d28e - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
2: 0x7ff78321d28e - std::sys_common::backtrace::_print_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:67
3: 0x7ff78321d28e - std::sys_common::backtrace::_print::{{impl}}::fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:46
4: 0x7ff78323422b - core::fmt::write
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\fmt\mod.rs:1078
5: 0x7ff783218ab8 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\io\mod.rs:1517
6: 0x7ff78321ffcd - std::sys_common::backtrace::_print
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:49
7: 0x7ff78321ffcd - std::sys_common::backtrace::print
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:36
8: 0x7ff78321ffcd - std::panicking::default_hook::{{closure}}
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:208
9: 0x7ff78321fa34 - std::panicking::default_hook
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:225
10: 0x7ff7832208de - std::panicking::rust_panic_with_hook
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:591
11: 0x7ff783220401 - std::panicking::begin_panic_handler::{{closure}}
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:497
12: 0x7ff78321dbef - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\sys_common\backtrace.rs:141
13: 0x7ff783220359 - std::panicking::begin_panic_handler
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:493
14: 0x7ff783233550 - core::panicking::panic_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\panicking.rs:92
15: 0x7ff783233373 - core::option::expect_none_failed
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\option.rs:1268
16: 0x7ff782fd55e2 - core::result::Result<mpq::archive::Archive, std::io::error::Error>::unwrap<mpq::archive::Archive,std::io::error::Error>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\result.rs:973
17: 0x7ff782fd4600 - replay_parser::parse_replay
at D:\Projects\SC2Emul\SC2Emulator\replay_parser\src\lib.rs:167
18: 0x7ff782fd14d8 - sc2_emulator::main
at D:\Projects\SC2Emul\SC2Emulator\sc2emul\src\main.rs:31
19: 0x7ff782fd174b - core::ops::function::FnOnce::call_once<fn() -> core::result::Result<tuple<>, log::SetLoggerError>,tuple<>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227
20: 0x7ff782fd154b - std::sys_common::backtrace::__rust_begin_short_backtrace<fn() -> core::result::Result<tuple<>, log::SetLoggerError>,core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys_common\backtrace.rs:125
21: 0x7ff782fd17f1 - std::rt::lang_start::{{closure}}<core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:66
22: 0x7ff783220a94 - core::ops::function::impls::{{impl}}::call_once
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\library\core\src\ops\function.rs:280
23: 0x7ff783220a94 - std::panicking::try::do_call
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:379
24: 0x7ff783220a94 - std::panicking::try
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:343
25: 0x7ff783220a94 - std::panic::catch_unwind
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panic.rs:396
26: 0x7ff783220a94 - std::rt::lang_start_internal
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\rt.rs:51
27: 0x7ff782fd17c3 - std::rt::lang_start<core::result::Result<tuple<>, log::SetLoggerError>>
at C:\Users\Xeizzeth\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\rt.rs:65
28: 0x7ff782fd1510 - main
29: 0x7ff78325abbc - invoke_main
at d:\A01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
30: 0x7ff78325abbc - __scrt_common_main_seh
at d:\A01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
31: 0x7ffed1de7034 - BaseThreadInitThunk
32: 0x7ffed1f82651 - RtlUserThreadStart
Any help is appreciated.
The problem was that it couldn't find the replay archive specified. I supplied it with relative path, and during debugging it couldn't find it by relative path so I had to supply the absolute path.

Can a debugger produce a list of all executed lines of source code of an attached process?

I'm working for a company, that does not have a habit of adding log entries in their source code.
Hence, if something goes wrong, the amount of logs, explaining what might have happened, is too small to make any real analysis.
Therefore I'm looking for a tool which can do the following:
Attach to a running process and link to the symbols file.
Follow all lines of source code which are executed.
After a certain key is pressed (like "Ctrl+C"), produce a report which looks as follows:
[]
file1.c:010: function1(1, 2, 5)
file1.c:011: sum(1,2)
file1.c:020: return 3;
file1.c:012: sum(3,5);
file1.c:020: return 8;
file1.c:012: return 8;
I can imagine this question sounding very naïve, but if I can have something which just approaches this result, it might be very useful.
Does anybody know if this can be achieved using windbg, cdb, Visual Studio or any other means?
do you have the source code and symbols for your exe
if yes windbg can step and print source lines
demo below for a simple recv sample
start an executable whose pdb with src info is available
:\>cdb recv
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
windbg breaks on system breakpoint
ntdll!LdrpDoDebuggerBreak+0x2c:
771a05a6 cc int 3
enable loading of line information
enable stepping in source mode
enable printing of src lines
0:000> .lines
Line number information will be loaded
0:000> l+t
Source options are 1:
1/t - Step/trace by source line
0:000> l+s
Source options are 5:
1/t - Step/trace by source line
4/s - List source code at prompt
disallow all other output except src
0:000> .prompt_allow -reg -dis -sym -ea
Allow the following information to be displayed at the prompt:
(Other settings can affect whether the information is actually displayed)
src - Source info for current instruction
Do not allow the following information to be displayed at the prompt:
sym - Symbol for current instruction
dis - Disassembly of current instruction
ea - Effective address for current instruction
reg - Register state
go to main and step 10 times
you will see each step is showing the src
read and use controlling the target in windbg help to know about various
execution methods like step until return , step until branch etc
0:000> g recv!main
ModLoad: 69f50000 69f53000 C:\Windows\system32\api-ms-win-core-synch-l1-2-0.DLL
> 13: int __cdecl main() {
0:000> p 10
> 24: iResult = WSAStartup(MAKEWORD(2,2), &wsaData);
> 25: if (iResult != NO_ERROR) {
> 30: ConnectSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
> 31: if (ConnectSocket == INVALID_SOCKET) {
> 38: clientService.sin_family = AF_INET;
> 39: clientService.sin_addr.s_addr = inet_addr( "127.0.0.1" );
> 40: clientService.sin_port = htons( 27015 );
> 42: iResult = connect( ConnectSocket, (SOCKADDR*) &clientService, sizeof(clientService) );
> 43: if ( iResult == SOCKET_ERROR) {
> 44: closesocket (ConnectSocket);
> 45: printf("Unable to connect to server: %ld\n", WSAGetLastError());
Unable to connect to server: 0
> 66: WSACleanup();
> 67: return 1;
> 88: }
*** The C++ standard library and CRT step filter can be enabled to skip this fun
ction. Run .settings set Sources.SkipCrtCode = true">.settings set Sources.SkipC
rtCode = true to enable it. ***

Sonar scanner error: Unable to parse file

We have implemented ESlint Plugin in Sonarqube 5.6.6 for performing Sonar anlysis of a Javascript project.
I am executing the following tasks:
Checking out the code from repository
Running sonar-scanner on the checked out code.
Although the task is getting executed successfully, but I am getting an error while executing the task. the logs for the error part is as follows:
19:57:54.069 ERROR: Unable to parse file: /ebs/deployment/codebases/test-design/sonar/lib/atomic/List/LI/index.js
19:57:54.071 ERROR: Parse error at line 14 column 40:
4:
5: import React from 'react';
6: import classnames from 'classnames';
7: import PropTypes from 'prop-types';
8: import styles from './LI.css';
9:
10:
11: // eslint-disable-next-line
12: console.log(styles.length);
13:
14: const LI = ({ ...props, children, data = {}, titleKey = '', className = {}, styleNames, style, onClick, onMouseOver, onMouseOut }) => (
^
15: <li
16: {...props}
17: className={classnames(className)}
18: style={style}
19: data={data}
20: styleName={`li ${styleNames}`}
21: >
22: <button
23: styleName="buttonsStyles"
24: onClick={event => onClick(event, data)}
19:57:54.574 ERROR: Unable to parse file: /ebs/deployment/codebases/test-design/sonar/lib/atomic/Tabs/index.js
19:57:54.576 ERROR: Parse error at line 46 column 22:
36: className={className}
37: onMouseOver={onMouseOver}
38: onMouseOut={onMouseOut}
39: onClick={onClick}
40: />)
41: ))}
42: </UL>);
43:
44: const BorderedTab = ({
45: ...props,
46: liActiveStyleNames = '',
^
47: liStyleNames = '',
48: ulStyleNames = '',
49: }) => (<TabComponent
50: {...props}
51:
52: liStyleNames={`borderedTab ${liStyleNames || ''}`}
53: liActiveStyleNames={`borderedTabAcive ${liActiveStyleNames || ''}`}
54: ulStyleNames={`borderedTab ${ulStyleNames || ''}`}
55: />);
56:
Although the job ran successfully, but I am not sure whether the analysis is correct or not.
The sonar-scanner command is as follows:
sonar-scanner -Dsonar.sources=. -Dsonar.projectVersion=v1 -Dsonar.projectKey=test-design -Dsonar.projectName=test-DesigneSystem -Dsonar.host.url=http://localhost:9000 '-Dsonar.exclusions=**/font/**' -X
The profiles which we are using: csslint, eslint
Can anybody tell me what may be the issue.

sbcl memory-fault-error with zeromq

I am new to Lisp, and am trying to work with ZMQ in it. For a simple function, I get the error below. How do I debug this error? Are there tools to help? It isn't dropping me into the ldb, how do I see what is at the address printed with the error?
Unhandled memory fault at #x10CC8B000.
[Condition of type SB-SYS:MEMORY-FAULT-ERROR]
Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [ABORT] abort thread (#<THREAD "new-repl-thread" RUNNING {1003E0F353}>)
Backtrace:
0: (SB-SYS:MEMORY-FAULT-ERROR)
[No Locals]
1: ("foreign function: call_into_lisp")
[No Locals]
2: ("foreign function: post_signal_tramp")
[No Locals]
3: ("foreign function: _ZN3zmq6pipe_t12get_identityEv")
[No Locals]
4: ("foreign function: _ZN3zmq8router_t5xrecvEPNS_5msg_tE")
[No Locals]
5: ("foreign function: _ZN3zmq5rep_t5xrecvEPNS_5msg_tE")
[No Locals]
6: ("foreign function: _ZN3zmq13socket_base_t4recvEPNS_5msg_tEi")
[No Locals]
7: ("foreign function: _ZL9s_recvmsgPN3zmq13socket_base_tEP9zmq_msg_ti")
[No Locals]
8: (ZEROMQ::%MSG-RECV #.(SB-SYS:INT-SAP #X005002D0) #.(SB-SYS:INT-SAP #X06006000) 0)
Locals:
SB-DEBUG::ARG-0 = #.(SB-SYS:INT-SAP #X005002D0)
SB-DEBUG::ARG-1 = #.(SB-SYS:INT-SAP #X06006000)
SB-DEBUG::ARG-2 = 0
9: ((LAMBDA (&REST SB-DI::ARGS) :IN SB-DI::HANDLE-SINGLE-STEP-AROUND-TRAP) #.(SB-SYS:INT-SAP #X06006000) #S(ZEROMQ:MSG :RAW #.(SB-SYS:INT-SAP #X005002D0)))
Locals:
SB-DI::ARGS = (#.(SB-SYS:INT-SAP #X06006000) #S(ZEROMQ:MSG :RAW #.(SB-SYS:INT-SAP #X005002D0)))
10: (RECV)
Locals:
CONTEXT = #.(SB-SYS:INT-SAP #X00500CC0)
SOCKET = #.(SB-SYS:INT-SAP #X06006000)
11: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RECV) #<NULL-LEXENV>)
Locals:
SB-DEBUG::ARG-0 = (RECV)
SB-DEBUG::ARG-1 = #<NULL-LEXENV>
12: (EVAL (RECV))
Locals:
SB-DEBUG::ARG-0 = (RECV)
--more--
Here is the code I am trying to run. I am running these two functions in two different sbcl processes
sbcl<1>
(defun send ()
(zmq:with-context (context)
(zmq:with-socket (socket context :req)
(break)
(zmq:connect socket "tcp://127.0.0.1:3333")
(break)
(zmq:msg-send socket (zmq:make-msg :size 6 :data "Jello")))))
(send)
sbcl<2>
(defun recv ()
(zmq:with-context (context)
(zmq:with-socket (socket context :rep)
(break)
(zmq:bind socket "tcp://127.0.0.1:3333")
(break)
(zmq:msg-recv
socket (zmq:make-msg :size 6)))))
(recv)
[EDIT]
After a bit of digging around, I found this message in the buffer
* sbcl(49664,0x700000104000) malloc: *** error for object 0x500058: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
CORRUPTION WARNING in SBCL pid 49664(tid 123145303375872):
Received signal 6 in non-lisp thread 123145303375872, resignalling to a lisp thread.
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
I have used the same C library with it's Python & Node bindings and it works without errors in Python and Node. I am only running into these errors with CL
So after a few days of hanging out in the #zeromq IRC, using lldb to debug the memory issues, I finally gave up. The CL bindings for zeromq aren't tested on OS X, and they do not work.
I switched to Ubuntu, and had no such problems.

Resources