OnCreate problem
Monkey Forums/Monkey Programming/OnCreate problem
| ||
| Is there a certain amount of stuff you can do in OnCreate, I ask as my game sets up the rendering system loads some basic images and parses a demo system (2595 bytes). But I always get a MAV when parsing the demo system. I have tried outputting the databuffer to a file to make sure its not corrupt, its perfect. Also moving stuff around to no avail. The whole loader fails at random points when parsing the file my only option would be to push the file to OnUpdate and hope it fixes it. If this is the case maybe it should be in the docs somewhere. |
| ||
| I've never seen any problems. You can get some systems complaining when OnCreate() takes more than a few seconds, but that's a different error anyway. Have you tried it in Debug mode, and perhaps on a different target? Most likely you have a bug somewhere and this may help root it out, |
| ||
| Ive even deleted the build folder, its weird as the exact same code works flawlessly under Linux. All its doing is reading a character from a databuffer with PeekByte converting with String.FromChar and tacking it onto the end of a string. After that is a #10 or #13 is hit I parse the string, it also ignores #9 tabs etc. Running it gives me a MAV at random points in the data this is with monkey 83a. Oh and this is all in Debug mode all I get is Memory Access Violation and nothing more. |
| ||
| I get this: The Monkey Runtime Error : Memory access violation is not very descriptive and happens at random in this function. If it was at the same place or we had some more 'descriptive' error messages it would be easier to debug. I have remmed out some of the code and it still throws a MAV and to be honest its bloody annoying I know the data is fine too. |
| ||
| Can you separate the code in different methods which is called by OnCreate so that you can narrow down the issue? From your build log, the application compiles fine and is running until you parse the Sun data. |
| ||
| are you doing any async loading or using any mojo-specific functionality? iirc, OnCreate does some stuff before App has a full handle on all contexts, including graphics context, which can cause headaches when loading some assets. Async loaders may return before graphics context is valid, which can cause this error. Solution would be to have a state machine delay the loading a few frames (like say in a splash screen). Very sleepy so apologies if this is completely off |
| ||
| Well all I'm doing is getting a character from a DataBuffer with peekbyte and using String.FromChar( char ) to add it to a string then when chr(10) or chr( 13 ) are hit. It also ignores ; and blank lines. Once it hits the characters 10 and 13 I just run through parsing the string seeing what it contains. The reason I was asking is it fails at random points in the parser its not always at the same point in the instance above it failed last sun sometimes at stations or planets its completely random. Its not async loaded just loading a file into a buffer, unencrypting the buffer and then parsing the buffer to find out what's in the system. |
| ||
| Another option is to install MSVC and do a proper debug run. |
| ||
| Hmm but I use gnu c++ as its easiest to install and setup :/ |
| ||
| Shot in the dark but sometimes it's possible to have a random error when an asset is not loaded do to misspelling or some such. It would also cause a MAV. |
| ||
| We think alike but this system is pure code no assets, all it does is run through the DataBuffer and make the system. I know the DataBuffer is there as the system details are parsed perfectly before the system bodies, sun, planets and moons etc. I also know these are created perfectly to as it sometimes gets right up to nebulas before throwing a error, sometimes its the first sun. On the whole the error is very hard to track down and correct if I knew what caused it I would fix it and continue but throwing a random error is just complete nonsense. Fwiw I recoded the function so it was laid out completely different with if statements instead of a select...case...end call and it still throws a random error at random points. I also make sure all types are created before use and that would have been a null type problem not a mav. Being the error in question even in debug mode shows a complete lack of proper debugging system available, even MSVC 2010 doesn't give a different error I had a hard time getting it to use that as it preferred to use mingw |
| ||
| Are you using a static seed or using millisecs or something to make it more random? Could you try to find a seed which always reproduces the issue? |
| ||
| The error being printed is effectively Monkey throwing its hands up and saying "something went wrong in a way the language didn't trap". As it's platform specific you're going to struggle to track it at a Monkey level. If you're not comfortable with debugging C++ applications then you may have to bite the bullet and hand the project to someone who is to trace the problem. Mark may well consider any such error being thrown in Debug mode to be a Monkey bug and be willing to look at the problem himself if you report it. |
| ||
| What happens if you run it on a different target? ie. HTML5. |
| ||
| File loading prevents it all I have is glfw2 and 3 to test with |
| ||
righty after going through LOADS of lines and ludicrous applications of #rem this lineLine += String.FromChar( Char ) It seems the FromChar is causing a MAV no matter how I use it |
| ||
| Testing now.. |
| ||
| The file is 2595 bytes long and the line is reset when its parsing is complete so no string gets longer than 30-40 bytes. |
| ||
| How are you testing for end of file? |
| ||
| Well I'm using DataBuffer.load to load it in and checking against its length. |
| ||
| If you've tracked it down to a single line then it should be easy for you to create a simple example with an embedded string that reproduces the issue. |
| ||
| I suspect it's the data buffer, usage of which sounds a little like overkill when it comes to reading and parsing a text file. |
| ||
| The file is encrypted so the DataBuffer is used for unencryption, with the loading system from the DataBuffer it seemed easier to do it that way. As for reproducing the issue I am looking at writing a work around to make sure it doesn't happen again |
| ||
| How does "writing a workaround" stop it from happening again? It might solve your specific issue in your singular project but it does nothing to resolve the problem for Monkey users as a whole if the problem is with Monkey and not an error in your code. |
| ||
| I will look to creating a source file that hopefully will demonstrate the issue. |
| ||
| After moving the offending functions to a separate source file I cant reproduce the problem, I have checked all variables to make sure they are initialised (coming from c++ its something I always do). What I might try is Strict to see if that throws anything, its a weird bug which is why I thought there might be a certain amount of stuff that can be done before monkey throws a error. EDIT: Weirdly enough strict didnt throw up anything apart from function return values, I managed to rectify the problem by running from 0-DataBuffer.Length-1 (one line I missed) instead of to the length which seems to fix the problem, it wasnt throwing a error for being out of bounds like it does with arrays just throwing a MAV which seemed a bit harsh. After doing that I also looked at the whole project and decided to convert to using arrays instead of databuffers and this works faster than the databuffers do so for me its a win win :). I had some niggles with converting some of the functions but this has all been sorted now and the system is now back on track. All I have to do now is extract the colours from the values in the data files and then its back to where it was before with encrypted star systems :). So I would like to apologise for being a complete douche and not noticing a glaring error in my code, its amazing how a simple error just doesnt appear no matter how hard you look at it. No matter how hard I looked my eyes just couldnt see it but stepping back from the whole thing for a while and then coming back to it allowed me to see I missed one line :s. |
| ||
| I guess the data functions probably use pure pointer arithmetic instead of arrays. |
   |