segfault in hash access (possibly alias analysis)

[grahame]

Checkout http://github.com/grahame/limerick/

make
wget http://www.transperth.wa.gov.au/TimetablePDFs/GoogleTransit/google_transit.zip
mkdir data && cd data && unzip ../google_transit.zip
cd ..
gdb ./feedinfo
(gdb) run ./data
Starting program: /Users/grahame/code/limerick/feedinfo ./data
Reading symbols for shared libraries .....+................................................................ done
loading file: ./data/agency.txt

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000020
[Switching to process 95567 thread 0x1c03]
0x00000001000162bc in str::hash::_f0ffd86f4899f548::_02 ()
(gdb) bt
#0  0x00000001000162bc in str::hash::_f0ffd86f4899f548::_02 ()
#1  0x0000000100820e60 in ?? ()
#2  0x00000001004b17cf in gtfs_load::no_overwrite944::_82e59d78a8472226::_01 ()
#3  0x00000001004b143b in gtfs_load::load_agencies::anon ()
#4  0x00000001004b0e29 in gtfs_load::file_iter::anon ()
#5  0x0000000100489244 in rowiter::meth89::iter::_3cf1bd4f7d58a1ce::_02 ()
#6  0x00000001004b0a1d in gtfs_load::file_iter::_fcad8389d2eb128e::_01 ()
#7  0x00000001004c4f9c in __morestack ()
Previous frame inner to this frame (gdb could not unwind past this frame)

With rust 77c470d on a x86_64 MacOS 10.7.4 system.
Latest master of limerick.

[catamorphism]

I was able to reproduce this with Rust 77c470d -- I got the segfault compiling the code unmodified, but if I changed the signature for no_overwrite to:

    fn no_overwrite<T: copy, U: copy>(m: map::hashmap<T, U>, +k: T, v: U) {

I didn't see the segfault (I got the output saying it was loading some data, then it ran for a long time or went into a loop, not sure which). Also, the code that calls no_overwrite here -- in load_agencies looks very much like the offending code in #2633 (particularly, that row_id gets passed as an argument to no_overwrite as well as being a field in a record that's passed to no_overwrite). So I'm going to assume this is another instance of #2584 and that it's therefore fixed in Rust HEAD. (I can't verify that because the code doesn't compile in HEAD, for other reasons.)

Reopen if that's not so!