News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Recursion making images dissapear! :(

Started by steadyeddy, February 20, 2011, 07:37:51 PM

Previous topic - Next topic

steadyeddy

Hi,
New to the forum.

I really need some assistance here. I'm recursing through the whole harddrive and displaying each file to the main GUI by posting a message from the thread.

This works fine for about 5 minutes then the images on my program start to vanish and the dialog turns grey!

Does anybody know why this is?

Image Attached.

Best Regards,
SE

dedndave

picture doesn't do much good
if i had to venture a guess, i would say you are eating up stack space - or otherwise hogging resources
but - recursion - 5 minutes - bad things - sounds like stack

dedndave

run the program
bring up the Task Manager - Performance tab
watch memory usage

steadyeddy

Performance is fine and the only thing that gets high is the CPU, nothing much else.

Is there a way to increase the stack size for the program? I think the default is 1MB.

Thanks.

oex

You dont want to change the stack size but instead fix the recursion *bug*....

It is difficult to give an answer without code.... There could be any number of reasons that you are getting this problem....
We are all of us insane, just to varying degrees and intelligently balanced through networking

http://www.hereford.tv

dedndave

well - if it isn't a resource issue, then maybe you are over-writing some data
memory usage seems more likely
when windows gets cramped for memory or, perhaps disk space, symptoms like you described can happen
as Peter said, it is hard to say without seeing some code

otherwise - get Olly debugger and see what you can find

MichaelW

As a quick and easy test you could use the linker /Stack option to increase the size of the stack. I would specify the same value for reserve and commit, and make the value at least 10000000. If this solves the problem then you know where to look. You can track the stack usage per recursion by saving the value of ESP on entry, and then within each recursion subtracting the current value of ESP from the entry value and displaying the result.
eschew obfuscation

steadyeddy

.386
.model flat,stdcall
.stack 10000000[10000000]

I tried this and it still happened.

It is recursing very deep thanks for the suggestions.

Dont really know how to solve this.

:red

jj2007

> .stack 10000000[10000000]

Afaik this gets ignored. Try the linker option. Try it with deliberately low stack values to identify the problem faster.

Edit: Tests reveal that .stack in the source code gets indeed ignored. Instead, the linker option works just fine:
/STACK:64,32 in the linker command line yields 20h reserved and 10h committed stack size according to peview.


clive

Well if the GUI is getting fouled up one should look for a resource leak (Pens, DC, etc). ie not releasing, or hogging.

Minimize stack usage as you descend. Dynamically allocate memory for large data items, generate diagnostics if the allocations fail. Keep track of what you are doing, or if you are getting into a circular loop. Instrument your code, and use tools like DebugView to keep track outside the GUI interface. Especially check for error and return codes from system interfaces.
It could be a random act of randomness. Those happen a lot as well.

hutch--

Rough guess it sounds like a resource issue, something you allocate from the OS that is not being released. Recursing a hard disk rarely ever gets more than about 20 iterations deep so I doubt its a stack issue. It is most likely a pen or a brush that is being selected and not being released as you step back down the recursion level. That will eat up all of your system resource if its handling a large number of separate calls.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

steadyeddy

I reduced the stack size as described and It still happened around the same time, so it doesn't seem like a stack issue.

.elseif auMsg==WM_CTLCOLORDLG ; custom color for the dialogbox
invoke CreateSolidBrush, 0FFFFFFh
ret

.elseif auMsg==WM_CTLCOLORSTATIC
mov eax,alParam
invoke SetTextColor,awParam , Black
invoke SetBkMode, awParam, TRANSPARENT
invoke SetBkColor, awParam, eax
invoke CreateSolidBrush, 0FFFFFFh
ret

.elseif auMsg==WM_CTLCOLORBTN
invoke CreateSolidBrush, 0FFFFFFh
ret


This is from the main GUI thread, and the recursion thread only sends messages to this thread to update the item it's working on.

So I need to send a message to update these as well?

Thanks for all your help guys.
   

MichaelW

The WM_CTLCOLORDLG, WM_CTLCOLORSTATIC, etc messages are sent each time the dialog or control is drawn, and you are creating a new brush each time. You should create the necessary brushes in the WM_INITDIALOG handler and save the brush handles for use in the WM_CTLCOLOR... handlers, and delete the brushes when you no longer need them, for example in the WM_CLOSE handler.
eschew obfuscation