segfault calling same function from two other functions (now reduced)

[grahame]

Hi everyone

I've tried for a couple of hours to reduce a segfault I'm seeing in pure rust code, but I can't manage it.

I'm compiling these files together:
https://raw.github.com/grahame/rust-csv/master/csv.rc
https://raw.github.com/grahame/rust-csv/master/csv.rs
https://raw.github.com/grahame/limerick/master/sim.rs

Then running the program, eg:
./sim data
where data is a directory containing a gtfs dataset, eg.
http://www.transperth.wa.gov.au/TimetablePDFs/GoogleTransit/google_transit.zip

I'm seeing a segfault in the no_overwrite function (sim.rs):

fn no_overwrite<T: copy, U: copy>(m: map::hashmap<T, U>, k: T, v: U) {
    //log(error, (k, v));
    let ck = k;
    let cv = v;
    m.insert(ck, cv);
}

but only if I remove the "let ck" and "let cv" lines, and just use k and v directly. Those lines fix up the crash if present, as does chucking in a log(error, (k, v));.

A traceback on my mac (using rust 1d7d5c1):

rustc -g -L ../rust-csv/ ../rust-csv/csv.rc
rustc -g -L ../rust-csv/ sim.rs
(gdb) r ./data
Starting program: /Users/grahame/code/limerick/sim ./data
Reading symbols for shared libraries ...+................................................................. done
loading file: agency.txt
loading file: stops.txt
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000001
[Switching to process 10651 thread 0x1f03]
0x0000000100004080 in glue_take10 ()
(gdb) bt
#0  0x0000000100004080 in glue_take10 ()
#1  0x0000000100516b00 in ?? ()
#2  0x00000001000130fd in glue_take1407 ()
#3  0x000000010000f333 in insert () at sim.rs:1
#4  0x0000000100028b85 in __morestack ()
Previous frame inner to this frame (gdb could not unwind past this frame)

[marijnh]

The csv.rs you linked doesn't have a rowaccess in it, which the sim.rs you linked refers to.

[grahame]

Sorry Marijn, I forgot to do a push of the limerick project. I've just done it, the rev f067e505a661f030e6d48caa955a7a5eb34e0f3b of limerick and rev eea5be3dd67057bb803c2028860c5afe07be6288 of rust-csv will segfault.

[grahame]

Managed to reduce this; compile with rust 851fde8

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

type map1 = map::hashmap<str, @t>;
type map2 = map::hashmap<str, ~t>;

type t = {
    s: str
};

fn main(args: [str])
{
    fn nover<T: copy, U: copy>(m: map::hashmap<T, U>, k: T, v: U) {
        if ! m.insert(k, v) {
            fail;
        }
    }

    fn f1(m: map1) {
        nover(m, "x", @{
            s: "pq"
        });
    };

    fn f2(m: map2) {
        nover(m, "27", ~{
            s : "blah"
        });
    };

    let m : map2 = map::str_hash();
    f2(m);
}

On my system (MacOS Lion, x86_64):

herugrim::~/code/limerick $ rustc -g bug.rs      
bug.rs:12:0: 34:1 warning: unused variable args
bug.rs:12 fn main(args: [str])
bug.rs:13 {
bug.rs:14     fn nover<T: copy, U: copy>(m: map::hashmap<T, U>, k: T, v: U) {
bug.rs:15         if ! m.insert(k, v) {
bug.rs:16             fail;
bug.rs:17         }
          ...
herugrim::~/code/limerick $ gdb ./bug      
GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
Reading symbols for shared libraries .. done

(gdb) b malloc_error_break
Function "malloc_error_break" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (malloc_error_break) pending.
(gdb) run
Starting program: /Users/grahame/code/limerick/bug 
Reading symbols for shared libraries ..+................................................................. done
Breakpoint 1 at 0x7fff97c6b6c0
Pending breakpoint 1 - "malloc_error_break" resolved
bug(2167,0x10061a000) malloc: *** error for object 0x1004146b1: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[Switching to process 2167 thread 0x1a03]

Breakpoint 1, 0x00007fff97c6b6c0 in malloc_error_break ()
(gdb) bt
#0  0x00007fff97c6b6c0 in malloc_error_break ()
#1  0x00007fff97c6b805 in free ()
#2  0x000000010036ab06 in __morestack () at rust_task.cpp:1327
#3  0x000000010035b5fe in rust_task::call_on_c_stack (this=0x10100a000, 
    args=0x10100f730, fn_ptr=0x10035d0b0) at rust_task.h:352
#4  0x000000010035d088 in upcall_shared_free (ptr=0x1007dfeb8)
    at rust_upcall.cpp:50
#5  0x0000000100003617 in glue_free80 ()
#6  0x0000000100003780 in glue_drop118 ()
#7  0x0000000100006875 in glue_drop542 ()
#8  0x0000000100006af7 in glue_free567 ()
#9  0x0000000100006a63 in f2 () at bug.rs:28
#10 0x00000001000011d7 in main () at bug.rs:33
#11 0x0000000100001292 in _rust_main ()
#12 0x000000010035b0d5 in task_start_wrapper (a=0x1004146b1)
    at rust_task.cpp:141

The bug goes away if I comment out the entirety of f1; which isn't called! Odd one.

[brson]

Also, if you swap the order of f1 and f2 it works. That makes me think it has to do with incorrectly reusing monomorphised functions.

[brson]

If I modify make_mono_id to always return precise_param_ids it seems to work.

[brson]

@marijnh I believe this has something to do with type_use

[marijnh]

You're probably right. I'll look into this when I get back from vacation.