[RLC]Data Execution Prevention? <solved>

[rhezalouis]

I am working on a particle toolbox (LÖVE 0.6.0; WinVista Bussiness). Somehow, the program is very likely to crash on exiting or on some minutes after it's started (either BufferOverflowException or AppCrash). The screenshot:

screenPrint

BEXerror.PNG (125.91 KiB) Viewed 2780 times

Windows indicates the error is caused by illegal memory access:

Buffer overflow exception

BEXError - Info.PNG (12.88 KiB) Viewed 2780 times

The debug report shows an unhandled exception:access violation at 0x017BF7A0 in love.exe which stores the CLC command (clear carry flag).

I thought it was the localization of the huge 'potion' table that causes the memory leakage; but as i remove the most significant localization, the program still crashes. I tried to turn off the DataExecPrevention service for the LÖVE.exe but the OS prohibits that. And moreover, the crash is not just BEX, but also Appcrash. Do you have any idea/suspect about why the program crashes?

If you don't mind, please try or read the program [sorry for the messy code]:

[RLC]potion0.1.love

LÖVE0.6.0

(29.45 KiB) Downloaded 119 times

Any corrections and suggestions about the program is welcomed.

Code: Select all

----------------------------------------[]
Readme
----------------------------------------[]
[RLC]Pötion: Particle Toolbox v0.1
Framework: LÖVE 0.6.0 Jiggly Juice
Copyright 2010 Rheza Louis
Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License
----------------------------------------[]
Buttons
----------------------------------------[]
[up]        Move particleProp selection up
[down]      Move particleProp selection down
[abc123,.?] Input parameter for the selected particleProp
[return]    Assign parameter to the selected particleProp
[bkspc]     Erase parameter
[shift+bksp]Clear commandLine
[f5]        Restart the programme
[escape]    Quit the programme
----------------------------------------[]
Command
----------------------------------------[]
"r"         Restart the programme
"q"         Quit the programme
"tcm"       Toggle colorMode
"tbm"       Toggle blendMode
"--"<str>   Load the chunk <str> and execute it
----------------------------------------[]
Acknowlegdement
----------------------------------------[]
Thanks to Marcelo Magalhães Macedo for the nice "monoMMM5.ttf" typeface.

[rhezalouis]

I had rewritten the code to check whether there was something I missed. But everything seemed fine (to me) and the program crashed still.

Curious, I rewritten the program again without any features other than reading the "particleProperty.txt", loading it to a table and then setting it to a single particle. Somehow, it still crashes on each execution (after sometime, longer than the earlier build). I avoided the LookUpTable which stores functions (prime suspect) and used the basic branching if-then-else. The entire Windows DEP system had also been kicked off

Code: Select all

bcdedit.exe /set {current} nx AlwaysOff

The DEP error didn't pop out but the APPCRASH error kept appearing instead.

The crash happened either:

1. quite sometime after the programme was started. I guess the error was related to the particleSystem memory access or something;
2. when either the close button or the "escape" key was pressed. Maybe there's something that alter the system so that the love.event.push('q') is not working correctly.

The crash used to happen when nothing is actually given to the programme [would that related to LÖVE's internal? Sorry if I'm wrong, I don't know LÖVE's internal working].

[rude]

Happens for me too. Will look into that.

[bmelts]

At least part of the problem, or so it seems to me, is the usage of characters in the conf.lua title setting that aren't UTF-8 - they look to be using Windows-1252 instead. Deleting that troublesome line from conf.lua solved the problems this .love was giving me on my Mac, though they manifested themselves differently than this thread describes happening on Windows.

[rhezalouis]

Happens for me too. Will look into that.

Hey, it's rude! It's been a while, how are you? Please take a look and send me some feedback.

At least part of the problem, or so it seems to me, is the usage of characters in the conf.lua title setting that aren't UTF-8 - they look to be using Windows-1252 instead. Deleting that troublesome line from conf.lua solved the problems this .love was giving me on my Mac, though they manifested themselves differently than this thread describes happening on Windows.

I am really sorry for yesterday's confusion. I knew that the ö is not OK to be used as working dir folder name; so I had changed all ö to the regular o. But I forgot the one on the conf file which 'somehow' causes the programme to be unclose-able in Anjo's MacOSX.

So, a few minutes ago I tried to download the files I have uploaded to fix the ö's. Finished updating the archive in my computer, I tried to execute the programmes, and an error pops:

... Can't find the typeLib.dll..

i.e. the programme somehow asks for a *.dll instead of the *.lua. Some how, now I couldn't reproduce the error. Windows suddenly "reviewed the error message and decided that it was his mistake"... . What's that?

The problem is still there however.

P.S. Ah, there's a problem with DEP on the bug tracker, too.

[rhezalouis]

The problem has been addressed by rude through irc a few days ago. The particle image was cleaned up during garbage collection. And on the next call, the particle:draw() requests the non-existent object (image), thus violating the memory access regulation. The different crash event is possibly caused by the uneven garbage collector cycle.

The fix has been appended to the new build here:*.zip, *.exe.

Thanks rude!

[rhezalouis]

Duh.

Potion0.4 ScreenCapture

potion0.4.png (478.5 KiB) Viewed 2602 times

[TechnoCat]

cool particle editor.