This is a quote from my program:
dbg!(1);
let temp: Result<ExtractedRet, crate::parse::ParseError> = myfunc(
ty_kind,
potential_id,
ty,
location,
parent_id,
ctx,
canonical_ty,
&mut name,
&cursor);
dbg!(2);
dbg!(3);
if cond {
panic!();
}
The output is:
...
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1312] 1 = 1
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1312] 1 = 1
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1323] 2 = 2
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1324] 3 = 3
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1323] 2 = 2
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1324] 3 = 3
thread 'main' panicked at 'explicit panic', /home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1342:13
It seems like, the second dbg!(1) gets executed at the wrong time.rustc 1.50.0-nightly (1c389ffef 2020-11-24)
bjorn3
December 10, 2020, 11:01am
2
Are you using multiple threads? If so the output of multiple threads gets interleaved.
It doesn't seem so.
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1312] std::thread::current().id() = ThreadId(
1,
)
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1312] std::thread::current().id() = ThreadId(
1,
)
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1323] std::thread::current().id() = ThreadId(
1,
)
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1324] std::thread::current().id() = ThreadId(
1,
)
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1323] std::thread::current().id() = ThreadId(
1,
)
[/home/volker/Sync/git/rust-bindgen/src/ir/ty.rs:1324] std::thread::current().id() = ThreadId(
1,
)
bjorn3
December 10, 2020, 11:08am
4
Can you share the full code? That would allow others to reproduce the problem and locally debug it.
How to reproduce:
$ git clone https://github.com/Volker-Weissmann/rust-bindgen
$ cd rust-bindgen
$ git checkout compiler_bug
$ cd safe_wrappers
$ cargo build
...
Compiling safe_wrappers v0.1.0 (/home/volker/rust-bindgen/safe_wrappers)
error: failed to run custom build command for `safe_wrappers v0.1.0 (/home/volker/rust-bindgen/safe_wrappers)`
Caused by:
process didn't exit successfully: `/home/volker/rust-bindgen/safe_wrappers/target/debug/build/safe_wrappers-7bcb4c7d6e0ccb09/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=example.cpp
--- stderr
[/home/volker/rust-bindgen/src/ir/context.rs:561] &translation_unit = TranslationUnit { }
[/home/volker/rust-bindgen/src/ir/context.rs:561] &index = Index { }
[/home/volker/rust-bindgen/src/ir/ty.rs:1312] 1 = 1
[/home/volker/rust-bindgen/src/ir/ty.rs:1312] 1 = 1
[/home/volker/rust-bindgen/src/ir/ty.rs:1323] 2 = 2
[/home/volker/rust-bindgen/src/ir/ty.rs:1324] 3 = 3
[/home/volker/rust-bindgen/src/ir/ty.rs:1323] 2 = 2
[/home/volker/rust-bindgen/src/ir/ty.rs:1324] 3 = 3
thread 'main' panicked at 'explicit panic', /home/volker/rust-bindgen/src/ir/ty.rs:1342:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
bjorn3
December 10, 2020, 11:22am
6
safe_wrappers is not compiled at all for me:
$ git clone https://github.com/Volker-Weissmann/rust-bindgen --branch compiler_bug
$ rust-bindgen
$ cargo build
Downloaded peeking_take_while v0.1.2
Downloaded which v3.1.1
Downloaded clang-sys v1.0.1
Downloaded nom v5.1.2
Downloaded cexpr v0.4.0
Downloaded 5 crates (204.8 KB) in 0.46s
Compiling libc v0.2.80
Compiling memchr v2.3.4
Compiling glob v0.3.0
Compiling version_check v0.9.2
Compiling proc-macro2 v1.0.24
Compiling log v0.4.11
Compiling lazy_static v1.4.0
Compiling bitflags v1.2.1
Compiling regex-syntax v0.6.21
Compiling cfg-if v1.0.0
Compiling cfg-if v0.1.10
Compiling unicode-width v0.1.8
Compiling unicode-xid v0.2.1
Compiling strsim v0.8.0
Compiling termcolor v1.1.0
Compiling vec_map v0.8.2
Compiling humantime v2.0.1
Compiling ansi_term v0.11.0
Compiling bindgen v0.55.1 (/tmp/rust-bindgen)
Compiling rustc-hash v1.1.0
Compiling peeking_take_while v0.1.2
Compiling lazycell v1.3.0
Compiling shlex v0.1.1
Compiling nom v5.1.2
Compiling thread_local v1.0.1
Compiling clang-sys v1.0.1
Compiling libloading v0.6.5
Compiling textwrap v0.11.0
Compiling aho-corasick v0.7.15
Compiling atty v0.2.14
Compiling which v3.1.1
Compiling quote v1.0.7
Compiling clap v2.33.3
Compiling regex v1.4.2
Compiling cexpr v0.4.0
Compiling env_logger v0.8.1
warning: unreachable statement
--> src/ir/ty.rs:1294:13
|
1293 | panic!();
| --------- any code following this expression is unreachable
1294 | dbg!();
| ^^^^^^^ unreachable statement
|
= note: `#[warn(unreachable_code)]` on by default
= note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
warning: unused variable: `temp`
--> src/ir/ty.rs:1313:13
|
1313 | let temp: Result<ExtractedRet, crate::parse::ParseError> = myfunc(
| ^^^^ help: if this is intentional, prefix it with an underscore: `_temp`
|
= note: `#[warn(unused_variables)]` on by default
warning: variable does not need to be mutable
--> src/ir/ty.rs:1290:13
|
1290 | let mut kind = if location.kind() == CXCursor_TemplateRef ||
| ----^^^^
| |
| help: remove this `mut`
|
= note: `#[warn(unused_mut)]` on by default
warning: 3 warnings emitted
Finished dev [unoptimized + debuginfo] target(s) in 55.55s
The dbg!(1), dbg!(2), dbg!(3) code gets called from safe_wrappers/build.rs
if cond {
panic!();
}
part.
bjorn3
December 10, 2020, 11:27am
8
Safe_wrappers isn't compiled at all for me, so it can't result in an error.
You need to cd into safe_wrappers before running cargo build.
bjorn3
December 10, 2020, 11:30am
10
Ah, I can reproduce it now.
bjorn3
December 10, 2020, 11:56am
11
Single stepping shows that it goes from dbg!(1) to myfunc to dbg!(1). The only thing I can think of is that there must be a bug in unsafe code causing corruption.
The program uses both unsafe rust code and external C++ code.
bjorn3
December 10, 2020, 12:14pm
13
Not sure. All corruption I had to debug was either in simple C++ programs or caused by miscompilations by cg_clif. In the former case it has been easy to find the problem with a debugger. In the later case I have been removing code piece by piece and have been continuously cross checking that it works fine using cg_llvm. In this case the corruption is very likely a problem with the code itself, so cross checking against cg_clif and cg_llvm won't help and changing the code may introduce new problems that didn't exist in the original program.
If you follow the call graph myfunc may call from_clang_ty. So maybe when from_clang_ty is first called something like this happens:
dbg!(1)call to myfunc
call to from_clang_ty
dbg!(1)call to myfunc
doesn't call from_clang_ty and returns
dbg!(2)dbg!(3)
cond is false, so it doesn't panic
return
return
dbg!(2)dbg!(3)
cond is true and it panics
You are right, how did I overlook that
system
March 10, 2021, 12:28pm
16
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.
