Thread: wierd c++ problem

  1. #1
    Frustrated Programmer :( phantom's Avatar
    Join Date
    Sep 2001
    Posts
    163

    wierd c++ problem

    I program in C++ and openGL and have an annoying bug. Once when I ran the program it crashed and I had to restat the computer, when I restarted the computer one of my header files had been turned into the assembly code and the screen looked like a hex editor. Any way to change this back and how did I cause it?

    I then proceeded to load in my recent backup but the first time I built the program I had a 'non incremental link' warning, without doing anything I rebuilt the program and it came up fine. I have cleaned the program, re-built in differant ways but I can't replicate the warning.

    Now, about every third time I run it the program crahes when executing the line
    glwInstance->glwFinished = TRUE; //quits program
    Yet this line is part of the program that has not been edited for months (when I started).

    James
    My site to register for all my other websites!
    'Clifton Bazaar'

  2. #2
    Frustrated Programmer :( phantom's Avatar
    Join Date
    Sep 2001
    Posts
    163
    Someone e-mailed me and explained I should compile this program in 'release' mode. I did this and I have no more crashes, can anyone explain to me why?
    My site to register for all my other websites!
    'Clifton Bazaar'

  3. #3
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > can anyone explain to me why?
    You've moved the bug to somewhere else.

    It's like a minefield - sometimes you can walk across it and nothing happens.

    Release mode builds just move the mines around - it can't remove them.

    > Yet this line is part of the program that has not been edited for months
    This is a sure sign of trouble.
    It usually means that you have some kind of memory access problem, typically resulting from
    1. using uninitialised pointers
    2. any kind of array overrun - either normal arrays, or arrays of dynamic memory
    3. not releasing allocated memory at the correct time
    4. using memory which has already been freed.

    But you have a bug for sure - and you can be pretty sure it will surface again at some point in the future - the only difference is, you'll have more code to look through.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  4. #4
    Frustrated Programmer :( phantom's Avatar
    Join Date
    Sep 2001
    Posts
    163
    I wish you were wrong but my inner voice tells me your right I think I might go through the code with an instructor and see what he can find.
    My site to register for all my other websites!
    'Clifton Bazaar'

  5. #5
    Registered User Engineer's Avatar
    Join Date
    Oct 2001
    Posts
    125

    Post

    I have had a similar problem at work last week. I have some code that was in production for several months. When we modified the main header file most of our software uses, I had to recompile the program with the new .h. No major changes were done to the structures in the header file, but despite that my server stopped working, it would run once and after doing everything it should have done, would get a segmentation fault error.

    After two days of debugging I found out that the lines that were causing the seg. fault, were actually the ones that were working for months before this.

    What happened is this: by incorrectly using some of my pointers, every pass through a certain function would damage the memory heap of my program in such a way that all the pointers in the heap were destroyed.

    The problem you are describing sounds very similar. What happenes in the release mode, is that the compiler packs your executable a bit differently than in debug mode, and because of that the conditions to recreate the previous error change. But if you add something to the program or remove something from it, the compiler will repack the executable again and the error might appear again.

    Cheers.
    1 rule of the Samurai Code: if you have nothing to say, don't say anything at all!

  6. #6
    Frustrated Programmer :( phantom's Avatar
    Join Date
    Sep 2001
    Posts
    163
    Other than Pointers to arrays the only other pointer I know of in my program is
    glwInstance->glwFinished = TRUE;
    which is the quit screen, and this is where the program crashes.
    My site to register for all my other websites!
    'Clifton Bazaar'

  7. #7
    Registered User Engineer's Avatar
    Join Date
    Oct 2001
    Posts
    125
    If I saw more of the code using this pointer and also if I really wanted to debug another problem such as this in less than a week, I would definitely help you.

    Cheers.
    1 rule of the Samurai Code: if you have nothing to say, don't say anything at all!

  8. #8
    Frustrated Programmer :( phantom's Avatar
    Join Date
    Sep 2001
    Posts
    163
    I wouldn't ask anyone on this board to help me debug a major problem like that because it would take up a lot of their time (which I don't think is fair). I have paid good money to do a course though so I'll get them to help me
    My site to register for all my other websites!
    'Clifton Bazaar'

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. A question related to strcmp
    By meili100 in forum C++ Programming
    Replies: 6
    Last Post: 07-07-2007, 02:51 PM
  2. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 06:54 PM
  3. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 06:24 PM
  4. Replies: 5
    Last Post: 11-07-2005, 11:34 PM
  5. half ADT (nested struct) problem...
    By CyC|OpS in forum C Programming
    Replies: 1
    Last Post: 10-26-2002, 08:37 AM