Yu Ding

I think panic.rs and panicking.rs is not doing well with panic info, and the [`downcast_ref`](https://github.com/baidu/rust-sgx-sdk/blob/abde31d5c0ab9dbdee9b5250ae941d7d07d9a868/sgx_tstd/src/panicking.rs#L96) failed twice. rust-stable branch works well. Need more time on panicking.rs

And I'm able to reproduce the bug. Let me see.

@elichai Confused. I enabled the `backtrace` feature by editing enclave/Cargo.toml: ```diff -sgx_tstd = { git = "https://github.com/baidu/rust-sgx-sdk.git", rev = "v1.0.7" } +sgx_tstd = { git = "https://github.com/baidu/rust-sgx-sdk.git", rev = "v1.0.7",...

https://github.com/intel/linux-sgx/blob/1248fc21c64467c2a8e8a126d5ea6c69f05d490b/sdk/tlibc/stdlib/malloc.c#L541 Intel makes the alignment `8` instead of traditional x86_64 default `16`. So it breaks the logic of sgx_alloc. Fixed in f99c9bc98c0fb700e14bed1b7fb771bff9a201c4. I can run your code now!

looking into the wrong panic info (but correct line number) probem now.

yeah i think this is the problem. and i can confirm that sgx_alloc should be the only global allocator in this environment as long as it compiles. So i think...

and i have to add more tests for alignment-critical crates — such as crates as hashbrown, ring, other stuffs related to sse or avx instructions. and more tests against low-level...

Fixed in 2940370a34db11e2c9b7956ffd0e3d14ee9f1cf2

Let me create a new release today with tag = v1.0.8. :-) Sorry for the waiting

@elichai rls seems getting back from failed state on 05-19, so it'll be ready on toolchain nightly-2019-05-20. nightly-2019-05-20 is not ready to download now but may be ready in hours...