Skip to content
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.

Sign up for GitHub

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

Jump to bottom

QEMU issues #2

Closed
2 of 4 tasks
japaric opened this issue Aug 8, 2016 · 7 comments
Closed
2 of 4 tasks

QEMU issues #2

japaric opened this issue Aug 8, 2016 · 7 comments

Comments

@japaric
Copy link
Member

japaric commented Aug 8, 2016 •
edited
Loading

Update

Trying to run the test suite on QEMU for some targets crashes QEMU

I'm not quite sure what's the exact problem for each target but some possible causes:

  • The std binaries for the target are "broken". Most likely, some C binding in libc is wrong.
  • We are using the wrong QEMU variant (qemu-ppc64le).
  • "Just" a problem with multithreading. This leads to sporadic failures.

In some cases, using QEMU's system emulation instead of user emulation might fix the problem.

Example.

Emphasis on sometimes. This is weird because (a) as of e5ab308, the test suite is deterministic and (b) I'm using RUST_TEST_THREADS=1 to "prevent" multithreading (QEMU is known to have problems handling multiple threads) but I guess this last part is impossible because detecting a panic requires at least two threads.
@Amanieu
Copy link
Member

Amanieu commented Aug 8, 2016

Yes, that looks like qemu-user is failing due to threads. There's not much you can do about it. One way to solve it would be to use qemu-system-arm instead and run the tests in a full VM (though you can probably get away with just the kernel and running the test with init=/test, in which case all you need is a kernel image).

@japaric
Copy link
Member Author

japaric commented Aug 8, 2016

@Amanieu Thanks for taking a peek.

Yes, that looks like qemu-user is failing due to threads.

What I feared. 🙀

One way to solve it would be to use qemu-system-arm instead and run the tests in a full VM

Sounds annoying. Know of any place where I can get an ARM kernel image? For the rootfs I think I can use one of ubuntu-core's.

though you can probably get away with just the kernel and running the test with init=/test, in which case all you need is a kernel image

Hmm, I'm not sure. The test binary is dynamically linked and depends on libc and other C libraries.

@Amanieu
Copy link
Member

Amanieu commented Aug 8, 2016

This might be helpful.

@japaric japaric changed the title QEMU sometimes crashes when running tests for armv7-unknown-linux-gnueabihf QEMU issues Aug 9, 2016
japaric pushed a commit that referenced this issue Aug 9, 2016
don't run tests on targets that have QEMU issues
83d5ee8 
cc #2
japaric pushed a commit that referenced this issue Aug 9, 2016
don't run tests on targets that have QEMU issues
09935e2 
cc #2
@japaric japaric mentioned this issue Aug 9, 2016
Merged
@japaric
Copy link
Member Author

japaric commented Aug 10, 2016

mips-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu

QEMU for these three targets appears to be flat out broken. Even this simple program causes a segfault when executed with QEMU for these targets:

int main() { return 0; }

This issue have been reported upstream but there has been no action. Also, someone claims that the 32-bit version of qemu-$TARGET doesn't segfault on amd64. Might try that.

@japaric
Copy link
Member Author

japaric commented Aug 10, 2016

Also, someone claims that the 32-bit version of qemu-$TARGET doesn't segfault on amd64. Might try that.

And, weirdly enough, it actually works! At least on MIPS. Will send a PR.

japaric pushed a commit that referenced this issue Aug 10, 2016
mips: run test on 32-bit QEMU
67ed0e4 
cc #2
@japaric japaric mentioned this issue Aug 10, 2016
Merged
@japaric
Copy link
Member Author

japaric commented Aug 10, 2016

And, weirdly enough, it actually works! At least on MIPS. Will send a PR.

Fixed the mips and ppc64 targets. The trick didn't work on the ppc64le target.

@japaric
Copy link
Member Author

japaric commented Aug 13, 2016

Switching Travis to exclusively use Docker (Ubuntu 16.04) fixed the flakiness of the ARM targets. The ppc64le target still doesn't work (QEMU appears to be busted) but I'm OK with that; we got 16 of 17 targets working so I'm gonna close this.

@japaric japaric closed this as completed Aug 13, 2016
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 23, 2019
@da-x
Add CFI information to __rust_probestack
41ddb18 
In order for GDB to correctly backtrace a stack overflow, it needs
CFI information in __rust_probestack.

This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 23, 2019
@da-x
Add CFI information to __rust_probestack
e4322b4 
In order for GDB to correctly backtrace a stack overflow, it needs
CFI information in __rust_probestack.

This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 23, 2019
@da-x
Add CFI information to __rust_probestack
48a8722 
In order for GDB to correctly backtrace a stack overflow, it needs
CFI information in __rust_probestack.

This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 23, 2019
@da-x
Add CFI information to __rust_probestack
a7e6876 
In order for GDB to correctly backtrace a stack overflow, it needs
CFI information in __rust_probestack.

This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 23, 2019
@da-x
Add CFI information to __rust_probestack
e67619c 
In order for GDB to correctly backtrace a stack overflow, it needs
CFI information in __rust_probestack.

This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 23, 2019
@da-x
Add CFI information to __rust_probestack
e32930d 
In order for GDB to correctly backtrace a stack overflow, it needs
CFI information in __rust_probestack.

This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 24, 2019
@da-x
probestack: add frame pointers for easier traceback
7c3243f 
This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
da-x added a commit to da-x/compiler-builtins that referenced this issue Jul 24, 2019
@da-x
probestack: add frame pointers for easier traceback
985a430 
This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 rust-lang#1  0x00005555555595ba in test::main ()
 rust-lang#2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 rust-lang#3  0x0000555555561ae3 in std::panicking::try::do_call ()
 rust-lang#4  0x000055555556595a in __rust_maybe_catch_panic ()
 rust-lang#5  0x000055555555af9b in std::rt::lang_start_internal ()
 rust-lang#6  0x00005555555594d5 in std::rt::lang_start ()
 rust-lang#7  0x000055555555977b in main ()
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Amanieu @japaric