Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
grahame opened this issue Mar 25, 2012 · 7 comments
Closed

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

grahame opened this issue Mar 25, 2012 · 7 comments
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@grahame
Copy link
Contributor

grahame commented Mar 25, 2012

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
Copy link
Contributor

marijnh commented Mar 26, 2012

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

@grahame
Copy link
Contributor Author

grahame commented Mar 26, 2012

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
Copy link
Contributor Author

grahame commented Apr 5, 2012

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
Copy link
Contributor

brson commented Apr 8, 2012

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
Copy link
Contributor

brson commented Apr 8, 2012

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

@brson
Copy link
Contributor

brson commented Apr 8, 2012

@marijnh I believe this has something to do with type_use

@ghost ghost assigned marijnh Apr 9, 2012
@marijnh
Copy link
Contributor

marijnh commented Apr 9, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@marijnh @brson @grahame