[no bug] crash with empty string

[robmar]

There seems to be a bug here. Under VS 2008, Win 7 64-bit, its been crashing because the Irrlicht empty string allocator is passing a null pointer.

The culprit is this line:-

static core::stringc irrEmptyStringc("");

because it passes a null ptr into deallocate().

here´s the code change I made in irrallocator.h:-

Code: Select all

        //! Deallocate memory for an array of objects
        void deallocate(T* ptr)
        {
                // Robmar2012/02/11 fix
                if ( ptr )
                        internal_delete(ptr);
        }
 

[CuteAlien]

@robmar: Hm, that would've been worth it's own bug-report.
When do you get this crash - just running any example?
And do you also compile for 64-bit or just using VS 2008 with 32-bit compilation (that's my current setting...)?

[robmar]

@CuteAlien: Well, I recently went from XP to W7 64-bit, its the usual pain, VS 2010 is just unstable, went back to VS2008, but the linker crashes reliably 1 time out of 3, but a repeat compile fixes it. Microsoft!!!!

Am working on 64-bit, but there are issues with related libraries, or lack of them, in 64-bit, which is why on 64-bit W7 Microsoft are still using IE 32-bit.

Back to the point! I´m debugging an ocean shader node and on closing, calling closedDevice followed by device->drop, was getting a crash in Irrlicht. Traced it to that location which lacked a null ptr check, but I guess the problem is further up the call chain. Will let you know.

Can i ask you, the OGRE demos look really good, especially the Ogre water one, where when an object is dragged through water the water surface mesh deforms. I think if those were converted to Irrlicht, it would be a plus. SiO2´s demos would also be good if he would only include the source (converted from nvidia samples).

[CuteAlien]

Ok, please tell if you find out more. Don't know anything about OGRE demos :-)

[hybrid]

Ok, I've split this one as it really seemed to be a different thing.

[robmar]

i traced the null ptr being passed to "void deallocate(T* ptr)" in irrallocator.h to a push_back call in my code.

maybe a data member in allocator not being set for some reason in void insert(const T& element, u32 index=0).

Code: Select all

 
// From my header
core::array<core::vector3df>    m_ArrayOrientation;
float fX, fY, fZ;
 
// Serialize code loading float and writing to array:-
ar >> fX;
ar >> fY;
ar >> fZ;
m_ArrayOrientation.push_back( core::vector3df( fX, fY, fZ ) );   // This call ends up passing a null ptr to   void deallocate(T* ptr)
 

Call is from void insert(const T& element, u32 index=0)

which calls void reallocate(u32 new_size)

which calls allocator.deallocate(old_data); //delete [] old_data;

with a member, passed in old_data, which is NULL.

[robmar]

If I´ve not missed anything obvious, you might want to check the code below, at the end see <<code change>>.

Maybe to change the use of the variable name "array", as this is a reserved word in MS C++

[From MS help:
The array keyword lets you create a dynamic array that is allocated on the common language runtime heap.
[qualifiers] [cli::]array<[qualifiers]type1[, dimension]>^var =
gcnew [cli::]array<type2[, dimension]>(val[,val...])]

Code: Select all

 
        //! Assignment operator for strings, ascii and unicode
        template <class B>
        string<T,TAlloc>& operator=(const B* const c)
        {
                if (!c)
                {
                        if (!array)
                        {
                                array = allocator.allocate(1); //new T[1];
                                allocated = 1;
                        }
                        used = 1;
                        array[0] = 0x0;
                        return *this;
                }
 
                if ((void*)c == (void*)array)
                        return *this;
 
                u32 len = 0;
                const B* p = c;
                do
                {
                        ++len;
                } while(*p++);
 
                // we'll keep the old string for a while, because the new
                // string could be a part of the current string.
                T* oldArray = array;
 
                used = len;
                if (used>allocated)
                {
                        allocated = used;
                        array = allocator.allocate(used); //new T[used];
                }
 
                for (u32 l = 0; l<len; ++l)
                        array[l] = (T)c[l];
 
 
//              if (oldArray != array)
// <<code change>>
                if (oldArray  && oldArray != array)
                        allocator.deallocate(oldArray); // delete [] oldArray;
 
                return *this;
        }

[hybrid]

there's no problem with passing a null pointer into deallocate, even with the current version. The pointer is passed on until it reaches the delete operator, which handles null ptr properly. However, we probably need to document this a little more, as e.g. a malloc/free replacement would have to handle this in internal_delete. But so far there should be no problem. Even not with the array keyword, because it is only used as a keyword if managed code compilation is activated AFAIK.
But this means that your crash should come from somewhere else. Maybe you overwrite the array boundaries somewhere?

[robmar]

In debug, an illegal address exception occured at that point with the null ptr... if null is handled by the proc, maybe it was a corrupted heap. Microsofts debugger doesnt handle exceptions properly in the debugger inside try blocks, so at times it shows the wrong a point in the code, hard to believe isnt it!