Programming Forums
User Name Password Register
 

RSS Feed
FORUM INDEX | TODAY'S POSTS | UNANSWERED THREADS | ADVANCED SEARCH

Reply
Page 1 of 3 1 23 >
 
Thread Tools Display Modes
Old Jun 26th, 2007, 7:58 AM   #1
rwm
Professional Programmer
 
Join Date: Jan 2007
Location: Cape Town
Posts: 291
Rep Power: 2 rwm is on a distinguished road
overloading global new/delete
hey, im trying to overload the global new and delete operators, im getting very strange allocations from malloc(...)

(Toggle Plain Text) 
//Debug.h

#pragma once

#ifdef MEM_DEBUG

//overload operator new and delete
void *operator new(size_t sz) {
	cout << "::new" << endl;
	void *mem = malloc(sz);
	cout << "\tallocated " << sz << " bytes\t(" << mem << ")" << endl;
	return mem;
}

void operator delete(void *m) {
	cout << "::delete" << endl;
	cout << "\tdeallocated\t\t(" << m << ")" << endl;
	free(m);
}

#endif

//something.h
#pragma once

//std
#include <vector>
using namespace std;

//local
#include "Debug.h"

void f() {
	vector<int *> vec;
	for(int i=0; i<10; i++) {
		int *p = new int(i+1);
		vec.push_back(p);
	}

	cout << "num of new " << vec.size() << endl;

	for(int i=0; i<vec.size(); i++)
		delete vec[i];
}

//main.cpp
#include <iostream>
#include <vector>
using namespace std;

//local
#include "Debug.h"
#include "something.h"

int main() {
	//
	int *p = new int(101);
	cout << *p << endl;
	delete p;

	f();

	return 0;
}

instead of 10 new calls, there are 21???

(Toggle Plain Text) 
clear; g++ -DMEM_DEBUG main.cpp -otest; ./test
::new
        allocated 4 bytes       (0x969c008)
101
::delete
        deallocated             (0x969c008)
::new
        allocated 4 bytes       (0x969c008)
::new
        allocated 258 bytes     (0x969c018)
::new
        allocated 100 bytes     (0x969c120)
::new
        allocated 4 bytes       (0x969c188)
::new
        allocated 4 bytes       (0x969c198)
::new
        allocated 4 bytes       (0x969c1a8)
::new
        allocated 4 bytes       (0x969c1b8)
::new
        allocated 4 bytes       (0x969c1c8)
::new
        allocated 4080 bytes    (0x969c1d8)
::new
        allocated 4 bytes       (0x969d1d0)
::new
        allocated 4 bytes       (0x969d1e0)
::new
        allocated 4080 bytes    (0x969d1f0)
::new
        allocated 4 bytes       (0x969e1e8)
::new
        allocated 4 bytes       (0x969e1f8)
::new
        allocated 4080 bytes    (0x969e208)
::new
        allocated 4 bytes       (0x969f200)
::new
        allocated 4 bytes       (0x969f210)
::new
        allocated 4 bytes       (0x969f220)
::new
        allocated 4 bytes       (0x969f230)
::new
        allocated 4080 bytes    (0x969f240)
::new
        allocated 4 bytes       (0x96a0238)
num of new 10
::delete
        deallocated             (0x969c008)
::delete
        deallocated             (0x969d1d0)
::delete
        deallocated             (0x969d1e0)
::delete
        deallocated             (0x969e1e8)
::delete
        deallocated             (0x969e1f8)
::delete
        deallocated             (0x969f200)
::delete
        deallocated             (0x969f210)
::delete
        deallocated             (0x969f220)
::delete
        deallocated             (0x969f230)
::delete
        deallocated             (0x96a0238)

whats wrong?
rwm is offline   Reply With Quote
Old Jun 26th, 2007, 5:14 PM   #2
grumpy
Programming Guru
 
grumpy's Avatar
 
Join Date: Jun 2005
Location: Adelaide, South Australia
Posts: 1,260
Rep Power: 5 grumpy will become famous soon enough
Nothing's necessarily wrong. Standard containers dynamically allocate and deallocate memory, which might (or might not; it depends on implementation of the allocator) make use of global operator new and delete.
grumpy is offline   Reply With Quote
Old Jun 27th, 2007, 3:51 AM   #3
rwm
Professional Programmer
 
Join Date: Jan 2007
Location: Cape Town
Posts: 291
Rep Power: 2 rwm is on a distinguished road
ah ok i see now! thanks for pointing that out!

but wouldnt there be an equal number of delete calls for every new call?
rwm is offline   Reply With Quote
Old Jun 27th, 2007, 4:50 AM   #4
iammilind
Newbie
 
Join Date: Jun 2007
Posts: 6
Rep Power: 0 iammilind is on a distinguished road
Indeed there is a mistake here
Hi rwm,

You have come up with really a genuine doubt, which is hardly seen or detected. It took me so much long to identify the same. Indeed there is a problem with your code, but before that I would like to inform something regarding why you are getting such answer.

The answer you are getting is dependent on compiler. The compiler like turboC may give you error for such code. Compiler like CC will give an immediate core dump / memory fault. And the compiler what you are using is giving you wrong output, which is more dangerous because you can't predict in big codes that something is really wrong.

When I compiled in CC, it was giving mem fault from the beginning. So I commented eveything inside the main() (retaining the above function definitions of f(), new(), delete() as it is). Still it was giving memory fault !!! It should not have happened, because main() is empty. In that sense CC compiler was helpful since it was not allowing the wrong definition of functions also.

After commenting function definition one by one, I found that there is a problem only with new(). After googling it I found it. Here they are,

(1) not a major one : for using size_t one should include<stdlib.h> and for malloc-free include<malloc.h>.

(2) The major problem is, you have defined new as,
void* operator new(size_t sz)
instead of
void* operator new(size_t sz, int arg) // preferably int arg=0

This is expected since you are using new for int allocation (default int argument shoud be there whether you are giving it or not). Same for the float/double/struct allocations is preferred.
Avoiding this default(second) argument will cause ambiguity for 'new', that which datatype is calling it,
i.e. int *p = new int; and
char *p = new char; and so on
will be seen as same and that's why confusing. It might be taking 'void' (which is not valid) by default (who knows).

Just add this 2 words(..., int arg=0) in your same code, and I hope it should start working fine as it is the case for my compiler. Let me know what result you are getting. I guess this explanation is sufficient. Thanks !
iammilind is offline   Reply With Quote
Old Jun 27th, 2007, 5:14 AM   #5
rwm
Professional Programmer
 
Join Date: Jan 2007
Location: Cape Town
Posts: 291
Rep Power: 2 rwm is on a distinguished road
hey iammilind! thanks for the reply! very helpful! only problem is i cant compile the changed code:

(Toggle Plain Text) 
#include <iostream>
#include <vector>
#include <stdlib.h>
#include <malloc.h>
using namespace std;

#ifdef MEM_DEBUG
//overload operator new and delete
void *operator new(size_t sz,int arg=0) {
	cout << "::new" << endl;
	void *mem = malloc(sz);
	cout << "\tallocated " << sz << " bytes\t(" << mem << ")" << endl;
	return mem;
}

void operator delete(void *m) {
	cout << "::delete" << endl;
	cout << "\tdeallocated\t\t(" << m << ")" << endl;
	free(m);
}
#endif

void f() {
	vector<int *> vec;
	for(int i=0; i<10; i++) {
		int *p = new int(i+1);
		vec.push_back(p);
	}

	cout << "num of new " << vec.size() << endl;

	for(int i=0; i<vec.size(); i++)
		delete vec[i];
}

int main() {
	//
	f();

	return 0;
}

i get this error

(Toggle Plain Text) 
main.cpp: In function ‘void f()’:
main.cpp:26: error: call of overloaded ‘operator new(unsigned int)’ is ambiguous
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/new:84: note: candidates are: void* operator new(size_t)
main.cpp:9: note:                 void* operator new(size_t, int)

im compiling using g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). there should be a flag to fix this problem then? only problem is when i look at the GCC docs i get a headache, theres so much stuff in there and to make matters worse im clueless as to what i should be looking for!

hope you can help!
rwm is offline   Reply With Quote
Old Jun 27th, 2007, 5:17 AM   #6
rwm
Professional Programmer
 
Join Date: Jan 2007
Location: Cape Town
Posts: 291
Rep Power: 2 rwm is on a distinguished road
and to kill a bird with one stone (ahem, 2 posts for clarity)

ive got a problem getting overloaded new and delete to work in my application. as it turns out ive found what is causing the bug, its a call to delete...

(Toggle Plain Text) 
*** glibc detected *** ./test: free(): invalid pointer: 0x0958c664 ***

so im trying to overload new/delete to find where the problem is coming from...

heres what i get when i try to compile with overloaded new/delete

(Toggle Plain Text) 
#ifdef MTK_DEBUG

//overload global new
void *operator new(size_t sz) throw(bad_alloc) {
	void *mem = malloc(sz);
	cout << "allocated " << sz << "bytes (" << mem << ")" << endl;
	return mem;
}

//overloade global delete
void operator delete(void *p) throw() {
	cout << "deallocated (" << p << ")" << endl;
	free(p);
}

#endif

(Toggle Plain Text) 
clear; make clean; make test
rm -rf *.h~ *.cpp~ *.so Makefile~  *~ *.mel~ test /root/dev/plug-ins/*.so
g++ -g test.cpp -g -D_DEBUG -DMTK_DEBUG MASParser.cpp OBJParser.cpp CDLParser.cpp APFParser.cpp wParser.cpp Tokenizer.cpp XHandler.cpp -o test
/tmp/cc7VCQqf.o(.text+0x4e): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/cc7VCQqf.o(.text+0xb0): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
/tmp/ccYsjTyP.o(.text+0x4e): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/ccYsjTyP.o(.text+0xb0): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
/tmp/ccYoaQ5V.o(.text+0x4e): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/ccYoaQ5V.o(.text+0xb0): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
/tmp/ccLyOW70.o(.text+0x4e): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/ccLyOW70.o(.text+0xb0): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
/tmp/ccjPbNTO.o(.text+0x4e): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/ccjPbNTO.o(.text+0xb0): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
/tmp/ccuOiyZm.o(.text+0x4e): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/ccuOiyZm.o(.text+0xb0): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
/tmp/cc1a6D4n.o(.text+0x0): In function `operator new(unsigned int)':
/root/dev/MassiveMayaToolkit/Debug.h:11: multiple definition of `operator new(unsigned int)'
/tmp/ccbrDobJ.o(.text+0x0):/root/dev/MassiveMayaToolkit/Debug.h:11: first defined here
/tmp/cc1a6D4n.o(.text+0x62): In function `operator delete(void*)':
/root/dev/MassiveMayaToolkit/Debug.h:17: multiple definition of `operator delete(void*)'
/tmp/ccbrDobJ.o(.text+0x62):/root/dev/MassiveMayaToolkit/Debug.h:17: first defined here
collect2: ld returned 1 exit status
make: *** [test] Error 1

hope you can help!
rwm is offline   Reply With Quote
Old Jun 27th, 2007, 5:58 AM   #7
iammilind
Newbie
 
Join Date: Jun 2007
Posts: 6
Rep Power: 0 iammilind is on a distinguished road
strange solution
I am refering to your earlier code which is appearing with following error after my solution,
main.cpp: In function ‘void f()’:
main.cpp:26: error: call of overloaded ‘operator new(unsigned int)’ is ambiguous
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/new:84: note: candidates are: void* operator new(size_t)
main.cpp:9: note: void* operator new(size_t, int)

This is strange solution but true,
instead of writing,
void* operator new(size_t sz, int arg=0)
write
void* operator new(size_t sz, int arg)
It will start working.

Earlier version confilicts with the library defined 'new' operator, because in that case we don't need to give the arg (default is taking care). However in later version we must have to give an argument.
However I am not sure this is the reason, but the same error has got solved in my CC compiler after removing '=0' from 'int arg'.
May be I din't check properly for int arg=0 and suggested you for the same. But isn't it a strange phenomena?
iammilind is offline   Reply With Quote
Old Jun 27th, 2007, 6:50 AM   #8
rwm
Professional Programmer
 
Join Date: Jan 2007
Location: Cape Town
Posts: 291
Rep Power: 2 rwm is on a distinguished road
heya! thanks for the reply!

ok i changed like you suggested from arg=0 to arg and it compiles fine, only problem is new is not overloaded anymore? heres my output:

(Toggle Plain Text) 
num of new 10
::delete
        deallocated             (0x8eb2008)
::delete
        deallocated             (0x8eb31d0)
::delete
        deallocated             (0x8eb31e0)
::delete
        deallocated             (0x8eb41e8)
::delete
        deallocated             (0x8eb41f8)
::delete
        deallocated             (0x8eb5200)
::delete
        deallocated             (0x8eb5210)
::delete
        deallocated             (0x8eb5220)
::delete
        deallocated             (0x8eb5230)
::delete
        deallocated             (0x8eb6238)

as you can see no calls to overloaded new are made
rwm is offline   Reply With Quote
Old Jun 27th, 2007, 7:16 AM   #9
grumpy
Programming Guru
 
grumpy's Avatar
 
Join Date: Jun 2005
Location: Adelaide, South Australia
Posts: 1,260
Rep Power: 5 grumpy will become famous soon enough
Sorry, iammilind, but you are mistaken in your advice.

If you supply an operator new() with a default argument value (that's what you get when you add the "=0" to the second argument) the result will be a compiler error due to ambiguity: the compiler has two operator new functions it can call, and no reason for preferring one over the other. If you supply an operator new with two arguments (and no default value for the second) you are simply overloading a function, and the operator new you supply will not be called.

rwm, the linker errors you reported in post 6 of this thread are self-explanatory. Your linker is finding two operator new() functions -- the compiler/library supplied default and yours. The ways of addressing this are compiler/linker dependent. In effect, you need to ensure the linker only sees one of those functions.

As I explained in another post, overriding operator new() and delete() are not the way to solve your problem. If you are getting a reported error with free() at run time, the real problem is not actually in the free() call. A basic rule of pointer molestation: if an error (eg a program crash) occurs, the real cause is code at or before the point where the crash occurs. If free() is reporting an invalid pointer, then you need to check the pointer supplied to free() -- and the code which supplied that pointer.
grumpy is offline   Reply With Quote
Old Jun 27th, 2007, 8:14 AM   #10
rwm
Professional Programmer
 
Join Date: Jan 2007
Location: Cape Town
Posts: 291
Rep Power: 2 rwm is on a distinguished road
heya! thanks for the reply and explanation!

ok, how can I force the linker to only see my version of new/delete?

what I was gonna do is in my delete call is put in the line number and file so i can find out where the crash happens, then i could go from there and find the bug at or before the point of crash

(Toggle Plain Text) 
...
void operator delete(void *p) {
    cout << "deleting (" << p << ") at " << __FILE__ << ',' << __LINE__ << endl;
    ...
}

im having trouble finding the point of crash - all g++ returns is

(Toggle Plain Text) 
*** glibc detected *** ./test: free(): invalid pointer: 0x08ac9664 ***
======= Backtrace: =========
/lib/libc.so.6[0x1641e0]
/lib/libc.so.6(__libc_free+0x77)[0x16472b]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x4d8e0a9]
/usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0x4d8e0f5]
./test[0x8060fdf]
./test[0x805adc3]
./test[0x805b040]
./test(__gxx_personality_v0+0x21b)[0x8049987]
/lib/libc.so.6(__libc_start_main+0xdf)[0x115d7f]
./test(__gxx_personality_v0+0x91)[0x80497fd]
======= Memory map: ========
00101000-00224000 r-xp 00000000 fd:00 32243724   /lib/libc-2.3.6.so
00224000-00226000 r-xp 00122000 fd:00 32243724   /lib/libc-2.3.6.so
00226000-00228000 rwxp 00124000 fd:00 32243724   /lib/libc-2.3.6.so
00228000-0022a000 rwxp 00228000 00:00 0
0038d000-003a7000 r-xp 00000000 fd:00 32243722   /lib/ld-2.3.6.so
003a7000-003a8000 r-xp 00019000 fd:00 32243722   /lib/ld-2.3.6.so
...

i cant find the point of crash. sure the addresses are returned, but to me it means nothing. i dont know how to utilize these...

sorry to be a ignorant ass but could you explain please! :eek:

thanks!
rwm is offline   Reply With Quote
Reply
Page 1 of 3 1 23 >

Bookmarks

« Previous Thread in Forum | Next Thread in Forum »

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes
Linear Mode Linear Mode

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Overloading >> and + fhslacrosse13 C++ 3 Nov 3rd, 2006 8:18 AM
C++ Global Variables question Ricky205 C++ 7 May 21st, 2005 11:12 AM
Overloading jon182 C++ 0 Mar 12th, 2005 10:09 PM
my Calculator layer Other Scripting Languages 4 Mar 9th, 2005 8:09 PM
global variables uman C++ 2 Feb 20th, 2005 11:39 PM


Contact Us - DaniWeb IT Discussion Community - Privacy Statement - Top


DaniWeb IT Discussion Community
All times are GMT -5. The time now is 6:57 PM.

Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC