Has anyone else ever had any problems with running their progams in GnuDebugger and then gdb picks the wrong source file?

It's really frustrating because I can't set any breakpoints and it's only useful if my program quits suddenly and then I can use a backtrace (bt full) to find out where it was. And why does that work anyway if it is picking the wrong source file?

I've been developing the same program for a while now and gdb has been picking the correct source file for a while now until a few weeks ago it started picking wrong source files!

I think it was about the same time I added #include<fstream> and #include<iostream>
but I'm not sure. The last major change I made was to add saving settings to text and data files and reading them back in.

For a while gdb would pick allegro's inline - wait a minute, I remember it started happening as soon as I added my settings class. That's when gdb started picking allegro's inline file as source. I was using the settings from memory and then I added file save functions to my code. Then gdb started picking fstream as it's source file.

Here are my compiler settings.
Compile
-Wall -mwindows -ggdb
Link
-mwindows -lalld -ggdb

I get the same results if I use -g instead of -ggdb.

I've tried setting the default directory to search for source files (in gdb)
tried just about every command I could find in gdb's help and nothing works.
Here is the list of includes I am using.

#include <allegro.h>
#include <string.h>
#include <stdio.h>
#include <math.h>
#include <iostream>
#include <fstream>

//using std::cout;
using std::endl;
using std::ostream;
using std::fstream;
using std::ofstream;
using std::ios;

Does anyone know how to fix this?

I add -g3 -ggdb to all my commands as well as include all the same headers as you and have had no problems ever

Dustin, that -ggdb will override the -g3. -g args do not "stack". Just like -O.

Personally, I use -ggdb3, or -gstabs+ for c++ (though I'm not sure thats necessary anymore)

Sorry dudes no luck with -ggdb3 or -gstabs+ ,
gdb still insists my source file is fstream.
[center]:'([/center]

By the way I am using GDB 5.2.1

Did you do a total-recompile?

Why don't you post a gdb transcript? You know you can change the source file, right?

You probably might want to use cmath instead of math.h, cstring instead of string.h, and cstdio instead of stdio.h, if you want everything to be nice and tidy in the std namespace.

Dustin - deleted object and executable files and recompiled, no change.

CGamesPlay - Here's a copy of what happens in gdb. I've looked for how to change the source file but I don't know how to do that in gdb. All I've been able to find are commands that change the search path for source files and that doesn't help even after unloading the executable and changing the source path search directory by using
cmd->file
cmd->directory c:\\ctwoplus\\progcode\\allegro
cmd->path c:\\ctwoplus\\progcode\\allegro
cmd->file c:\\ctwoplus\\progcode\\allegro\\shadedshapes.exe
(Shown in transcript below)

BAF - I touched up my include files , thanks for the tip.

Any suggestions?

Try break main. Or break main.c:102. Or help break...

CGamesPlay -
I tried
(gdb)->break myfile.cpp:line_number
and it worked to set a breakpoint. Still outputs wrong file when using the list command though.

At least now I can set breakpoints again. Thanks.

Edit 1
-Correction , when gdb is stopped at the now sucessfully set breakpoint when I use the list command it lists my source file, but still initially only lists fstream.

Well, gdb isn't a source browser. I don't think there's any problem

I would like so see the full output of one of these sessions where its giving the wrong info.

Right here

Har. So I missed it.

But yeah, I don't think thats the right way to be using gdb...

cd /path/to/program
gdb ./program
gdb> run <arguments>
... (wait for crash)
gdb> bt
... (backtrace here)

I'd like to see that, instead of that odd mess that I saw above.

Or set proper breakpoints, and watches, and then "run". None of that other stuff should be necessary.

how can you expect it to give a valid "list" if its not even started running?

Well, I can see a good argument for having it show the main function as that is the next line about the be executed

Could be, but the actual first line is in crt0.o, some init code that eventually calls main().

Thomas - I included the output from the help commands within gdb in case I had missed something that would help me set the source file that was being read from.
My problem was that I couldn't set proper breakpoints because gdb was picking fstream for the source file. (Which I can do now with {gdb->break myfile.cpp:line_number})

This excerpt should show you better what happens when I use gdb to debug my program. I put in a line with pound signs to highlight what happens.

P.S. The progam has never had to be running for me to use list to view source code.
The problem is that it picks the wrong file.

Edit 1 - If gdb is listing the wrong file , that's where the breakpoints get set (in the wrong file). CGamesPlay gave me a workaround by using
gdb->break myfile.cpp:line_number
Then when my program reaches that breakpoint , it starts listing source from my file properly again. This is what I want to understand.

What? That looks fine to me. You do understand how #include works, right?

BAF - Not really , no. At least not in the way the compiler puts everything together.

And I've used plenty of #includes before and until recently they've never made gdb read in the wrong source file.

Like I said , it started happening as soon as I added my settings class (basically just data storage and retrieval and an << operator function so I can put it into a text file nicely. That's when gdb started selecting some allegro inline file as my main source file. Then I added #include<fstream> and #include<iostream> and that's when gdb started picking fstream.tcc as my source file.

Look at my last post - in the transcript window at these three lines

Until CGamesPlay showed me how to set a breakpoint by using the file name
I couldn't set any breakpoints to debug my program.
I've never had to explicitly mention my program by name or path when setting breakpoints until recently when gdb started playing roulette with source files.

.tcc? Isn't that a precompiled header? Maybe that has something to do with the oddities?

I haven't the slightest clue , so I'm going to try updating gdb (6.6 is out now)
and look over the online manual.
GDB: The GNU Project Debugger
GDB Documentation

If .tcc is a precompiled header I think its safe to just delete it. Try renaming / deleting it and see if that fixes it.

Is there a settings.tcc as well?

On second thought, I think .pch is the precompiled header extension... hm...

fstream.tcc is a bunch of templates which I don't understand yet anyway.
But I won't be deleting anything. Don't want to reinstall Mingw.

The trick is to rename it which is effectively the same yet can be easily undone.

I knew this would cause trouble but I didn't know how. Did it for fun anyway.
renamed fstream.tcc to fstream.tcc.bak
and the compiler replied :
C:/MinGW/include/c++/3.2.3/fstream:576:29: bits/fstream.tcc: No such file or directory

fstream contains these lines

#ifdef _GLIBCPP_NO_TEMPLATE_EXPORT
# define export
#endif
#ifdef  _GLIBCPP_FULLY_COMPLIANT_HEADERS
# include <bits/fstream.tcc>
#endif

#endif

And as such the program would never compile without it.
Well , I had my fun.

Dustin - no , there's no settings.tcc in my compiler directory.