#36 Complicated problem


Dear Sir,
I'm facing a difficult situation while coding a program,
and i really need your help.

Sometimes my program behaves great, then i make a
little change to the program and it starts doing strange
things, so i change another little thing and it starts
working great again. It seems to me that there is a bug
hided too deep and that i can't find it.

I'm starting to think that the bug is not in my code but
in the standard C++ library but of course I'm not sure, I
beg u help me

I finnally got a version of my programm that instead of
doing strange things it simply crashes.
Analyzing what's happening i found that there is a string
object that changes its value suddenly with no reason.
I needed to trace the value of that string in the whole
program to know the exact moment when it changes.
So i created a class called TraceObjCaller that in whose
constructor it writes to a file the value of that string.
When i want to trace the value i build one object of
that class.

Using that technique i traced down the bug to the
construction of a deque. As shown in the next piece of
code i've placed a trace before an after the
construction of the deque.

class msg_lnklist : public TraceObjCaller, public
TraceObjCaller toca;

during that construction the value of the string changes
for no reason
Here is the output (the trace file)
TraceName():|Q= l= l= n= |Q= 

The first time the string has its correct value(an ip
address), the second time it seems to show random

From this evidence i suspect that in some conditions the
deque class is modifying memory which doesn't belong
to it. Could this be possible????
Thank you very much in advance for your help,
Marcelo Taube

PD: Some details: I'm using gcc version 3.2 (mingw
special 20020817-1) (which comes with the last version
of Dev-Cpp).


  • Luke Dunstan

    Luke Dunstan - 2003-12-15

    Logged In: YES

    It is very unlikely that your problem is caused by a bug in
    libstdc++, but the only way for us to check is if you post a
    complete example program that demonstrates the problem.
    Ideally you should reduce the code as much as possible but it
    is not essential. You may use the file attachment feature on
    this bug tracker, or if it is too big then preferably you can
    make it available on the web and post a link here.

  • Marcelo Taube

    Marcelo Taube - 2003-12-15

    Logged In: YES

    I could try that but it would be extremly diffult to achive
    because if add or delete a variable the problem moves
    somewhere else.
    I mean that if i start removing things probably my programm
    would modify another piece of memory and not the string
    which is modifying now and i was lucky to find it this time, i
    might not find it again.

    I suspected that the problem was libstdc++ because the
    problem happens when the deque is constructed, typically i
    search for buggy code finding the exact line when the
    mistake is made. However, if the deque is not the problem
    you could give me an idea of how to search for the bug
    because i don't know what to do now.

  • Leo

    Leo - 2003-12-16

    Logged In: YES

    Are you using multiple threads?
    Or does your program execution depend on some kind of
    external timing (like PC clock, timeGetTime() Win32 function,

    If that is not the case, that is, if your program is just plain
    sequential, then you can use gdb watches to inspect what
    code is modifying hthe corrupted data (up to the exact asm
    instruction), and chances are 100% that you'll catch your bug.

    If you're doing threads, then probable cause is that you
    forgot to compile and link with -mthreads options for gcc.
    I'm using STL and no problems til now, but I'm not using
    deque's, just plain lists vectors, strings and all sorts of

    The watches command(s) for gdb is docummented in gdb
    docs, but one advice: make your expressions as simple as
    possible, or your program may go way to slow. For example, if
    you know that a (void *) stored at 0x123456 is changed and
    it shouldn't change, then you can set a watch like this in the
    gdb console:

    gdb> watch *((void **)0x123456
    gdb> run

    That's simple enough expression I think.

    Hope this helps,

  • Marcelo Taube

    Marcelo Taube - 2003-12-17

    Logged In: YES

    hehe, i'm sorry, it was all my mistake.
    I finally discovered my mistake.
    My whole project is a dll and i have a test programm. The
    mistake was not in the dll itself but in the programm. I passed
    a char array that didn't end with a '\0'. Since my dll works
    with std::string and not with char array, it constructed a
    std::string with that. When the constructor of std::string
    was called it probably made a mess inside libstdc++. But the
    programm continued to work untill later when some other
    libstdc++ functions were used.

    In order to fix everything i only had to add the '\0'.

    I only have something to ask: isn't possible to detect this
    kind of error in an easier way?. I mean i had an error in one
    side of my code and the effects were seen in the opposite
    side, and it keep me thinking that the error was in the
    constructor of a deque. That made me spend like three days
    of headaches. There must be some way to test this kind of
    thing. don't u think?

    Anyway, all this stuff helped me a little.
    I learned about -mthreads, which i had never heard of before.
    I now added it to the g++ params but what is it supposed to
    do? My programm used to work just fine without them. And
    now i need to include a new dll called mingwm10.dll which i
    didn't have and i had to search it in the internet... (i found it
    but i'm not sure is the latest version). And mingwm10.dll isn't
    small at all, it's size is 529 kb. Do u think it's usefull? Where
    can i learn about that?

    Thanks to Leo and infidel for all their help,

  • Earnie Boyd

    Earnie Boyd - 2003-12-17
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks