On 09/14/2013 02:57 AM, Daniel Micay wrote:
On Fri, Sep 13, 2013 at 1:17 AM, Minh Do <[email protected]
<mailto:[email protected]>> wrote:
On 08/27/2013 12:43 AM, Minh Do wrote:
My name is Do Nhat Minh, currently a final year Computer
Science student at Nanyang Technological University in
Singapore. I have played with Rust and found the experience to
be very pleasant. I think Rust make sensible trade-offs and
managed to stay small, compared to C++.
I have been granted permission by my university supervisor to
work on rusti as my final year project. I hope with this
contribution, Rust will be even stronger a competitor to Go and D.
This will be my first time working on something this size and
this long a duration. I would love to hear your advice or
experience implementing rusti.
Thank you for your time.
Regards,
Minh
Hi,
I'm working on figuring out why rusti segfaults. So far, I'm able
to extract very little information.
Attached is a backtrace from rusti using gdb. SIGSEGV is signaled
inside jemalloc's tcache_alloc_easy, line 286. Below is the piece
code where it fails.
274 JEMALLOC_ALWAYS_INLINE void *
275 tcache_alloc_easy(tcache_bin_t *tbin)
276 {
277 void *ret;
278
279 if (tbin->ncached == 0) {
280 tbin->low_water = -1;
281 return (NULL);
282 }
283 tbin->ncached--;
284 if ((int)tbin->ncached < tbin->low_water)
285 tbin->low_water = tbin->ncached;
286 ret = tbin->avail[tbin->ncached]; // <- XXX fail here
287 return (ret);
288 }
jemalloc is trying to read from tbin->avail at tbin->ncached.
tbin->ncached was 1227353920 (or 0x4927ef40) which is too big in
my opinion. All the other values in tbin were unusually high or
low, which leads me to suspect tbin is uninitialized or there is a
memory overrun.
I run valgrind on rusti in the hope of catching memory overruns,
but it does not help much. Valgrind only prints some warning about
conditional jumps depending on uninitialized variables and then
reports an invalid read with the identical backtrace. However, at
the top, valgrind prints the below text, which I find quite
interesting.
==31583== Syscall param read(buf) points to unaddressable byte(s)
==31583== at 0x40170C7: read (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x400586C: open_verify (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x4005CA6: open_path (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x4008495: _dl_map_object (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x400C281: openaux (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x400E773: _dl_catch_error (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x400C4E4: _dl_map_object_deps (in
/usr/lib/ld-2.18.so <http://ld-2.18.so>)
==31583== by 0x4002E93: dl_main (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x4015174: _dl_sysdep_start (in
/usr/lib/ld-2.18.so <http://ld-2.18.so>)
==31583== by 0x4004AE5: _dl_start (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== by 0x4001277: ??? (in /usr/lib/ld-2.18.so
<http://ld-2.18.so>)
==31583== Address 0x7fec7f700 is on thread 1's stack
I then try linking directly with Rust's libstd (since it's the
first thing that's linked with the code being compiled) in rusti's
main() before anything is done. Below is the addition.
diff --git a/src/librusti/rusti.rs <http://rusti.rs>
b/src/librusti/rusti.rs <http://rusti.rs>
index 8d61a97..2f72cfa 100644
--- a/src/librusti/rusti.rs <http://rusti.rs>
+++ b/src/librusti/rusti.rs <http://rusti.rs>
@@ -84,6 +84,9 @@ use syntax::print::pprust;
use program::Program;
use utils::*;
+use rustc::lib::llvm::llvm;
+use std::unstable::intrinsics;
+
mod program;
pub mod utils;
@@ -505,6 +508,17 @@ pub fn main() {
pub fn main_args(args: &[~str]) {
#[fixed_stack_segment]; #[inline(never)];
+ unsafe {
+ let manager =
llvm::LLVMRustPrepareJIT(intrinsics::morestack_addr());
+ let path =
"/path/to/rust/x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-6c65cf4b443341b1-0.8-pre.so
<http://libstd-6c65cf4b443341b1-0.8-pre.so>";
+ do path.with_c_str |buf_t| {
+ if !llvm::LLVMRustLoadCrate(manager, buf_t) {
+ debug!(~"Could not link");
+ }
+ debug!("linked: %s", path);
+ }
+ }
+
let input = io::stdin();
let out = io::stdout();
let mut repl = Repl {
Rusti now also fails in the scheduler sometimes if it happens to
switch threads while LLVMRustLoadCrate is being executed. Below is
the backtrace.
#0 rust_thread_start (ptr=0x7ffff1c1f5e0) at
src/rt/sync/rust_thread.cpp:36
#1 0x00007ffff548b0a2 in start_thread () from
/usr/lib/libpthread.so.0
#2 0x00007ffff3217a2d in clone () from /usr/lib/libc.so.6
The above failure in the scheduler and the curious message by
valgrind makes me wonder about the scheduler and the runtime.
However, when git grep-ing for rust_thread, I don't see how it is
hooked into Rust. Could someone enlighten me on this?
More importantly, does anyone have any suggestion about my
approach or any leads on this?
Regards,
Minh
Compile jemalloc with --enable-debug (you can add it to rt.mk
<http://rt.mk>) and it will check for things like double-free.
Hi Daniel,
Below is how I added --enable-debug to rt.mk. However, I don't see any
debug messages printed out. Could you please tell me how I can make
jemalloc print out debug messages?
diff --git a/mk/rt.mk b/mk/rt.mk
index e31f222..69fc6ce 100644
--- a/mk/rt.mk
+++ b/mk/rt.mk
@@ -220,7 +220,7 @@ endif
ifeq ($(OSTYPE_$(1)), linux-androideabi)
$$(JEMALLOC_LIB_$(1)_$(2)):
cd $$(RT_BUILD_DIR_$(1)_$(2))/jemalloc;
$(S)src/rt/jemalloc/configure \
- --disable-experimental --build=$(CFG_BUILD_TRIPLE)
--host=$(1) --disable-tls \
+ --enable-debug --disable-experimental
--build=$(CFG_BUILD_TRIPLE) --host=$(1) --disable-tls \
EXTRA_CFLAGS="$$(CFG_GCCISH_CFLAGS)
$$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)" \
LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS)
$$(LIBUV_FLAGS_$$(HOST_$(1)))" \
CC="$$(CC_$(1))" \
@@ -230,7 +230,7 @@ $$(JEMALLOC_LIB_$(1)_$(2)):
else
$$(JEMALLOC_LIB_$(1)_$(2)):
cd $$(RT_BUILD_DIR_$(1)_$(2))/jemalloc;
$(S)src/rt/jemalloc/configure \
- --disable-experimental --build=$(CFG_BUILD_TRIPLE)
--host=$(1) \
+ --enable-debug --disable-experimental
--build=$(CFG_BUILD_TRIPLE) --host=$(1) \
EXTRA_CFLAGS="$$(CFG_GCCISH_CFLAGS)
$$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)" \
LDFLAGS="$$(CFG_GCCISH_LINK_FLAGS)
$$(LIBUV_FLAGS_$$(HOST_$(1)))" \
CC="$$(CC_$(1))" \
Regards,
Minh
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
