Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. corrupt callstack after crash in release

corrupt callstack after crash in release

Scheduled Pinned Locked Moved C / C++ / MFC
debuggingdata-structureshelpannouncementlearning
5 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    RicoH
    wrote on last edited by
    #1

    Hi, I've been working on this one for some days now and I'm all out of ideas. My program works just fine when it is build for debug, but when I build it for release it crashes at some point. Now, when I tried to analyze the crash dump information, I saw that the callstack got corrupt so I can't do anything with it. I've tried using BoundsChecker on both the release and debug exe but it doesn't report anything (except for the access violation of course...) My next idea was to add some logging (to a file) in my program so I could trace where exactly I was going in my code. The problem now is that by adding code for logging purposes I'm changing the stack of my program so that again it doesn't crash anymore. I have been able to make up in which function the crash occurs, but placing logging inside that function "prevents" the crash... I hope there is someone out there who has run into a similar problem and was able to solve it. Any ideas are welcome greetz Don't think you are, know you are...

    J T A N 4 Replies Last reply
    0
    • R RicoH

      Hi, I've been working on this one for some days now and I'm all out of ideas. My program works just fine when it is build for debug, but when I build it for release it crashes at some point. Now, when I tried to analyze the crash dump information, I saw that the callstack got corrupt so I can't do anything with it. I've tried using BoundsChecker on both the release and debug exe but it doesn't report anything (except for the access violation of course...) My next idea was to add some logging (to a file) in my program so I could trace where exactly I was going in my code. The problem now is that by adding code for logging purposes I'm changing the stack of my program so that again it doesn't crash anymore. I have been able to make up in which function the crash occurs, but placing logging inside that function "prevents" the crash... I hope there is someone out there who has run into a similar problem and was able to solve it. Any ideas are welcome greetz Don't think you are, know you are...

      J Offline
      J Offline
      Joaquin M Lopez Munoz
      wrote on last edited by
      #2

      If you spotted the offending function, then you're nearly at it. Try posting the code here, maybe someone can see the error. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

      1 Reply Last reply
      0
      • R RicoH

        Hi, I've been working on this one for some days now and I'm all out of ideas. My program works just fine when it is build for debug, but when I build it for release it crashes at some point. Now, when I tried to analyze the crash dump information, I saw that the callstack got corrupt so I can't do anything with it. I've tried using BoundsChecker on both the release and debug exe but it doesn't report anything (except for the access violation of course...) My next idea was to add some logging (to a file) in my program so I could trace where exactly I was going in my code. The problem now is that by adding code for logging purposes I'm changing the stack of my program so that again it doesn't crash anymore. I have been able to make up in which function the crash occurs, but placing logging inside that function "prevents" the crash... I hope there is someone out there who has run into a similar problem and was able to solve it. Any ideas are welcome greetz Don't think you are, know you are...

        T Offline
        T Offline
        Tim Smith
        wrote on last edited by
        #3

        You are probably trashing a stack array. Maybe a character string or some such thing. You might also be returning a pointer to a stack variable. This can cause all sorts of strange problems. Tim Smith I'm going to patent thought. I have yet to see any prior art.

        1 Reply Last reply
        0
        • R RicoH

          Hi, I've been working on this one for some days now and I'm all out of ideas. My program works just fine when it is build for debug, but when I build it for release it crashes at some point. Now, when I tried to analyze the crash dump information, I saw that the callstack got corrupt so I can't do anything with it. I've tried using BoundsChecker on both the release and debug exe but it doesn't report anything (except for the access violation of course...) My next idea was to add some logging (to a file) in my program so I could trace where exactly I was going in my code. The problem now is that by adding code for logging purposes I'm changing the stack of my program so that again it doesn't crash anymore. I have been able to make up in which function the crash occurs, but placing logging inside that function "prevents" the crash... I hope there is someone out there who has run into a similar problem and was able to solve it. Any ideas are welcome greetz Don't think you are, know you are...

          A Offline
          A Offline
          AlexO
          wrote on last edited by
          #4

          The first thing to check is that all you modules use same CRT model (lets say /MDd) "Project settings->C/C++->Code Generation->Runtime Library" page. The second is to debug. When stack gets corrupted it is easy to see in debug right the way (assuming you know the approximate location.

          1 Reply Last reply
          0
          • R RicoH

            Hi, I've been working on this one for some days now and I'm all out of ideas. My program works just fine when it is build for debug, but when I build it for release it crashes at some point. Now, when I tried to analyze the crash dump information, I saw that the callstack got corrupt so I can't do anything with it. I've tried using BoundsChecker on both the release and debug exe but it doesn't report anything (except for the access violation of course...) My next idea was to add some logging (to a file) in my program so I could trace where exactly I was going in my code. The problem now is that by adding code for logging purposes I'm changing the stack of my program so that again it doesn't crash anymore. I have been able to make up in which function the crash occurs, but placing logging inside that function "prevents" the crash... I hope there is someone out there who has run into a similar problem and was able to solve it. Any ideas are welcome greetz Don't think you are, know you are...

            N Offline
            N Offline
            Neville Franks
            wrote on last edited by
            #5

            This article may help. http://www.codeproject.com/debug/survivereleasever.asp[^] Also the BugSlayer column by John Robbins on MSDN/MSJ and his book, and the WheetyExceptionReport code by Matt Pietrek (spelling) also on MSDN. Neville Franks, Author of ED for Windows. www.getsoft.com Make money with our new Affilate program

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups