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. move up call stack one level

move up call stack one level

Scheduled Pinned Locked Moved C / C++ / MFC
questiondata-structuresperformancetutorial
5 Posts 4 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.
  • A Offline
    A Offline
    Andy H
    wrote on last edited by
    #1

    I am writing code to track down memory leaks in our program. I am doing this by overloading the new(size_t), new[](size_t), delete(size_t) and delete[](size_t) functions so that I can keep track of which calls to new do not have a corresponding delete. This is all working well. Now to my question, try as I might I cannot get the callers __FILE__ and __LINE__ information which I also need. I have tried #define new new(__FILE__,__LINE__) etc... but this is not compatible with existing code. I therefore feel that at some point in the call to new and new[], etc... that I need to move up the call stack a level to the caller so as I can obtain the __FILE__ and __LINE__ information from the stack page of interest. Does anyone have any example code of how this can be done, please?

    D L M 3 Replies Last reply
    0
    • A Andy H

      I am writing code to track down memory leaks in our program. I am doing this by overloading the new(size_t), new[](size_t), delete(size_t) and delete[](size_t) functions so that I can keep track of which calls to new do not have a corresponding delete. This is all working well. Now to my question, try as I might I cannot get the callers __FILE__ and __LINE__ information which I also need. I have tried #define new new(__FILE__,__LINE__) etc... but this is not compatible with existing code. I therefore feel that at some point in the call to new and new[], etc... that I need to move up the call stack a level to the caller so as I can obtain the __FILE__ and __LINE__ information from the stack page of interest. Does anyone have any example code of how this can be done, please?

      D Offline
      D Offline
      David Crow
      wrote on last edited by
      #2

      Andy H wrote:

      I have tried #define new new(__FILE__,__LINE__) etc... but this is not compatible with existing code.

      Just for my own edification, why not?


      "Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

      "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

      1 Reply Last reply
      0
      • A Andy H

        I am writing code to track down memory leaks in our program. I am doing this by overloading the new(size_t), new[](size_t), delete(size_t) and delete[](size_t) functions so that I can keep track of which calls to new do not have a corresponding delete. This is all working well. Now to my question, try as I might I cannot get the callers __FILE__ and __LINE__ information which I also need. I have tried #define new new(__FILE__,__LINE__) etc... but this is not compatible with existing code. I therefore feel that at some point in the call to new and new[], etc... that I need to move up the call stack a level to the caller so as I can obtain the __FILE__ and __LINE__ information from the stack page of interest. Does anyone have any example code of how this can be done, please?

        L Offline
        L Offline
        led mike
        wrote on last edited by
        #3

        Andy H wrote:

        I am writing code to track down memory leaks in our program.

        Is there some reason you don't use a tool that finds memory leaks?

        1 Reply Last reply
        0
        • A Andy H

          I am writing code to track down memory leaks in our program. I am doing this by overloading the new(size_t), new[](size_t), delete(size_t) and delete[](size_t) functions so that I can keep track of which calls to new do not have a corresponding delete. This is all working well. Now to my question, try as I might I cannot get the callers __FILE__ and __LINE__ information which I also need. I have tried #define new new(__FILE__,__LINE__) etc... but this is not compatible with existing code. I therefore feel that at some point in the call to new and new[], etc... that I need to move up the call stack a level to the caller so as I can obtain the __FILE__ and __LINE__ information from the stack page of interest. Does anyone have any example code of how this can be done, please?

          M Offline
          M Offline
          maciu2020
          wrote on last edited by
          #4

          I don't get, how do you want to get file and line with stack trace, but you can obtain your return address with void *lpReturnAddress; __asm { mov lpReturnAddress, DWORD PTR[esp] }

          A 1 Reply Last reply
          0
          • M maciu2020

            I don't get, how do you want to get file and line with stack trace, but you can obtain your return address with void *lpReturnAddress; __asm { mov lpReturnAddress, DWORD PTR[esp] }

            A Offline
            A Offline
            Andy H
            wrote on last edited by
            #5

            Thanks, I hadn't thought of assembler code. The following did the trick: unsigned* my_ebp; __asm { mov eax, ebp mov dword ptr [my_ebp], eax }

            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