Liberty BASIC Community Forum
« CLS and FLUSH confusion »

Welcome Guest. Please Login or Register.
Jan 22nd, 2018, 5:54pm


Rules|Home|Help|Search|Recent Posts|Notification


« Previous Topic | Next Topic »
Pages: 1 2 3  Notify Send Topic Print
 veryhotthread  Author  Topic: CLS and FLUSH confusion  (Read 844 times)
Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5618
xx Re: CLS and FLUSH confusion
« Reply #15 on: Aug 21st, 2017, 10:38am »

Its called FACTORIL.bas in the sample programs that ship with Liberty. Click on help in the ide then tutorials then click on the open file icon and you will get the list of sample programs stored in %appdata%\Liberty BASIC V4.5.1

I forgot to ask, delete your error.log, run the program till it crashes then let us see the error.log entry that shows the correct time and date for the crash, copy and paste it here.
User IP Logged

Brandon Parker
Moderator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1123
xx Re: CLS and FLUSH confusion
« Reply #16 on: Aug 21st, 2017, 11:00am »

on Aug 20th, 2017, 7:15pm, Jim Hiley wrote:
I think that memory usage will increase steadily until LB does it's 'garbage collection'

I have an application that has a similar issue.

I don't know of any way to force LB to do it's garbage collection.
You could try pausing the program periodically during the run and see if that allows the memory usage to drop.

Jim



There is no way to trigger Liberty BASIC's garbage collection that I am aware of.

That being said, once a program has been started and is running through it's normal paces it should not just continuously build allocated memory.

When Subs/ Function are entered they build on the stack, but if they are exited properly those chucks should be reclaimed eventually by the garbage collection. In the event that Sub/ Functions are entered and they never exit (i.e. endless recursion) this can cause the build-up of memory.

Loops should be exited properly and NEVER jumped out of with a GoTo statement; this can cause memory leaks as well.

When passing strings to DLL's "as ptr" I always append a chr$(0) to the end of the string to force Liberty BASIC to pass the string By Reference instead of By Value. This will ensure that the DLL works on the single copy of the string.

We really need to see some code to help get to the bottom of this unless it is really obvious from the Error.log that Rod requested.


{:0)

Brandon Parker
« Last Edit: Aug 21st, 2017, 11:01am by Brandon Parker » User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
Turtleman
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 187
xx Re: CLS and FLUSH confusion
« Reply #17 on: Aug 22nd, 2017, 04:27am »

It's very rare that I find anything OBVIOUS in the error log, but here's the latest after the program went down after 966,000 simulations! (I would have posted sooner, but naturally, when you want it to crash, it doesn't. LOL) For this run, I did not have any of the several other windows open just the basic control panel. I hope someone can make sense of this:
-----
Error log timestamp Monday 08/21/17 04:28:05 PM\
Runtime error: Invalid device context (DC) handle. ( OS error 16r591 )

Error(Exception)>>grinefaultAction
Error(Exception)>>activateHandler: <anUndefinedObject>
Error(Exception)>>handle
Error(Exception)>>signal
Error class(Exception class)>>signal: <'Invalid device conte...'>
LibGraphPane(Object)>>osError: <1425>
LibGraphPane(Object)>>osError
LibGraphPane(Window)>>releaseDC: <aDeviceContext>
RecordingPen(GraphicsTool)>>release
RecordingPen>>release
LibGraphPane(GraphPane)>>close
LibGraphPane(BasicGraphPane)>>close
[] in Window>>close
[] in IdentityDictionary>>grino:
LinearIdentityHashTable(LinearInlineHashTable)>>keysAndValuesDo: <aBlockClosure>
IdentityDictionary>>grino: <aBlockClosure>
BasicApplicationWindow(Window)>>close
BasicApplicationWindow(ApplicationWindow)>>closeViewOverride
BasicApplicationWindow>>closeOverride
BasicWindow>>close
[] in BasicProgram>>closeAll
LinearHashTable>>elementsDo: <aBlockClosure>
Set(HashedCollection)>>grino: <aBlockClosure>
BasicProgram>>closeAll
BasicProgram>>terminateRun: <anError>
[] in BasicProgram>>errorHandlerBlock
ExceptionHandler>>evaluateResponseBlock: <aBlockClosure> for: <anError>
[] in ExceptionHandler>>handle:
ProtectedFrameMarker(BlockClosure)>>setUnwind: <aBlockClosure>
BlockClosure>>invisibleEnsure: <aBlockClosure>
ExceptionHandler>>handle: <anError>
ExceptionHandler>>findHandler: <anError>
Error(Exception)>>activateHandler: <anExceptionHandler>
Error(Exception)>>handle
Error(Exception)>>signal
Error class(Exception class)>>signal: <'The handle is invali...'>
LibButton(Object)>>osError: <6>
LibButton(Object)>>osError
LibButton(ControlPane)>>controlColor: <0>
BasicApplicationWindow(Window)>>controlColor: <3084210> hDC: <0>
BasicApplicationWindow(Window)>>wmCtlcolorbtn: <0> with: <3084210>
NotificationManager>>notify: <aWinMessage>
NotificationManager>>notifyRecursive
NotificationManager>>recursiveMessage
SystemDictionary>>recursiveMessage
SystemDictionary>>launch
LibButton(Window)>>setWindowText: <'RUNNING'>
LibButton(ControlPane)>>contents: <'RUNNING'>
LibButton>>writeItem: <'RUNNING'>
LibButton(SubPane)>>writeItemCr: <'RUNNING'>
-----
Thanks for offering to take a look!
User IP Logged

Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5618
xx Re: CLS and FLUSH confusion
« Reply #18 on: Aug 22nd, 2017, 10:40am »

OK, in your program do you change the color of a button at any point? How are you doing this? With an API call?

The error log is telling us that the program tried to change the background color of a button but found it did not exist. The window it was on might have been closed, but I would have thought you would get a #handle not known error.


This might still be the symptoms of out of memory, but if you are changing buttons with API calls that could also be the memory leak.

Are you changing the color of buttons? Setting focus on a button probably changes its background color.
User IP Logged

Turtleman
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 187
xx Re: CLS and FLUSH confusion
« Reply #19 on: Aug 22nd, 2017, 10:56am »

No, not changing any button colors! Some graphicbox colors are data dependent, but certainly not anything that wouldn't show up within the first hundred or so simulations. How hundreds of thousands or even a million simulations can run before crashing still has me stumped. I just got through restricting the number of sims to 100,000, so perhaps I'll disable most or all graphicbox writes just to see if it makes a difference.
User IP Logged

Chris Iverson
Administrator
ImageImageImageImageImage


member is offline

Avatar

20% Cooler


Homepage PM

Gender: Male
Posts: 2294
xx Re: CLS and FLUSH confusion
« Reply #20 on: Aug 22nd, 2017, 11:17am »

I'm not sure if I'm remembering properly, but isn't there an issue in LB with issuing COLOR commands? The brushes not getting deleted properly, with the memory usage building up because of it?

I seem to recall something like that. I'll try to take a look.
User IP Logged

"Do you believe in destiny?" - Pyrrha Nikos, RWBY
"With what wish will your Soul Gem shine?" - Kyubey, Puella Magi Madoka Magica
Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5618
xx Re: CLS and FLUSH confusion
« Reply #21 on: Aug 22nd, 2017, 1:03pm »

We need to see what that long color number is in rgb terms and see if it matches anything you are doing in the program.

3084219 in r g b terms

Not got time right now but later unless someone beats me to it.
User IP Logged

Turtleman
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 187
xx Re: CLS and FLUSH confusion
« Reply #22 on: Aug 22nd, 2017, 1:37pm »

It's premature and inconclusive, but after disabling writing to the four graphicboxes that can change colors, and successfully running a million sims, overall memory usage is about the same as before.

If it offers any clues, the only changeable LB colors are: green, red, cyan, dark green, dark red, and blue depending on simulation results. The investigation continues.
« Last Edit: Aug 22nd, 2017, 1:39pm by Turtleman » User IP Logged

Brandon Parker
Moderator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1123
xx Re: CLS and FLUSH confusion
« Reply #23 on: Aug 22nd, 2017, 3:01pm »

I think that's red'ish color code there.....

So are you saying that the memory usage is the same after running over a million simulations as it was prior to starting the simulations?

That definitely points to something with graphics obviously if that's the case.

Without seeing some code it's still guesswork for the most part.


{:0)

Brandon Parker
User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
Turtleman
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 187
xx Re: CLS and FLUSH confusion
« Reply #24 on: Aug 22nd, 2017, 3:08pm »

No, and sorry for the confusion. Memory usage starts at around 11M and gradually increased to around 35M after a million sims similar to what the memory usage was before disabling writing to the displays. There are several other sections I may be able to "bypass" to see what's causing the increase. That's assuming that memory usage should stabilize at a much smaller number of sims, though I don't know if memory usage even enters into the equation.
User IP Logged

Brandon Parker
Moderator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1123
xx Re: CLS and FLUSH confusion
« Reply #25 on: Aug 22nd, 2017, 7:17pm »

Sounds like there is still a problem....

It's normal for memory to go up/ down as the program allocates more and then discards it for various tasks. For instance, my main program which is almost 16,000 lines long hovers between 20-22MB; if it climbs any higher than that I know I've caused a problem. I added code that saves the memory allocated to a CSV file every second if commanded to and it's pretty much like clockwork with the up/ down pattern.

Another good place to look, while the program is running through its paces, is Task Manager. You can go to the Processes tab and then add the "Commit Size" under the View>Select Columns... menu option. Pay attention to the Commit Size as your program is running. The number assigned to your program should increase/ decrease as the program's memory is allocated/ freed, but in the event that you only see this number steadily increasing over a long period of time and never dropping back down close to where it started shortly after initializing the simulations then you definitely have a memory leak.

What else are you doing inside the loops for simulations?

Can you post any code?

We want to help you make your program run as best it can and having a memory leak is a definite issue that can be difficult to track down.


{:0)

Brandon Parker

User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5618
xx Re: CLS and FLUSH confusion
« Reply #26 on: Aug 23rd, 2017, 04:40am »

Ok, if we are running out of memory the errors are likely to be many fold and you are unlikely to get the same error.log report again. So it will help if you log the error reports and the memory use at the time of the error.

If the same error repeats then we are far more likely to have a program flow error.

I think what you said in the last post or two is that stopping drawing makes no difference to the memory use it keeps climbing. The error seems to be random and not dependent on reaching an actual memory limit.

The reason the program stopped last time is that the Device Context it was trying to write to did not exist, the handle was 0, it should have been a large number. So either Windows had run out of resources to support the program or we had a coding error.

Windows can run out of all sorts of resources, memory, handle names, text space...

So are you using API code anywhere in your program to manage anything?

Where in your program are you using this color.

Code:
    WindowWidth = 800
    WindowHeight = 600
    open "test" for graphics_nsb as #draw
    #draw "trapclose [quit] ; down"
    'A decimal value for rgbcolor may be set with the following formula:
    'rgbcolor = redValue + (greenValue * 256) + (blueValue * 256*256)
    'reverse the process
    c=3084219
    b=int(c/(256*256))
    c=c-b*256*256
    g=int(c/256)
    r=c-g*256
    #draw "fill ";r;" ";g;" ";b
    #draw "place 100 100 ;\Red ";r;" ;\Green ";g;" ;\Blue ";b

    wait

[quit]
    close #draw
    end

 
« Last Edit: Aug 23rd, 2017, 04:52am by Rod » User IP Logged

Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5618
xx Re: CLS and FLUSH confusion
« Reply #27 on: Aug 23rd, 2017, 04:50am »

@Chris yes, there used to be an issue with color change but I think it might have been fixed.

Turtleman, issuing color change commands selects a new "brush" in Windows, old "brushes" should be deleted if not required. But I think that issue was fixed so probably a red herring.

As a side note, to avoid issuing all the color change commands, create colored segments and redraw the segment you wish. So keep three or four permanent segments and delsegment the final variable one. That way you issue only three or four color change commands but can redraw colored segments millions of times without creating or using any new resource.

Probably something to do if and when we prove it is drawing that is causing the problem.

User IP Logged

Turtleman
Full Member
ImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 187
xx Re: CLS and FLUSH confusion
« Reply #28 on: Aug 23rd, 2017, 11:58am »

Getting closer! There are two basic modes for running simulations. In the READ mode, simulations use previously STORED data. In the NEW mode, (which is what I've been describing in this thread) fresh data is generated and saved in an array as it's used. The number of simulations can be anywhere between 1 and 1 million. But not knowing how many data points might need to be saved, the array is rather small and automatically dumps its contents to a temporary HDD file every 50,000 data points or around 10,000 sims. Then the array is cleared and the process repeats as necessary. When simulations have been completed, the user may decide whether or not to transfer the temporary data to any of 20 "permanent" files. This ping-pong approach is used, since dimensioning an array for a million sims would slow things down, as would constantly writing to HDD.

While troubleshooting, when the just described storage technique was disabled, memory usage occasionally "jumped" upwards, but otherwise was ROCK STABLE! Why the sudden increase from, say 11.5M to 13M and then maybe to 15M and ending up higher is still a mystery; but again, except for the jumps, memory usage no longer fluctuates like it did before. However, if simulations are paused, memory usage doesn't go back down, but stays where it was. Obviously, something is very wrong with the way new data is being stored in the temporary array and transferred to the temporary HDD file. And how that relates to the crashes and some of the error log items is another mystery. (Then again, the real cause of problems could lie somewhere else!)

To compound things further, I tried optimizing LB with an old memory management program called "Minimen," and memory usage immediately drops and remains at a very stable 2.5 - 3M (not a typo).

It looks like it's back to the drawing board for storing newly generated data. Any suggestions?

« Last Edit: Aug 23rd, 2017, 11:59am by Turtleman » User IP Logged

Brandon Parker
Moderator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1123
xx Re: CLS and FLUSH confusion
« Reply #29 on: Aug 23rd, 2017, 12:53pm »

I think it should be pointed out that just because the simulation is paused does not mean that the garbage collector will be triggered to run nor does it mean that any memory is ready to be discarded by the program. When you pause it you are just temporarily forcing the program to wait at a specific spot in the code.

It still would benefit everyone trying to help if we could at least see parts of the code.


{:0)

Brandon Parker

User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
Pages: 1 2 3  Notify Send Topic Print
« Previous Topic | Next Topic »

Rules|Home|Help|Search|Recent Posts|Notification

Donate $6.99 for 50,000 Ad-Free Pageviews!

| |

This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls