segfault inserting into a hashmap

[grahame]

Test program:

use std;
import std::map;
import map::hashmap;

type test =  {
    x : str,
    y : str
};

fn main(args: [str]) {
    let t : map::hashmap<str, test> = map::new_str_hash();
    let aa = "goat";
    t.insert(aa,
            { x : "blah", y : "boo" });
    t.insert("budgie",
            { x : aa, y : aa });
    t.insert(aa,
            { x : aa, y : aa });
}

If you compile that and run it on Mac OS, using rust 664d71f I get:

(gdb) r
Starting program: /Users/grahame/code/limerick/test
Reading symbols for shared libraries ..+................................................................. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 37060 thread 0x1e03]
0x000000010001849c in str::hash::_31827ae260e7bf7b ()
(gdb) bt
#0  0x000000010001849c in str::hash::_31827ae260e7bf7b ()
#1  0x0000000100704dd0 in ?? ()
#2  0x000000010011fb6d in map::chained::insert::_6cad5a231a3253ac ()
#3  0x00000001000f67b5 in _ZN3map7chained7hashmap5168726insert17_76e8354b7f8b17bdE ()
#4  0x00000001000014d2 in _ZN4main17_cfc7c565861fc2bfE () at test.rs:19
#5  0x00000001000015f2 in _rust_main ()
#6  0x00000001001d7695 in task_start_wrapper (a=0x100704da0) at rust_task.cpp:184

The problem seems to be that "aa" is being stomped on in the case where it is used for both the key and as part of a struct being inserted.

[brson]

Here's a slightly reduced test case:

use std;
import std::map;
import map::hashmap;

fn main(args: [str]) {
    let t = map::new_str_hash();
    let aa = "g";
    t.insert(aa, {x:aa});
}

[brson]

Here's what valgrind says:

==8818== Thread 9:
==8818== Invalid read of size 8
==8818==    at 0x4E7AC3C: str::hash::_31827ae260e7bf7b (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libcore-14bd852465126fe7-0.1.so)
==8818==    by 0x51F68C4: map::chained::insert::_6cad5a231a3253ac (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-79ca5fac56b63fde-0.1.so)
==8818==    by 0x519FCC5: _ZN3map7chained7hashmap5168726insert17_76e8354b7f8b17bdE (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-79ca5fac56b63fde-0.1.so)
==8818==    by 0x401197: main::_e915de59229b3560 (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/issue-1964.stage1-x86_64-unknown-linux-gnu)
==8818==    by 0x4012F1: _rust_main (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/issue-1964.stage1-x86_64-unknown-linux-gnu)
==8818==    by 0x5754F5A: task_start_wrapper(spawn_args*) (rust_task.cpp:184)
==8818==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8818==
==8818==
==8818== Process terminating with default action of signal 11 (SIGSEGV)
==8818==  Access not within mapped region at address 0x0
==8818==    at 0x4E7AC3C: str::hash::_31827ae260e7bf7b (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libcore-14bd852465126fe7-0.1.so)
==8818==    by 0x51F68C4: map::chained::insert::_6cad5a231a3253ac (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-79ca5fac56b63fde-0.1.so)
==8818==    by 0x519FCC5: _ZN3map7chained7hashmap5168726insert17_76e8354b7f8b17bdE (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd-79ca5fac56b63fde-0.1.so)
==8818==    by 0x401197: main::_e915de59229b3560 (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/issue-1964.stage1-x86_64-unknown-linux-gnu)
==8818==    by 0x4012F1: _rust_main (in /home/banderson/Dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/issue-1964.stage1-x86_64-unknown-linux-gnu)
==8818==    by 0x5754F5A: task_start_wrapper(spawn_args*) (rust_task.cpp:184)
==8818==  If you believe this happened as a result of a stack
==8818==  overflow in your program's main thread (unlikely but
==8818==  possible), you can try to increase the size of the
==8818==  main thread stack using the --main-stacksize= flag.
==8818==  The main thread stack size used in this run was 16777216.

Perhaps rustc thinks that aa is no longer used and deinitializes it.

[brson]

Assigning to @marijnh because I think he'll probably know what's up.