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.

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

gdb has the wrong source location with many macros #18285

alexcrichton opened this issue Oct 24, 2014 · 5 comments


None yet
7 participants
Copy link

commented Oct 24, 2014


macro_rules! call2( ($e:expr) => ($e()) )            
macro_rules! call( ($e:expr) => (handle(call2!($e))) )

fn bar() {                                           
    unsafe {                                         
        *(0 as *mut uint) = 0;                       

fn foo() {                                           

fn handle(_:()) {}                                   

fn main() {                                          
$ rustc -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 <>
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:
Find the GDB manual and other documentation resources online at:
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/".

Program received signal SIGSEGV, Segmentation fault.
main::bar () at src/
8               *(0 as *mut uint) = 0;
(gdb) bt
#0  main::bar () at src/
#1  0x000055555555f32e in main::foo () at src/
#2  0x000055555555f39e in main::main () at src/
#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).

cc @michaelwoerister


This comment has been minimized.

Copy link

commented Mar 26, 2015

Might be related to #23480.


This comment has been minimized.

Copy link

commented Jul 10, 2015

This bug makes debugging errors returned through try! really annoying.


This comment has been minimized.

Copy link

commented Nov 18, 2015


This comment has been minimized.

Copy link

commented Nov 15, 2016

Will this magically get fixed when #23480 is fixed?


This comment has been minimized.

Copy link

commented 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.

@jseyfried jseyfried self-assigned this Feb 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.