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?

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)

Did you do a total-recompile?

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.

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

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

Right here

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

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.

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.

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

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.

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.