Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

test_port in run-pass/binops.rs causes valgrind warnings from shape_glue #2724

Closed
msullivan opened this issue Jun 26, 2012 · 5 comments
Closed

test_port in run-pass/binops.rs causes valgrind warnings from shape_glue #2724

msullivan opened this issue Jun 26, 2012 · 5 comments
Labels
A-codegen Area: Code generation A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Milestone
0.5

Comments

@msullivan
Copy link
Contributor

On my system, it produces:

==25913== Thread 3:
==25913== Conditional jump or move depends on uninitialised value(s)
==25913==    at 0x5876323: shape::cmp::walk_res2(shape::rust_fn const*, unsigned char const*) (rust_shape.cpp:220)
==25913==    by 0x587A181: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk() (rust_shape.h:954)
==25913==    by 0x587A674: shape::data<shape::cmp, shape::ptr_pair>::walk_box_contents1() (rust_shape.cpp:188)
==25913==    by 0x587A6E4: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk_box0() (rust_shape.cpp:282)
==25913==    by 0x587A1EC: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk() (rust_shape.h:306)
==25913==    by 0x5876F30: shape::cmp::walk_variant2(shape::tag_info&, unsigned long, std::pair<unsigned char const*, unsigned char const*>) (rust_shape.cpp:371)
==25913==    by 0x5876FB7: shape::cmp::walk_tag2(shape::tag_info&, shape::data_pair<unsigned long> const&) (rust_shape.h:1010)
==25913==    by 0x5879B88: shape::data<shape::cmp, shape::ptr_pair>::walk_tag1(shape::tag_info&) (rust_shape.h:1124)
==25913==    by 0x5879CA9: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk_tag0() (rust_shape.h:415)
==25913==    by 0x587A034: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk() (rust_shape.h:305)
==25913==    by 0x5876DC8: shape_cmp_type (rust_shape.cpp:494)
==25913==    by 0x588056C: ??? (in /home/sully/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so)
==25913== 
==25913== Conditional jump or move depends on uninitialised value(s)
==25913==    at 0x5876330: shape::cmp::walk_res2(shape::rust_fn const*, unsigned char const*) (rust_shape.cpp:209)
==25913==    by 0x587A181: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk() (rust_shape.h:954)
==25913==    by 0x587A674: shape::data<shape::cmp, shape::ptr_pair>::walk_box_contents1() (rust_shape.cpp:188)
==25913==    by 0x587A6E4: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk_box0() (rust_shape.cpp:282)
==25913==    by 0x587A1EC: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk() (rust_shape.h:306)
==25913==    by 0x5876F30: shape::cmp::walk_variant2(shape::tag_info&, unsigned long, std::pair<unsigned char const*, unsigned char const*>) (rust_shape.cpp:371)
==25913==    by 0x5876FB7: shape::cmp::walk_tag2(shape::tag_info&, shape::data_pair<unsigned long> const&) (rust_shape.h:1010)
==25913==    by 0x5879B88: shape::data<shape::cmp, shape::ptr_pair>::walk_tag1(shape::tag_info&) (rust_shape.h:1124)
==25913==    by 0x5879CA9: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk_tag0() (rust_shape.h:415)
==25913==    by 0x587A034: shape::ctxt<shape::data<shape::cmp, shape::ptr_pair> >::walk() (rust_shape.h:305)
==25913==    by 0x5876DC8: shape_cmp_type (rust_shape.cpp:494)
==25913==    by 0x588056C: ??? (in /home/sully/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so)
==25913==

I am commenting out the call to the test_class function and putting in a FIXME that points to this bug.
msullivan added a commit that referenced this issue Jun 26, 2012
@msullivan
Comment out a failing part of a test; this is Issue #2724.
fb018fa
msullivan added a commit that referenced this issue Jun 26, 2012
@msullivan
Comment out the *right* part of the test failing due to issue #2724.
1c5e2ca
@msullivan
Copy link
Contributor Author

Oops. It was actually the test_port function causing the problems.

@ghost ghost assigned catamorphism Jun 26, 2012
@catamorphism
Copy link
Contributor

I think I've narrowed down the problem to the code in trans that handles class constructors, which created an 8-bit field within a 64-bit struct field and left three uninitialized bytes (plus, my dodgy shape code for resources wasn't properly skipping over that field (the "drop field"), and was comparing it instead of the actual pointer to the object). Working on a fix.

For future reference, the --track-origins=yes flag to valgrind will actually pinpoint where the uninitialized value was created. Wish I'd known that before I wasted hours barking up the wrong tree :-D

@catamorphism
Copy link
Contributor

I've been working on this, but right now the cycle collector is crashing and I'm not sure I'm getting accurate information from gdb about where. Going to put it aside for a bit, but if someone who knows the RTS better wants to help...

@catamorphism catamorphism mentioned this issue Jul 9, 2012
Closed
@catamorphism
Copy link
Contributor

Since both shape glue and classes as we know them are supposedly going away, I'm calling this "postponed".

@catamorphism
Copy link
Contributor

I guess this is no longer relevant since comparison ops are now trait-based. binops.rs no longer has a test_port function. Closing.

bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
@scampi
exit integration test successfully if the crate build failed before a…
81a1d46 
…pplying rustfmt

The `cargo test --all` command failed and exited the main process with a
SIGINT. Trapping the signal or trying to get the code of a subshell
didn't work.

Close rust-lang#2724
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@JustusAdam @zhassan-aws
Support for inductively verifying contracts of recursive functions (r…
2d32361 
…ust-lang#2809)

This adds support for verifying the contracts of recursive functions
inductively.

The idea is quite simple. We use a global variable to track whether
we're reentering a function and depending on that value we either
continue with checking the contract or assume the hypothesis by using
its replacement.

The precise mechanism that I implemented is explained in the
documentation
[here](https://github.com/JustusAdam/kani/blob/a31176c79098205ca0b2c2b199cdf06653754551/library/kani_macros/src/sysroot/contracts.rs#L126)

Resolves rust-lang#2724 

**Open Question:** to facilitate induction the return type of the
function must implement `kani::Arbitrary`. Since we can't discriminate
between recursive and non-recursive functions in the proc-macro this
means that this applies to all functions with contracts, not just
recursive ones. This may be an unacceptable restriction. We could
consider making inductive verification explicit with an annotation like
`#[kani::inductive]` or conversely make inductive the default and let
users opt-out with `#[kani::no_inductive]`. This is now tracked in rust-lang#2823

I had to remove the names of the functions in which the messages occur
in the test cases, since they are now generated, hard to read names

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.

---------

Co-authored-by: Zyad Hassan <88045115+zhassan-aws@users.noreply.github.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Milestone
0.5
Development

No branches or pull requests
2 participants
@msullivan @catamorphism