GLFW and v54
Monkey Forums/Monkey Programming/GLFW and v54
| ||
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. |
| ||
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. |
| ||
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 =( |
| ||
Tested you code. Works fine on my PC |
| ||
Does the executable file listed below actually exist on your system after it builds?D:\MonkeyWorkspace\rmex\driver.build\glfw\vc2010\Debug\MonkeyGame.exe |
| ||
@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? |
| ||
Deleted your build folder after you updated to v54? |
| ||
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... |
| ||
Maybe upgrade your Anti-virus software... I use to use Avast, but now use MSE :) |
| ||
@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? |
| ||
MSE = Microsoft Security Essentials Post the demo, I'll give you a hand. |
| ||
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 |
| ||
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 :? |
| ||
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 :/ |
| ||
We need to try to find the area where the crash is happening and try to produce a small code sample for Mark. |
| ||
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? |
| ||
Yep I found that too... |
| ||
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... |
| ||
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... |
| ||
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? |
| ||
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! |
| ||
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 |
| ||
Hi, It may be something to do with arrays - can you think of anything 'creative' your code may be doing with arrays?!? |
| ||
Hi, Yay, think I have this one nailed - turned out to be a relatively minor bug, but it took 4+ hours to find! |
| ||
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 |