FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Pages: [1] 2

Author Topic: bad_alloc / access violation reading location  (Read 7008 times)

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
bad_alloc / access violation reading location
« on: April 03, 2010, 01:17:12 pm »

hi,

i compiled FIFE as a dll in visual studio express 2008 (C++) and attempted to initialize some of the settings in EngineSettings class. (using C++)

I could use setInitialVolume, setScreenHeight, etc.. all the non-string values.

But I get a bad_alloc error during runtime when I try to set the string values like
setWindowTitle("Test");
setRenderBackend("OpenGL");

when I try to read instead - I could once again read from all the non-string values using the get methods.. but get a access violation reading location error during runtime when I try to read from the string values
getWindowTitle, etc..

Any ideas on where I went wrong please?

Thank you!
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #1 on: April 05, 2010, 10:30:53 am »

hi,

I managed to pinpoint the problem further. It seems like the member initialization list of the EngineSettings is not allocating the space for the string variables.

Code: [Select]
EngineSettings::EngineSettings():
m_bitsperpixel(0),
m_fullscreen(false),
m_initialvolume(MAXIMUM_VOLUME / 2),
m_renderbackend("SDL"),
m_sdlremovefakealpha(false), .....

m_renderbackend is a std::string variable of the EngineSettings class.

When i create an instance of the EngineSettings class, the debugger shows a <Bad_Ptr> at all the std::string variables like m_renderbackend, but the correct settings for the non strings ones.


Any enlightenment please?  :P

Thanks!
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #2 on: April 05, 2010, 01:01:26 pm »

hey,

Sorry for posting on my own post over and over again. Managed to find the problem, I THINK.

Not with FIFE!  :)

So here's just an update in case there are others who might run into this as well.

I think it is a general problem regarding passing non-POD across DLL boundaries. Different compilers, or even compiling with different settings might lead to different kinds of memory allocation and thus not being able to create and release memories for such non-POD members like strings.

Supposedly a few workarounds to this -> either create a function in the dll that handles the creating and releasing of memory.. described here
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/fb6ceb899f43f5c0

Or I chose the easier way out, use the same settings/compilers for the compiling of the dll and the main program that is calling the dll.

Thanks!

More problems to come!  ???
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #3 on: April 06, 2010, 09:20:00 am »

Hi noopeak,

Sorry for not getting back to you sooner...  I was away for Easter.   Good to hear you got your problem figured out. :D
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #4 on: April 06, 2010, 09:45:27 am »

Hi prock!

Thanks and great that you are back!  ;D Can do with some help now.

Immediately after I have "solved" that hurdle, another one slams in. Did not get much information from google.  :-[

This time my program crashes at this point during runtime, with a buffer overrun error:
A buffer overrun has occurred in test2.exe which has corrupted the program's internal state. Press Break to debug the program or Continue to terminate the program.


Code: [Select]

std::vector<std::string> EngineSettings::getPossibleRenderBackends() {
std::vector<std::string> tmp;
tmp.push_back("SDL");  // buffer overrun error here
tmp.push_back("OpenGL");
return tmp;
}

I have ensured that the dll and my test program is built with exactly the same settings this time- I ensured that the command line options had the same settings...

It should be a string problem (again!  >:() as I tested by adding the following codes to the above function and recompiling the dll..
Code: [Select]
std::vector<int> tmp2;
tmp2.push_back(1);
tmp2.push_back(32);

The test program got pass this 2 lines but still crash at the first push_back of the "SDL".

Please help me solve these "string problems" in the dll!

Thank you very much.
Logged

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #5 on: April 06, 2010, 01:24:47 pm »

short answer:
you cannot use FIFE as a dll currently. If you want to use c++ and FIFE together you will need to build FIFE as a static lib. I am currently doing this for the c++ tutorials I am writing see here http://code.google.com/p/fife-tutorials/

long answer:
As you have seen DLLs can cause a lot of problems when going across memory boundaries. There are ways around this problem but FIFE doesn't currently implement these techniques and we are working towards that goal in a future release. You are correct that in general memory should be handled on one side or the other to fix these weird crash problems that you are seeing. Also fife is not set up to produce a valid DLL currently as it does not have anything defined to be exported out of the DLL. Again we are working towards making FIFE compliant with DLL generation for an upcoming release but you should stick to building as a static lib for now. Also when developing with C++ you will find that FIFE does not provides a valid map loader or saver, these are things we are also currently addressing to make FIFE easier to use with c++.

If you have any other questions please feel free to post.
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #6 on: April 07, 2010, 01:12:08 pm »

hi vtchill,

Thanks for the response! Yes.. dlls do create a lot of headaches.  :(

Great to see someone working on the C++ version. I personally prefer C++ much more.

Anyway I have managed to bypass the problem by compiling them with the multi-threaded dll (without debug) option.

Another problem now.. I think you reported the same problem here -> http://forums.fifengine.net/index.php?topic=220.0

Basically runtime error when dealing with memory in the SDL portions. Have you solved that problem yet? What are the runtime library settings for the DLLs that come with the development kit?

Thanks!
Logged

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #7 on: April 07, 2010, 08:42:15 pm »

To my knowledge nothing has been done to solve that problem I posted. It kind of comes and goes depending on how things are built and run I think. When I build FIFE as a static lib things seem to operate much better and I would suggest doing that for now if you want to use c++. I can't think of a reason not to use a static lib right now with the current implementation of FIFE, but in the future having a valid DLL is definitely on the todo list.

I believe all libraries are built with multi-threaded DLL for the common run-time and the only thing I can think of is the SDL free being called there is calling free within the application space instead of the dll space which is bad since they use different memory spaces. So it is essentially a malloc in DLL space and free in EXE space is which causes an explosion in runtime of the memory heap.

Just as an aside the creation of a proper DLL is not something that is trivial to do. It is going to require a large api and code change to FIFE to make sure we don't export out anything that could be dangerous. A change of that size is going to take a while and will come slowly since we have teams relying on the FIFE api currently and we don't want to completely break their stuff.
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #8 on: April 12, 2010, 11:30:16 am »

Hi vtchill,

Sorry I ran into problems still... I decided to heed your advice and went static.. the errors showed up in the same place. Not being put off, I continued and even tried adding just a main function into the current FIFE engine, to build it as an exe, such as to reduce the possibilities of bad memory handling due to callings of dlls.

The runtime error is still at these places
Code: [Select]
SDL_QuitSubSystem(SDL_INIT_VIDEO);or
Code: [Select]
SDL_Quit();
Seems like freeing of any memory by SDL crashes the program.

Any advice on this please?

Thanks in advance!
« Last Edit: April 12, 2010, 11:34:06 am by noobpeek »
Logged

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #9 on: April 12, 2010, 12:07:09 pm »

Hmm that is odd that you are still seeing the same problems.

Out of curiosity can you checkout the source from the tutorials link i posted above into the directory <fife>/tutorials (you will have to create the tutorials directory as it does not exist). When you checkout the trunk it should have a build directory which has msvc2005 and msvc2008 support. Try and build using the msvc2008 solution and then you should be able to try by running the tutorials (using f5 in msvc). If this works then it is something in your build settings, however if this fails then it may be a more fundamental problem.

I will keep checking here for any updates.

In case you need the tutorials link again: http://code.google.com/p/fife-tutorials/
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #10 on: April 12, 2010, 12:52:30 pm »

hi vtchill!

Thanks for the ever prompt reply! Tried your suggestion.. but it didn't work..  :-[

Runtime error at
Code: [Select]
std::vector<std::string> EngineSettings::getPossibleRenderBackends() {
std::vector<std::string> tmp;
tmp.push_back("SDL");   // <- HERE!!
tmp.push_back("OpenGL");
return tmp;
}

Just as previously...  :-[

Perhaps it's how I built the fife.lib? Can I confirm what I did with you?

1) I used the svn trunk to get the latest revision from http://fife.svn.cvsdude.com/engine/trunk

2) I downloaded and installed the SDK - FIFE Win32 Development Kit January 2010 (installer)

3) I ran update_project_files.bat from <fife>/build/win32       (SHOULD I??)

4) I opened <fife>/build/win32/build_environments/visual_studio_9/fife_engine.sln

5) I removed the the "python" and "swigwrappers" folders from the project

6) I removed the Pre-Build Event of  "call update_swig_files.bat" from the Project Properties Settings

7) Then I built it with the settings that result in the below command line options:

*edited.. sorry.. pasted wrong command line codes

Builder Options:
Code: [Select]
/GL /I "..\..\..\..\engine" /I "..\..\..\..\engine\core" /I "..\..\includes\libguichan" /I "..\..\includes
\boost_1_38_0" /I "..\..\includes\openal" /I "..\..\includes\sdl" /I "..\..\includes\zlib" /I "..\..\includes
\libvorbis" /I "..\..\includes\libpng" /I "..\..\includes\libogg" /I "..\..\includes\python26" /I "..\..\includes
\sdl_image" /I "..\..\includes\sdl_ttf" /D "WIN32" /D "NDEBUG" /D "_LIB" /D "HAVE_OPENGL" /D "HAVE_ZIP"
 /D "LOG_ENABLED" /D "WIN32_LEAN_AND_MEAN" /D "NOMINMAX" /D
"M_SQRT2=1.41421356237309504880" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Fo"Release_static\\"
 /Fd"Release_static\vc90.pdb" /W3 /nologo /c /Wp64 /Zi /TP /wd4250 /wd4290 /errorReport:prompt

Linker Options:
Code: [Select]
/OUT:"C:\fife-static\build\win32\build_environments\visual_studio_9\Release_static\fife.lib" /NOLOGO /LTCG

Are my steps correct?  ???

Thanks a million!
« Last Edit: April 12, 2010, 01:10:10 pm by noobpeek »
Logged

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #11 on: April 12, 2010, 04:16:36 pm »

Those steps sound fine to me. Just make sure in the fife solution in the build configuration drop down you select Release_static which it looks like you did and verify that it copies the fife.lib to <fife>/build/win32/static_libs/msvc2008. Then if you open the tutorials solution from my google-code project it should link with that lib if you placed the tutorials in the <fife>/tutorials folder.

I can check this again tonight when I get home, but last time I ran it worked.

Also you can post a .zip archive of your msvc files and i can take a look and try and build them as well to see if i can reproduce the error. The only difference I can think of is I have msvc 2008 professional and you have the express version.

I know you need to download some additional SDKs if you are using the express versions which is documented here: http://wiki.fifengine.net/Building:Win32:VisualStudio
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #12 on: April 12, 2010, 10:46:32 pm »

hi vtchill,

Thanks for hanging on to me!  ;D Anyway, I missed out the additional Windows SDK portion. I did it and recompiled the engine and tutorials but no difference.

The debug version crashed at
Code: [Select]
std::vector<std::string> EngineSettings::getPossibleRenderBackends() {
std::vector<std::string> tmp;
tmp.push_back("SDL");   // <- HERE!!
tmp.push_back("OpenGL");
return tmp;
}

The release version crashed at (I didn't post regarding this the last time as I fell asleep!  :D)
Code: [Select]
ExactModelCoordinate Location::getMapCoordinates() const {
return m_layer->getCellGrid()->toMapCoordinates(m_exact_layer_coords); // HERE!!
}

I have attached the msvc files for the fife_engine. (<fife>/build/win32/build_environments/visual studio 9/) For the tutorials I didn't do anything to it, besides compiling and running.. so it should be fresh and original from the trunk.  :P

(I have renamed the ext of the zip file to .log, as they only allow uploads of a few filetypes!)

Thanks!
Logged

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #13 on: April 13, 2010, 06:56:09 am »

Ok great I will try and have a look at it tonight (its 8am here) and post my results.

I will also try the tutorials again quickly to see if they work out of the box. I have seen that exact crash you are seeing in the getPossibleRenderBackends and I am trying to remember how I got around it.
Logged

noobpeek

  • Newbie
  • Posts: 15
    • View Profile
Re: bad_alloc / access violation reading location
« Reply #14 on: April 14, 2010, 12:49:36 am »

Thanks vtchill!

Please let me know why I am getting these funny problems..  :-[

Meanwhile, I have went back to my attempt on DLL to try and pinpoint the problem of the SDL_Quit issue.
I think I have solved it. Not sure though. Please help me see, if it is a solution, it can perhaps be applied as a patch?

I pinpointed the problem to be calling any of the SDL_Quit, SDL_QuitSubSystem functions after the SDL_SetCursor call in cursor.cpp.

This is the way the cursor is drawn/set in FIFE engine
Ln 289 in cursor.cpp
Code: [Select]
WMcursor *cursor;
SDL_Cursor *curs2;

// Allocate memory. Use SDL_FreeCursor to free cursor memory
cursor = (WMcursor *)SDL_malloc(sizeof(*cursor));
curs2 = (SDL_Cursor *)SDL_malloc(sizeof *curs2);

//-- Set up some default values --
curs2->wm_cursor = cursor;
curs2->data = NULL;
curs2->mask = NULL;
curs2->save[0] = NULL;
curs2->save[1] = NULL;

//... blahblahblah.... etc... CODE OMITTED

m_native_cursor = curs2;
SDL_SetCursor(curs2);

#endif // WIN32 || __unix__

I noticed that the SDL_malloc was not freed. SDL_FreeCursor was never called for the cursor at the cleanup and SDL_FreeCursor CANNOT be called, as the cursor was not created by SDL_CreateCursor.

I replaced the code with
Code: [Select]
WMcursor *cursor;
cursor = (WMcursor *)SDL_malloc(sizeof(*cursor));

Uint8 mask[] = {0x00, 0x80, 0x01, 0xc0, 0x03, 0xE0, 0x07, 0xF0, 0x0F, 0xF8, 0x1F, 0xFC, 0x3F, 0xFE, 0x7F, 0xFF };
    Uint8 data[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
    SDL_Cursor* curs2 = SDL_CreateCursor(data, mask, 32, 32, 0, 0);
curs2->wm_cursor = cursor;


//... blahblahblah.... etc... CODE OMITTED


m_native_cursor = curs2;
SDL_SetCursor(curs2);   //cannot call SDL_Quit() after

and wrote a free memory function in the cursor class
Code: [Select]
void freemem() {
if (m_native_cursor != NULL) {
SDL_free(m_native_cursor->wm_cursor);
m_native_cursor->wm_cursor = NULL;
SDL_FreeCursor(m_native_cursor);
m_native_cursor = NULL;
}
}

and it solved the crash!  :D

Did the FIFE developpers have any issues with SDL_CreateCursor, which is why they avoided using it? If not using the SDL_CreateCursor and Freeing it later might solve some serious memory issues!

What do you think?
Logged
Pages: [1] 2