Skip to content

SIGSEGV matching a struct-like enum in a macro #9049

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.

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

Closed
sfackler opened this issue Sep 8, 2013 · 8 comments
Closed

SIGSEGV matching a struct-like enum in a macro #9049

sfackler opened this issue Sep 8, 2013 · 8 comments
Labels
I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@sfackler
Copy link
Member

sfackler commented Sep 8, 2013

enum Foo {
    A { a: int },
    B { b: int, bb: int },
}

macro_rules! thingy2(
    () => (
        match B { b: 10, bb: 10 } {
            A { a } => println!("{}", a),
            B { b, bb } => println!("{} {}", b, bb),
        }
    )
)

fn main() {
    thingy2!()
}
~ ❯ rustc -Z debug-info test.rs
~ ❯ gdb test
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
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) r
Starting program: /Users/sfackler/test
Reading symbols for shared libraries ..+................................................................. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000001
[Switching to process 59143 thread 0x40b]
0x000000010000171f in main () at <std-macros>:291
291 <std-macros>: No such file or directory.
    in <std-macros>

If I change Foo to

enum Foo {
    A(int),
    B(int, int)
}

The program works as expected. Manually expanding the macro invocation also causes the program to work correctly.

@sfackler
Copy link
Member Author

sfackler commented Sep 8, 2013

This regressed in the last day or two.

@sfackler
Copy link
Member Author

sfackler commented Sep 8, 2013

#9026 caused this. The program above runs fine if 124eb21 is reverted.

sfackler added a commit to sfackler/rust-postgres that referenced this issue Sep 9, 2013
Workaround for rust-lang/rust#9049 but probably the right thing to do in
any case.
@jbclements
Copy link
Contributor

goodness... there's something really freaky going on here. I've found a program near this one that actually behaves nondeterministically:

enum Foo {
    A { a: int, aa: int },
    B { b: int, bb: int },
}

macro_rules! thingy2(
    () => (
        match B { b: 10, bb: 10 } {
            A { a , aa} => 13,
            B { b , bb } => 14
        }
    )
)

fn main() {
    println!("{}",thingy2!());
}

It seems to seg fault about 1/5 of the time:

pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
zsh: segmentation fault  ./foo
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
zsh: segmentation fault  ./foo
pcp068341pcs:/tmp clements> 

@jbclements
Copy link
Contributor

BTW, what platform did you observe this on?

@sfackler
Copy link
Member Author

sfackler commented Sep 9, 2013

Both 64 bit Linux and OSX.

@jbclements
Copy link
Contributor

Okay, narrowing down; it looks like the post-patch version is omitting storage into local vars in the LLVM. I'm guessing this is because of an illegal ident comparison. I'd stick the LLVM diff in here but... I don't think it would be helpful to anyone but me.

@jbclements
Copy link
Contributor

okay, I think I've got the fix for this one. Now to add a test case and run make check....

@ghost ghost assigned jbclements Sep 10, 2013
jbclements added a commit to jbclements/rust that referenced this issue Sep 10, 2013
bors added a commit that referenced this issue Sep 10, 2013
This appears to fix issue #9049. It also re-enables the ICE check on comparing idents for equality; it appears that ICEs are better than seg faults.
@jbclements
Copy link
Contributor

apparently fixed by #9090 .

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

No branches or pull requests

2 participants