Liberty BASIC Community Forum
« Search Results »

Welcome Guest. Please Login or Register.
Aug 22nd, 2017, 5:20pm


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

--Liberty BASIC Resources--
Liberty BASIC Community WikiSpace
Frequently Asked Questions
Bay Six Software Forum
Liberty BASIC Home Page
Carl Gundel's Blog
Official Liberty BASIC Support
Liberty BASIC Programmer's Encyclopedia
Liberty BASIC on Rosetta Code

Search Results

Total results: 10


 1   Novice / Re: CLS and FLUSH confusion  on: Today at 3:08pm
Started by Turtleman | Post by Turtleman
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.
 
  Reply Quote Notify of replies

 2   Novice / Re: CLS and FLUSH confusion  on: Today at 3:01pm
Started by Turtleman | Post by Brandon Parker
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
 
  Reply Quote Notify of replies

 3   Novice / Re: CLS and FLUSH confusion  on: Today at 1:37pm
Started by Turtleman | Post by Turtleman
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.

 
  Reply Quote Notify of replies

 4   Novice / Re: CLS and FLUSH confusion  on: Today at 1:03pm
Started by Turtleman | Post by Rod
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.
 
  Reply Quote Notify of replies

 5   Novice / Re: CLS and FLUSH confusion  on: Today at 11:17am
Started by Turtleman | Post by Chris Iverson
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.
 
  Reply Quote Notify of replies

 6   Novice / Re: CLS and FLUSH confusion  on: Today at 10:56am
Started by Turtleman | Post by Turtleman
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.
 
  Reply Quote Notify of replies

 7   Novice / Re: CLS and FLUSH confusion  on: Today at 10:40am
Started by Turtleman | Post by Rod
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.
 
  Reply Quote Notify of replies

 8   API/DLL / Re: ListView color cells  on: Today at 10:11am
Started by metro | Post by NSbrown
Hello everyone
Has anyone been able to paint a specific cell? Can I see a sample code?
I can not figure it out
 
  Reply Quote Notify of replies

 9   Novice / Re: CLS and FLUSH confusion  on: Today at 04:27am
Started by Turtleman | Post by Turtleman
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!
 
  Reply Quote Notify of replies

 10   Novice / Re: CLS and FLUSH confusion  on: Yesterday at 11:00am
Started by Turtleman | Post by Brandon Parker
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
 
  Reply Quote Notify of replies


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