irrAllocator in C++ 2005 Express

Mikenoworth · Post by **Mikenoworth** » Wed Aug 16, 2006 10:41 pm

	//! deallocate memory for an array of objects
	void deallocate(T* ptr)
	{
		internal_delete(ptr);
	}

When I init a string as "" (empty), it passes the empty array (ptr=NULL) and crashes at internal_delete(ptr) saying Access violation reading location 0x00000008, which doesn't make any sense because on debugging I see that ptr = 0x00000000.

This is happening in VC++ 2005 Express.

The stack for deallocate issue:

Code: Select all

>	Game.exe!irr::core::irrAllocator<char>::deallocate(char * ptr=0x00000000)  Line 40 + 0xe bytes	C++
 	Game.exe!irr::core::string<char,irr::core::irrAllocator<char> >::operator=(const irr::core::string<char,irr::core::irrAllocator<char> > & other={...})  Line 154	C++
 	Game.exe!CAnimatedTextures::Load(irr::core::string<char,irr::core::irrAllocator<char> > _Filename={...})  Line 57 + 0x16 bytes	C++

I changed it to this, to do a quick check:

Code: Select all

   //! deallocate memory for an array of objects 
   void deallocate(T* ptr) 
   { 
#ifdef _MSC_VER
#if (_MSC_VER >= 1400 ) 
      if(!ptr) return;
#endif
#endif
      internal_delete(ptr); 
   }

But now, allocate is fighting me:

Code: Select all

	//! allocate memory for an array of objects
	T* allocate(size_t cnt)
	{
		return (T*)internal_new(cnt* sizeof(T));
	}

The stack for allocate issue:

Code: Select all

>	Game.exe!irr::core::irrAllocator<char>::allocate(unsigned int cnt=17)  Line 34 + 0xe bytes	C++
 	Game.exe!irr::core::string<char,irr::core::irrAllocator<char> >::operator=(const irr::core::string<char,irr::core::irrAllocator<char> > & other={...})  Line 155 + 0x12 bytes	C++
 	Game.exe!CAnimatedTextures::Load(irr::core::string<char,irr::core::irrAllocator<char> > _Filename={...})  Line 57 + 0x16 bytes	C++

Debug Info for allocate issue:

Code: Select all

-		this	0x0012fd3c	irr::core::irrAllocator<char> * const
-		__vfptr	0x00000000	*
		[0]	CXX0030: Error: expression cannot be evaluated	
		[1]	CXX0030: Error: expression cannot be evaluated	
		[2]	CXX0030: Error: expression cannot be evaluated	
		cnt	17	unsigned int

I'm not at all sure as to what is going on.

Mikenoworth · Post by **Mikenoworth** » Thu Aug 17, 2006 7:07 am

Please devs, look into this.

vitek · Post by **vitek** » Thu Aug 17, 2006 8:35 am

It might help if you posted a simple testcase [20 lines or so] that shows the problem.

Mikenoworth · Post by **Mikenoworth** » Thu Aug 17, 2006 9:24 am

Here ya go

Code: Select all

#ifndef _DEBUG
		int APIENTRY _tWinMain(HINSTANCE hInstance,
							   HINSTANCE hPrevInstance,
							   LPTSTR    lpCmdLine,
							int       nCmdShow)	
#else
	int main(int argc[] , char *argv[] )
	{
#endif // #ifndef _DEBUG

#define _IRRALLOCATORTEST

#ifdef _IRRALLOCATORTEST
		irr::core::stringc IrrString = "";
		IrrString = "hello";
		irr::core::stringc OtherIrrString = "Doob";
		IrrString = OtherIrrString;
		
		return 0;
#endif

// ... my code goes on from here

Remember I'm using VC++ 2005 Express "straight out of the box", including and up to the steps given by microsoft to get win apps to compile. This never occured in 7.1 student edition.

I think string::array is NULL for "" initialized strings? So even though it is instantiated, array is still NULL. From what I've read, 2005 express has tightened its error handling for NULL pointers and may be the cause, am I wrong? ?? Either way nobody has given me info on _THEIR_ encounters with 1.10 and 2005 express, which is what I'm really looking forward to, one of these days.

hybrid · Post by **hybrid** » Thu Aug 17, 2006 9:54 am

So several things here. First of all there is no chance to get a null pointer except when the compiler does some weird things or an allocate call failed. Otherwise the array is always initialized.
Second, even my mem debugger could not find any problems under Linux, so might really have to blame the compiler (did you check the M$ pages if you need a compiler patch?!). Adn finally, At which point does it crash in the program fragment. Because you have several assignments in each line so I cannot tell where your stack trace belongs to.

Mikenoworth · Post by **Mikenoworth** » Thu Aug 17, 2006 10:42 am

EDIT: I suggest you fullscreen for this post for ease of reading.

I may need a patch, but it is obviously not something I would be concerned with for this issue, as I downloaded and installed vc++ 2005 express three days ago to the day.

Also, you're right, you can't get the proper info from the stack because the stack from before is not from that stub. Here I will post the stack and where the debugger points to at the time of error from the last stub I gave after viteks reply.

Here is the code at which debugging points to:

Code: Select all

	virtual void internal_delete(void* ptr)
	{
		operator delete(ptr);  // <- this line here
	}

And the stack:

Code: Select all

 	ntdll.dll!7c901230() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!7c96c943() 	
 	ntdll.dll!7c949a2e() 	
 	ntdll.dll!7c9269a9() 	
 	ntdll.dll!7c926abe() 	
 	ntdll.dll!7c95db5c() 	
 	ntdll.dll!7c96e062() 	
 	ntdll.dll!7c9106eb() 	
 	ntdll.dll!7c94a5d0() 	
 	ntdll.dll!7c926abe() 	
 	ntdll.dll!7c926abe() 	
 	ntdll.dll!7c96cde9() 	
 	ntdll.dll!7c96e0f0() 	
 	ntdll.dll!7c96e0d4() 	
 	ntdll.dll!7c9268ad() 	
 	ntdll.dll!7c91056d() 	
 	ntdll.dll!7c96e0d4() 	
 	ntdll.dll!7c95db5c() 	
 	ntdll.dll!7c96cd11() 	
 	ntdll.dll!7c960af8() 	
 	ntdll.dll!7c960bf0() 	
 	ntdll.dll!7c960bcc() 	
 	ntdll.dll!7c960bcc() 	
 	Game.exe!_free_base(void * pBlock=0x01544cc8)  Line 109 + 0x12 bytes	C
 	Game.exe!_free_dbg_nolock(void * pUserData=0x01544ce8, int nBlockUse=1)  Line 1329 + 0x9 bytes	C++
 	Game.exe!_free_dbg(void * pUserData=0x01544ce8, int nBlockUse=1)  Line 1194 + 0xd bytes	C++
 	Game.exe!operator delete(void * pUserData=0x01544ce8)  Line 54 + 0x10 bytes	C++
>	Game.exe!irr::core::irrAllocator<char>::internal_delete(void * ptr=0x01544ce8)  Line 64 + 0x9 bytes	C++
 	Game.exe!irr::core::irrAllocator<char>::deallocate(char * ptr=0x01544ce8)  Line 40 + 0x13 bytes	C++
 	Game.exe!irr::core::string<char,irr::core::irrAllocator<char> >::~string<char,irr::core::irrAllocator<char> >()  Line 143	C++
 	Game.exe!main(int * argc=0x00000001, char * * argv=0x01543578)  Line 37 + 0x13 bytes	C++
 	Game.exe!__tmainCRTStartup()  Line 318 + 0x19 bytes	C
 	Game.exe!mainCRTStartup()  Line 187	C

if it comes down to it, f$&k express, I will reinstall msvc student, but I would rather keep express to save hd space (30gigs is no longer alot)

hybrid · Post by **hybrid** » Thu Aug 17, 2006 10:53 am

No sorry, this won't work that way. You should post the stack of exactly that program, not of something you're using. The stack points to main.cpp line 37 whereas your main only has 5 lines. So I'm still not sure which deallocation fails.
BTW: Try core::stringc IrrString("") which avoids the assignment of the empty string. Maybe that one works.

Mikenoworth · Post by **Mikenoworth** » Fri Aug 18, 2006 12:38 am

My bad, it was 4am and I was walking dead by then.

Hm.. I don't know what to do.. I'm getting into all kinds of trouble here with the allocators.. I added a constructor to my struct which has a stringc in it, to set it to "". But now irr::core::array is complaining, and I think I know why. I must play some more. My reply to you is to not worry about the problem until I know exactly what is going on.

Mikenoworth · Post by **Mikenoworth** » Sat Aug 19, 2006 3:43 am

It keeps coming back to internal_delete in irrallocator with strings..

Do this and see what happens:

1. Create a struct
2. Use struct (ie "_my_struct tempstruct;") and add a stringc var to it (ie "irr::core::stringc Name")

Tell me if you get an error when the struct goes out of scope when you run it.

I've found this out, in strings destructor, allocator _vfptr is null.

Code: Select all

	//! destructor
	~string()
	{
		allocator.deallocate(array); // (delete [] data_array;
	}

niko · Post by **niko** » Sat Aug 19, 2006 9:16 am

Hm, I don't know what you are doing, but everything works fine for me. I just tested it with visual studio 2005 (which is just the express version + some pro features) and everything worked fine, just as expected. If it wouldn't, irrlicht would crash all the time anyway, because stuff like that is being used through the code everywhere. Also your testcase here worked:

Mikenoworth wrote:

Code: Select all

	irr::core::stringc IrrString = "";
		IrrString = "hello";
		irr::core::stringc OtherIrrString = "Doob";
		IrrString = OtherIrrString;

Don't know what you are doing to make this fail..

Mikenoworth · Post by **Mikenoworth** » Sun Aug 20, 2006 7:28 pm

It doesn't make any sense why it isn't working. I don't know.. For some reason the virtual function pointer for the allocators are turning up null ??

Mikenoworth · Post by **Mikenoworth** » Mon Aug 21, 2006 3:10 am

*sigh* I found what was going on. I was clearing my structure.

Code: Select all

memset((void*)&_ant, 0, sizeof(_ant) );

I don't know why I even had that line in there, but what a lousy mistake to make and to even post about it in the bug reports forum.

shame.

This mistake was even talked about in a topic somewhere about _vfptr and I decided that was not the issue.

Right/Wrong score:
Irrlicht: 8
Me: 0