GLFW and v54

Monkey Forums/Monkey Programming/GLFW and v54

Rixarn(Posted 2012) [#1]
Hi,

Is there something special that has to be configured with the GLFW target and v54?

Now I cannot run even a simple piece of code:



I'm getting a File Not Found error:



BTW monkey's path is D:\MonkeyPro54.


benmc(Posted 2012) [#2]
I have no idea if this will help, but I always get this error if my previously running GLFW test is still running - or maybe it crashed and is running in the background.

Sometimes this happens if the vc2010 runtimes are still running in the background too - wish I could remember what they were.


Rixarn(Posted 2012) [#3]
Hi benmc,

Sadly for me it ain't the case. Just tried a 1st time run of the GLFW code and it's the same result =(


Playniax(Posted 2012) [#4]
Tested you code. Works fine on my PC


DruggedBunny(Posted 2012) [#5]
Does the executable file listed below actually exist on your system after it builds?

D:\MonkeyWorkspace\rmex\driver.build\glfw\vc2010\Debug\MonkeyGame.exe



Rixarn(Posted 2012) [#6]
@DruggedBunny, No, it doesn't. And that's the weird thing about this. Because when I roll back to Monkey v51 (That's the previous version I was using) it runs without a problem (that means the file exists when compiling with monkey v51). I'll try this update in my laptop and see what happens.

@Planiax, Thanks for testing. That makes it even more weird for me... What could be causing this?


therevills(Posted 2012) [#7]
Deleted your build folder after you updated to v54?


Rixarn(Posted 2012) [#8]
Just found the error! (At least about why the exe dissapears)

Avast was deleting the file without notice (silent gaming mode). The strange thing is that it didn't did that with previous files. It seems that for some reason it blacklisted the exe in that path and it gets detected as a Win32:MalOb-HC[Cryp] malaware... Now that I remember I updated avast yesterday.

Now I need to sort out the v54 GLFW bugs related to Memory Access Violation...


therevills(Posted 2012) [#9]
Maybe upgrade your Anti-virus software... I use to use Avast, but now use MSE :)


Rixarn(Posted 2012) [#10]
@therevills I'll try that antivirus, because I've never heard of it.

Well, now that I got past the point of running GLFW, I still have a problem with the app: it randomly crashes with an MAV (Memory Access Violation) ... The funny thing is that it doesn't show the debug output in the console, it just sais MAV and crashes. :/

Tried XNA and it runs fine. For me, it smells like a GC issue. I can post my demo app here, anyone interested in helping me test it on GLFW?


therevills(Posted 2012) [#11]
MSE = Microsoft Security Essentials

Post the demo, I'll give you a hand.


Rixarn(Posted 2012) [#12]
Thanks therevills!

http://www.smartb.mx/testapp.zip

It's a demo project I'm making as a documentation for my open source framework. Nothing near diddy tho :P


therevills(Posted 2012) [#13]
Okay, it happens to me too and in various (different) stages... sometimes on the loading screen, mostly on the start screen...

[edit 1]
Investigating the generated code (which I cant run in VC++), your error appears in the lang.cpp files:

case STATUS_ACCESS_VIOLATION:return "Memory access violation";


When I try to run the generated code in VC++, the window opens for a split second then closes and the console displays the following:



[edit 2]
Ignore the VC++ stuff, it happens with my stuff too :?


Rixarn(Posted 2012) [#14]
Thanks for testing therevills.

I think the VC++ stuff is because the generated project doesn't have those dll's in the project linker settings?

Anyway, the weird thing is the code runs fine on XNA and the rest of the targets, but fails for GLFW (and will fail probably for IOS) ... I'm really clueless about what to do :/


therevills(Posted 2012) [#15]
We need to try to find the area where the crash is happening and try to produce a small code sample for Mark.


DruggedBunny(Posted 2012) [#16]
I found that by adding Print "Drawing" to the start of mojo/graphics.monkey -> DrawImage and then clicking non-stop while running, I can get to see most of the screens up to the swords, though it varies per-run. It still crashes a little later, but you do get to click through a few screens!

So, a delay seems to allow it to get a little further at least. Perhaps it's trying to draw something before it's fully loaded?


therevills(Posted 2012) [#17]
Yep I found that too...


Rixarn(Posted 2012) [#18]
Thanks for helping James, I had a similar issue in BMax where a crash will occur kind of "randomly", and it happened quicker in release mode, and slower in debug mode. The problem back there was a GC issue with a 3rd party module integration.

As for monkey and my demo app, I made a test where I commented the swords drawing and it still crashes. The weird thing is that GLFW is the only target that crashes, all the other targets work fine and the closest one to GLFW(XNA)doesn't throw an MAV (Memory Access Violation) error...


DruggedBunny(Posted 2012) [#19]
I just wrote a little BMX program to add a Print statement after every method call (showing the method name) in the demo and module, but there's no consistent last method when it crashes (though RenderOut and RenderTransitionOut are quite common).

It does only seem to crash on a state change, though. If it manages to load a state and draw it (and you leave it alone) it doesn't crash...


Rixarn(Posted 2012) [#20]

If it manages to load a state and draw it (and you leave it alone) it doesn't crash...



You're right. It happens here too, sometimes it manages to get past the state change and it doesn't crash, although it's rare that I get past that point.


I just wrote a little BMX program to add a Print statement after every method call (showing the method name) in the demo and module, but there's no consistent last method when it crashes (though RenderOut and RenderTransitionOut are quite common).



Well, if there is no consistent last method when it crashes, it must be a GC issue. Or what else could it be?


marksibly(Posted 2012) [#21]
Hi,

Look like it might be something to do with the new incremental GC.

Try sticking this at the top of main.cpp:

#CPP_INCREMENTAL_GC="0"

Will look into it, but a smaller example would really help!


Rixarn(Posted 2012) [#22]
Thanks for the reply mark! Indeed setting the variable to 0 fixed the crash.

I will try to make a smaller code that keeps crashing, because the one on the demo app is the complete module I'm working on. Since it randomly crashes I don't know what part of the code I should replicate in a smaller version :/ ... But I will try something with passing object references between objects and see what happens :O


marksibly(Posted 2012) [#23]
Hi,

It may be something to do with arrays - can you think of anything 'creative' your code may be doing with arrays?!?


marksibly(Posted 2012) [#24]
Hi,

Yay, think I have this one nailed - turned out to be a relatively minor bug, but it took 4+ hours to find!


Rixarn(Posted 2012) [#25]
Yay! Thank you very much mark! I was about to make a post of the possible creative uses I was doing with arrays, but you already got it :)

Thanks. When I finish the testing I'll release the module with full documentation. So, i'm looking forward for the next version :) thanks again