Closed
Description
#![feature(macro_rules)]
macro_rules! call2( ($e:expr) => ($e()) )
macro_rules! call( ($e:expr) => (handle(call2!($e))) )
fn bar() {
unsafe {
*(0 as *mut uint) = 0;
}
}
fn foo() {
call!(bar);
}
fn handle(_:()) {}
fn main() {
foo();
}
$ rustc foo.rs -g
$ gdb ./foo
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...done.
(gdb) r
Starting program: /home/alex/code/foobar/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
main::bar () at src/main.rs:8
8 *(0 as *mut uint) = 0;
(gdb) bt
#0 main::bar () at src/main.rs:8
#1 0x000055555555f32e in main::foo () at src/main.rs:4
#2 0x000055555555f39e in main::main () at src/main.rs:19
#3 0x00005555555950eb in start::closure.8511 ()
#4 0x00005555555acbfc in rust_try_inner ()
#5 0x00005555555acbe6 in rust_try ()
#6 0x00005555555aa533 in unwind::try::hd12740a912640cc1imd ()
#7 0x00005555555aa3fc in task::Task::run::ha62f1c0aea75bedcWBc ()
#8 0x0000555555594f27 in start::h239c3a425c3165f7ehe ()
#9 0x0000555555594d68 in lang_start::hb36b8d7630529d77xge ()
#10 0x000055555555f3ef in main ()
The line number for the stack frame of main::foo
says it's on line 4, when it should actually be lower than that. I have noticed, however, that if there's only one macro (e.g. call2 goes away) the source location is correct. This may be a bug in debuginfo, but it may also be a bug in macros in general (source locations aren't always quite correct I think).
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
michaelwoerister commentedon Mar 26, 2015
Might be related to #23480.
aij commentedon Jul 10, 2015
This bug makes debugging errors returned through
try!
really annoying.huonw commentedon Nov 18, 2015
cc #9232, #17234
jethrogb commentedon Nov 15, 2016
Will this magically get fixed when #23480 is fixed?
jseyfried commentedon Feb 8, 2017
Yeah, this looks like a consequence of #23480 / #39450.
This should be fixed by span reform along the road to declarative macros 2.0.
Arthamys commentedon Aug 17, 2019
This seems to be fixed, at least from my test running the same source with rustc 1.37
Source locations are valid for both call sites.