• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
suliman

Access violation (bad reference counting, irrlicht)

13 posts in this topic

Hi

 

My prog "crashes" (when i close it!, still works fine during running) with: 

 

Unhandled exception at 0x1014d7af in game.exe: 0xC0000005: Access violation reading location 0xfeeefef2.

 

It happens when i send a string to a function. If i leave that param empty its ok. If i use a simple string like ("test") it crashes. But its only that instance of that function. I use that function with strings everywhere with no problem. Where can the problem lie?

 

Maybe you can answer generally, but when i close and get the error the compiler directs me to some irrlicht code, namely:

 

from ireferencecounter, this is what happens when i close my program:

bool drop() const
{
// someone is doing bad reference counting.
_IRR_DEBUG_BREAK_IF(ReferenceCounter <= 0)


--ReferenceCounter;
if (!ReferenceCounter)
{
delete this;
return true;
}


return false;
}
 
Edited by suliman
0

Share this post


Link to post
Share on other sites

Are you sure that you don't call delete explicitly on the object?

 

Cheers!

0

Share this post


Link to post
Share on other sites

Just out of curiosity, does this class have a destructor? If you call Foo::drop(), and it deletes the this pointer, then at the end of the scope, it calls Foo::~Foo(), this would be undefined behavior.

 

Also, the 0xfeeefef2 looks suspect. I hear that Microsoft's heap allocator implementation writes 0xFEEEFEEE in the freed memory, so it seems like you are trying to access something through an offset from a pointer that had its storage freed.

Edited by Ectara
0

Share this post


Link to post
Share on other sites

Of course it's a member function, it is const (EDIT: and delete this; wouldn't compile if it was a free function). A stack trace would be nice...

Edited by Paradigm Shifter
0

Share this post


Link to post
Share on other sites

0xFEEEFEEE is indeed value to mark freed heap memory. That's why I asked if the object has been freed already elsewhere.

 

Can you show the calling function where you send a string a bit more? Also the function receiving the string might be useful.

 

Cheers!

Edited by kauna
0

Share this post


Link to post
Share on other sites

i dont have to code now from work but it draws the string to screen. What makes it hard to understand is the function is used on other places to draw strings and works fine.
Its prob some messup with string lenght somewhere else right? I overwrite some memory and this gives that error message (mind: the program doesnt show any sign of corruption during runtime even if i provoce this error, i only see it when i close the program).

 

I never manually deal with the ireferencecounter its just an engine thing which i dont know what it does actually... But maybe it can hint on what im messing up.

0

Share this post


Link to post
Share on other sites

You're dropping the object too many times or else there's a bug in your version of irrlicht which is causing the object to be released too many times.

 

I know irrklang has a ridiculous and invasive memory management model. It looks like that extends into the realm of irrlicht in general, since the code you posted is one of the guilty parties. When I used irrklang there were constant bugs surrounding the poorly designed memory management and when I asked the author why he was doing things so bass-ackwards he blew me off, so I ended up just switching to FMOD, which is fantastic and far easier to work with.

 

Basically when you create the object it has one reference. When you do certain things to it that number increases, and when you call its drop() method the number decreases. The refcounter keeps track of how many things are referring to an object and deletes the object when that number reaches zero. If you try to drop or otherwise dispose of the object after that you'll get that segfault you're getting. Read the documentation carefully to see what all changes the refcount on the stuff you're using. When you shut down irrlicht it drops a lot of stuff, so it can segfault if some of that is already released.

 

Or just switch to FMOD. If your sound handling is properly abstracted it should only take a small amount of effort to make the switch.

Edited by Khatharr
0

Share this post


Link to post
Share on other sites

Im not using irrklang (already using FMOD by the way:))

 

This is the function that in the end causes the error (see below). If i comment out the last line (the drop) the error doesnt come up when i close the program.

But dont i need to drop it? Will they add up each time i call the function and use resources?

 

Thanks 

Erik

void gameGFX_irr::writeWrap(int flags, float x, float y, int align, float width, const char * fmt, ...){

	x+=offsetX;
	y+=offsetY;

	bool centered=false;
	if(flags==TEXT_CENTER)
		centered=true;

	const int maxLetters=2048;

	//prep string
	char txt[maxLetters];
	va_list va;
	va_start( va, fmt );
	vsprintf( txt, fmt, va );
	va_end( va );
	core::stringw str = txt;  

	const core::stringw strw(txt);
	const wchar_t* w_str = strw.c_str(); 
	irr::gui::IGUIStaticText * myText;
	myText=myDevice->getGUIEnvironment()->addStaticText(w_str,rect2d(x,y,x+width,screenY),0,true);
	myText->enableOverrideColor(true);
	myText->setOverrideColor(TEXTCOLOR);
	myText->setOverrideFont(font);
	myText->draw();
	//myText->drop();
}
0

Share this post


Link to post
Share on other sites

I can't quite see why you would be releasing the resource without a little more context. Do any of those function calls increment its reference counter? I can assume so, likely the addStaticText() method, which seems to return a pointer to an IGUIStaticText object with a reference count of one.

 

Again, does the class have a destructor?

0

Share this post


Link to post
Share on other sites

Hm... There's only a default destructor, so that rules that out. So, it may be a red herring to be trying to find fault in this reference counting; judging by the error given, it's crashing when trying to read ReferenceCounter, rather than triggering the assertion. So, it's either someone obviously is trying to use the automatically freed resource, or is trying to access something that was freed through some other means.

 

A stack trace and full error output would be desired. However, is it possible for you to place debug printing functions that don't depend on any state tracked by your code (like using std::cerr or std::wcerr), and have it output something like "IGUIStaticText constructed at (memory address)" on construction and reference increments, and "IGUIStaticText dropped at (memory address)" on calls to drop()? The (memory address) placeholder would be the value held by the this pointer, and if it doesn't dereference the this pointer for local variables or a vtable, it may manage to output the data without crashing, though the erroneous one would be undefined behavior, but it may still work for your platform.

 

If all goes to plan, you can count the number of times that a message is output for incrementing, and the number of times that a message is output for decrementing. If the two messages are equal in volume, we're barking up the wrong tree.

0

Share this post


Link to post
Share on other sites
Looking over Gebhardt's tuts it looks like the static text object is subordinate to an environment object, or should be. Seems you're only supposed to instantiate it once and then just render the environment and let everything auto-deallocate via spooky action from a distance. I've only got the phone until tomorrow, but I'll try to take a closer look when I can get to a computer. At first glance, though, it looks exactly like the nonsense from irrklang.
0

Share this post


Link to post
Share on other sites

Yeah. This is the same thing.

 

http://irrlicht.sourceforge.net/docu/classirr_1_1gui_1_1_i_g_u_i_environment.html#adb56652b23932a391b08f710a9546ef3

 

You're supposed to create the device, fetch the environment from it and then add your GUI widgets, then just call the environment's drawAll() each frame until you're done and then just drop the device to free everything. You gotta keep an eye on this cat. He makes everything droppable and then just mentions in his docs that there's all sorts of things that you shouldn't drop.

 

Here's his GUI tut:

 

http://irrlicht.sourceforge.net/docu/example005.html

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0