Sonar scanner error: Unable to parse file - sonarqube

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.

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't run a system command in 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.

Go detects concurrent read and write on map despite locks

I'm writing a simple caching mechanism which has an Add an Evict and a Search method. The Search is currently not implemented yet, so there's no need to worry about that.
There's a relatively large number of goroutines that call Add to add data and there's only one which runs in an evict loop to evict data. As soon as I put some serious traffic on it Go throws up saying there's a concurrent read and write access on the map metricCache, but I can't see how that can happen because there are locks around it. I'm using Go 1.7.
File mdata/cache.go:
57: func NewCCache() *CCache {
58: cc := &CCache{
59: lock: sync.RWMutex{},
60: metricCache: make(map[string]*CCacheMetric),
61: accnt: accnt.NewFlatAccnt(maxSize),
62: }
63: go cc.evictLoop()
64: return cc
65: }
66:
67: func (c *CCache) evictLoop() {
68: evictQ := c.accnt.GetEvictQ()
69: for target := range evictQ {
70: c.evict(target)
71: }
72: }
73:
74: func (c *CCache) Add(metric string, prev uint32, itergen chunk.IterGen) {
75: c.lock.Lock()
76:
77: if ccm, ok := c.metricCache[metric]; !ok {
78: var ccm *CCacheMetric
79: ccm = NewCCacheMetric()
80: ccm.Init(prev, itergen)
81: c.metricCache[metric] = ccm
82: } else {
83: ccm.Add(prev, itergen)
84: }
85: c.lock.Unlock()
86:
87: c.accnt.AddChunk(metric, itergen.Ts(), itergen.Size())
88: }
89:
90: func (c *CCache) evict(target *accnt.EvictTarget) {
91: c.lock.Lock()
92:
93: if _, ok := c.metricCache[target.Metric]; ok {
94: log.Debug("cache: evicting chunk %d on metric %s\n", target.Ts, target.Metric)
95: length := c.metricCache[target.Metric].Del(target.Ts)
96: if length == 0 {
97: delete(c.metricCache, target.Metric)
98: }
99: }
100:
101: c.lock.Unlock()
102: }
That's the error message:
metrictank_1 | fatal error: concurrent map read and map write
metrictank_1 |
metrictank_1 | goroutine 3159 [running]:
metrictank_1 | runtime.throw(0xaade7e, 0x21)
metrictank_1 | /usr/local/go/src/runtime/panic.go:566 +0x95 fp=0xc4216a7eb8 sp=0xc4216a7e98
metrictank_1 | runtime.mapaccess2_faststr(0x9e22c0, 0xc42031e600, 0xc4210c2b10, 0x22, 0x28, 0xa585d5496)
metrictank_1 | /usr/local/go/src/runtime/hashmap_fast.go:306 +0x52b fp=0xc4216a7f18 sp=0xc4216a7eb8
metrictank_1 | github.com/raintank/metrictank/mdata/cache.(*CCache).Add(0xc4202fa070, 0xc4210c2b10, 0x22, 0x0, 0xc421875f82, 0x25, 0x25, 0xa585d5496)
metrictank_1 | /home/mst/go/src/github.com/raintank/metrictank/mdata/cache/cache.go:77 +0x63 fp=0xc4216a7f80 sp=0xc4216a7f18
metrictank_1 | runtime.goexit()
metrictank_1 | /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4216a7f88 sp=0xc4216a7f80
metrictank_1 | created by github.com/raintank/metrictank/api.(*Server).getSeries
metrictank_1 | /home/mst/go/src/github.com/raintank/metrictank/api/dataprocessor.go:442 +0x122b
UPDATE: I recompiled with -race and now I'm getting a different error. This looks as if the RWMutex were completely ineffective because according to the backtraces the problem must be in the combination of the evict and Add methods.
==================
WARNING: DATA RACE
Read at 0x00c4201c81e0 by goroutine 215:
runtime.mapaccess2_faststr()
/usr/local/go/src/runtime/hashmap_fast.go:297 +0x0
github.com/raintank/metrictank/mdata/cache.(*CCache).Add()
/home/mst/go/src/github.com/raintank/metrictank/mdata/cache/cache.go:77 +0xaa
Previous write at 0x00c4201c81e0 by goroutine 155:
runtime.mapdelete()
/usr/local/go/src/runtime/hashmap.go:558 +0x0
github.com/raintank/metrictank/mdata/cache.(*CCache).evict()
/home/mst/go/src/github.com/raintank/metrictank/mdata/cache/cache.go:97 +0x30e
github.com/raintank/metrictank/mdata/cache.(*CCache).evictLoop()
/home/mst/go/src/github.com/raintank/metrictank/mdata/cache/cache.go:70 +0xb3
Goroutine 215 (running) created at:
github.com/raintank/metrictank/api.(*Server).getSeries()
/home/mst/go/src/github.com/raintank/metrictank/api/dataprocessor.go:442 +0x17c9
github.com/raintank/metrictank/api.(*Server).getTarget()
/home/mst/go/src/github.com/raintank/metrictank/api/dataprocessor.go:331 +0x9c3
github.com/raintank/metrictank/api.(*Server).getTargetsLocal.func1()
/home/mst/go/src/github.com/raintank/metrictank/api/dataprocessor.go:284 +0xa9
Goroutine 155 (running) created at:
github.com/raintank/metrictank/mdata/cache.NewCCache()
/home/mst/go/src/github.com/raintank/metrictank/mdata/cache/cache.go:63 +0x12f
main.main()
/home/mst/go/src/github.com/raintank/metrictank/metrictank.go:388 +0x246c
==================
A colleague of mine has found the answer:
After calling NewCCache() I copied the returned variable by value (including the lock) and then called Add() on the copy, at the same time the evictLoop() go routine was still referring to the old copy. So they were operating on different copies of the lock :)

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