2

Please let me know if I can do it or not?

I am writing a library that could work to track memory allocation and de-allocation in C++. In short, I am trying to see if my application does not have any memory leaks. This is what I did so far.

Overrode the new and the delete operator and now. Whenever the application uses new, I am planning to store the address and the number of bytes that are allocated in that call. Similarly, when the delete is called on that address, I will remove that from the stored list. Until now its fine. But I want to store the file name and the line number from where the "new" is called. I can do that only in the overridden new. Is there a way to get line number in the overridden function?


1    int main()
2    {
3       // Say, A is a structure
4        A *a = new A();
5        return 0;
6     }
7    void* operator new( size )
8    {
9        //
10       // store the line number and file name on line 4 ??? Can I do it?
11       return (malloc(size));
12   }
------------------------
user543630
  • 51
  • 1
  • 4
  • 4
    Why not use Valgrind? And not re-implement the wheel? Unless of course you really want to do this, of course – YuppieNetworking Dec 15 '10 at 16:54
  • @Yuppie Valgrind isn't on Solaris. – chrisaycock Dec 15 '10 at 16:55
  • 3
    For production-level testing on Solaris, use DTrace rather than writing your own profiler. – chrisaycock Dec 15 '10 at 16:56
  • I've never used Valgrind but dTrace is my second option after I am sure that I cannot implement the way I described as above. – user543630 Dec 15 '10 at 17:03
  • If you can afford it Purify will save you lots of headaches. Alternatively, if you can find it, there is a very small leak checking tool called `efence` I think the sources are available and you may be able to get this to work for you. – Nim Dec 15 '10 at 17:25

3 Answers3

4

Since C++20 you can use std::source_location which offers:

  • line
  • column
  • file_name
  • function_name

For previous versions of C++, traditionnally the macros __LINE__ gives the line number but also __FUNCTION__ and __FILE__ are really helpful, giving the const char* of the enclosing function, and file name.

Indeedn, __FUNCTION__ is not standard but supported by several compilers.

Unfortunately these macros only take their value in place. So it is not possible for you to ask for the caller.

You should write the __LINE__ and __FILE__ macros everywhere you use new. :(.

Stephane Rolland
  • 38,876
  • 35
  • 121
  • 169
  • 1
    `__LINE__` and `__FILE__` are standard C macros, and are not Visual Studio-specific. `__FUNCTION__` is not standard, but many compilers have equivalent alternatives. – Ben Karel Dec 15 '10 at 17:02
  • yes... __LINE__ and __FILE__ are useful but like u said, they can be useful only when we use them in a macro. I do have a lot of news and dels in my many many processes in the application. So, thats a big headache... looks like the last resort, dTrace. – user543630 Dec 15 '10 at 17:09
  • I don't know dTrace, I will have a look at it, nice to know. – Stephane Rolland Dec 15 '10 at 17:11
  • 1
    DTrace is available on Solaris, OpenSolaris, MacOS X and FreeBSD. – alanc Dec 15 '10 at 18:56
3

Finally I got an answer by one of similar threads in this forum... The following code worked... Lets say,

class A
{
    public:
    char str[1000];
    A()
    {
        strcpy(str,"Default string");
    }
    A(const char* s)
    {
        strcpy(str,s);
    }
};

void * operator new (unsigned size, char const * file, int line)
{
    cout << "File = " << file << endl;
    cout << "Line = " << line << endl;
    return( malloc(size));
}
#define new new(__FILE__, __LINE__)
int main()
{
    A *a = new A("Leak");
    printf("%s",a->str);
    delete a;
    return 0;
}

Related post where I found the answer... overloading new and delete in c++

Community
  • 1
  • 1
user543630
  • 51
  • 1
  • 4
1

You can use the studio dbx run time checking feature to identify memory leaks under Solaris ( http://blogs.oracle.com/janitor/entry/runtime_memory_checking .) libumem can also be very helpful ( http://blogs.oracle.com/pnayak/entry/finding_memory_leaks_within_solaris .)

alanc
  • 4,102
  • 21
  • 24
jlliagre
  • 29,783
  • 6
  • 61
  • 72