Sign in to follow this  
Guest iholrf

looking for a gauge monitoring tool

Recommended Posts

seems i have porgramed a meory leak or something like it into one of my gauges in a panel i am working on. it is causeing fs9 to crash with the out of available memory error. i have tons of available memory and 80 gig or so of unused hd space. a 2 gig swap file. and it only happens with my panel. there are to many gauges to sort through useing remove and test type isolation. especially since from what i can gather from the net it can take hours to manifest the error. it usually happens to me with in 5 minutes so its a very big leak! what i need is some kind of utility to track this. or some insight as to a likely cause ( its outside my realm of experiance) i was adding to a bunch of gauges, when the problem showed up. i tried useing task manager, but the performance doesnt show anything, swap at 312mb, processor hovering around 5-10% ofcourse cntrl-alt-delete & alt-tab causes fs9 to pause so its not surprising that nothing shows up.

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi Have a look for a file called event_logger.zipthis will help with finding gauges which are firing all the timemaynot help with a memory leak but may point you to a gauge thats being naughtyWozza

Share this post


Link to post
Share on other sites

>seems i have porgramed a meory leak or something like it into>one of my gauges in a panel i am working on. it is causeing>fs9 to crash with the out of available memory error. i have>............> i tried useing task manager, but the performance doesnt show>anything, swap at 312mb, processor hovering around 5-10%>ofcourse cntrl-alt-delete & alt-tab causes fs9 to pause so its>not surprising that nothing shows up. Add more data columns to Task Manager. Under 'View - Select Columns'. You can add 'Memory Usage', 'Peak Memory Usage', 'Virtual Memory Size', etc. Which will be displayed for each 'Image' running, including FS9. While the 'Performance' tab shows 'Page File Usage', 'Available Memory', etc. 'Available ..' gets low if one is reaching the Page File limit. Ron

Share this post


Link to post
Share on other sites

You can also hit 'alt''enter' and run the sim in a window and watch the task managers snapins realime (or in my case, I run it in my other monitor to watch memory and so on). You can eliminate XML gauges for the most part as memory leaks and race conditions usually only occur in C, C++ based guages (macros aside).Also this error does not usually relate to main memory but GDI resources or kernel memory (what used to be called low mem). If you had a leak that was using up all main mem and the swapfile, the system would a) grow the swap file and warn you (assuming its not locked in size - which is not recommended), and :( slow to a crawl before crashing (with continual thrashing of the hard drive).So probably you are not so much dealing with a leak, but a race condition.Of course I may be completely wrong....CheersShad

Share this post


Link to post
Share on other sites

i am not familiar with the term race, but it sounds more likely then a leak, what ever it is it happens quickly. i lost a hard drive and a panel i had been working on for many months, bought a new and larger drive, rebult the gauges from memory in a batch of about 20, all in xml. when i put them in the panel i started getting this previously unseen error. (you have run out of available memory, flight sim will shut down, you may not have sufficent space on your hard drive...) thats about all i know, i have searched the web and found conjecture about the problem but little in the way of usefull help. the error only manifests itself with my panel. i removed all the new dial gauges and the crash stopped. the gauges are xml, the only 'c' gauges are from doug dawson and they are feild proven and worked fine before my crash, so it has to be in one of the dial gauges. i have looked at them and do not see a obvious problem. but i have over looked typos or missing spaces in the past and suspect is is some simple glitch causeing this. what are some likely cause of 'race' ?

Share this post


Link to post
Share on other sites

>months, bought a new and larger drive, rebult the gauges from>memory in a batch of about 20, all in xml. when i put them in>the panel i started getting this previously unseen error. (you>have run out of available memory, flight sim will shut down,>you may not have sufficent space on your hard drive...) >thats about all i know, i have searched the web and found>conjecture about the problem but little in the way of usefull>help. the error only manifests itself with my panel. i removed>all the new dial gauges and the crash stopped. the gauges are>xml, >... what are some likely cause of 'race' ? I'd assume a 'race' is when two bools have to be in a specific sequence, but due to programming details and delays, they can run in the wrong sequence. -- I've never heard of a 'race' in programming, but they were common problems in digital circuits. FS 'XLM' is very fragile, one never knows what some detail might change. Usually my text window just goes blank. is INVALID! You can't have '--' inside such a comment! So, if one comments out XML code with a decrement, '--' in it, the gauge is messed up. However, using (* .... *) around some code blocks I wanted to disable also gave me trouble at times. I was experimenting with loops in XML, and it seems something I did resulted in FS9 crashing to the DT. It may have been an attempt to put a loop macro inside another loop. Since FS XML is stack oriented in RPN, and I suspect the stacks are directly converted to CPU stack space, it's possible a CPU stack grows without limit in system memory. Since the address space if 'flat', and covers all Memory, real and virtual, it could be that all your available memory gets eaten by some accidental XML loop. When one runs out of virtual memory, XP may lock up. And take a hard reset to get out of. I use a 'c' to clear the stack at the top at the top of c .... blocks. However, that won't stop an infinite loop, it's just a safeguard to clear the stack from what might remain of previous operations. An unacceptable character in a string also messes up FS XML. But I've only seen a text window go blank in such cases. All I can think of here is look at your commented blocks for what I mentioned above. Actually, putting: 0 if{ code to disable .... } Appears to be safe. Also, it could be some 's0' in a macro is conflicting with reg 0 outside the macro. Resulting in indeterminate operations. Same goes for accidental L:Vars with the same names. You might have to leave out one XML gauge at a time to try to find which one is causing the problem. Ron

Share this post


Link to post
Share on other sites

> I use a 'c' to clear the stack at the top at the top of >>> > > c> .... >>>> blocks. However, that won't stop an infinite loop, it's>just a safeguard to clear the stack from what might remain of>previous operations.I cannot agree more with you here. I think most people are not aware of the importance of that "c" when dealing with advanced XML gauges, because there is a common idea that the stack's composition is valid for only one line of code in ,,etc tags; which is not true. Even "s" registers are shared by all of the included in a I found this not too long ago after much struggling with some of my complex macros that causes FS to hung without "visible" reason.> Also, it could be some 's0' in a macro is conflicting with>reg 0 outside the macro. Resulting in indeterminate>operations. Same goes for accidental L:Vars with the same>names. This is quite true as well.Tom

Share this post


Link to post
Share on other sites

THANKS RON. the 'c' idea is a good one and i will take it to heart. i believe my self that my problem is along the lines you mention.i found a typo in my code ( i have a habit of pasting snipets from other gauges or the sdk in my gauge for referance when im am writting, like notes. i found a "..) }> at the end of a long if{ calculation i neglected to delete, the extra > did not get caught by the xml editor and it did not stop the gauge from working. when i started making gauges i was hoping to find a way to build my house board by board, now i know a better analogy is grain of sand by grain. looks like i have a pile of sand to sort through, no short cuts. i am wondering though, if the problem can be more complex. my panel has forward and lookdown views, there is about 30% overlap meaning that many of the gauges in the forward view are also in the lookdown view. the 8 or so gauges i removed in order to stop the crash are amoung those repeated. with only the forward view containing the gauges, i do not get the crash. adding the same gauges in the lookdown panel and CRASH! seems odd to me that it takes the pair to crash fs9, but it does appear to be the case. i used the key logger, and nothing odd showed up, i did not realize that keypad 0-number used to make a view sticky created a repeating sequence of key strokes lasting as long as the view remained sticky. i do not use many bit operators, or macros....im not that good a programer. the ones i use like for radio channel setting are copy and pasted from arne bartels posts above. i appreciate the insight and help, and i have got the offending gauge isolated in a group of 8 or so, worst case i will just redo all 8.

Share this post


Link to post
Share on other sites

>the 'c' idea is a good one and i will take it to heart. >i believe my self that my problem is along the lines you>mention. Doesn't hurt to c(lear) the stack now and then. Regardless, finding FS XML errors can be really difficult. I have mainly one 800 line 'Test Base.xml' gauge that often gets messed up. 'CookTop' checks if an XML file is 'well formed'. Which sometimes catches a problem. However, it appears to save the XML file whenever the edit window is killed; which means it may change or add some escape characters to one's code. >i found a typo in my code ( i have a habit of pasting snipets>from other gauges or the sdk in my gauge for referance when im>am writting, like notes. i found a "..) }> at the end of a>long if{ calculation i neglected to delete, the extra > did>not get caught by the xml editor and it did not stop the gauge>from working. I found a "-->" at the end of one macro that wasn't balanced. It didn't mess up the file, either. But, it certainly could have.>.......... i am wondering>though, if the problem can be more complex. my panel has>forward and lookdown views, there is about 30% overlap meaning>that many of the gauges in the forward view are also in the I have no idea.> ......... i do not use many bit>operators, or macros....im not that good a programer. the ones>i use like for radio channel setting are copy and pasted from>arne bartels posts above. I get confused by the post fix bool conditions, add that to confusion about how to do some things and I just work on something else for the time being. I haven't done gauges for panels, rather I mainly keep enhancing my Jet Test gauge to calculate and show more and more things. Which gives me ideas for useful XML coding. Ron

Share this post


Link to post
Share on other sites

jet test gauge? sounds interresting. another observation, can placing a gauge partially off screen cause problems? i started adding back some of the dial gauges to my 'veiw down panel, to watch the task maneger while fs9 was in windowed mode. and the ASI caused a crash, nothing showed up on task manager. or it was such an instantanious event that there was no time to record it. the asi gauge is only half way visible in 'view down' --- when i moved it to center screen ( on a hunch ) it does not cause the crash...makes me think its in the panel config....or is that nuts?

Share this post


Link to post
Share on other sites

i could have sworn that i had placed gauges partially off screen before, but with all gauges totally onscreen, the problem disappeared. strange and unusual! thank the responders for thier insight, and i really like the info about clearing the stack!

Share this post


Link to post
Share on other sites

>i could have sworn that i had placed gauges partially off>screen before, but with all gauges totally onscreen, the>problem disappeared. strange and unusual! thank the>responders for thier insight, and i really like the info about>clearing the stack!As you've now discovered, XML gauges cannot be set partially "off screen" without serious consequences... In most cases, the worst thing that can happen is that the gauge won't appear at all; in the more rare instances they can indeed engender a sim crash.Here are some practical "tips" for locating errors in XML guages. If you have a "Reload" gauge installed on your main window, start the sim and click the "Reload" gauge to unlock the .xml files for editing.Load your XML file into wordpad, and begin a process of "divide and conquest..." IOW, selectively highlight sections of code and Ctrl-X to cut-n-paste to the buffer, Save the result, minimize wordpad, then click "Reload" in the sim again.Is the problem still there? If so, then the offending code is still present.Maximize wordpad and immediately press Ctrl-Z to reinsert your previously cut code back to the file. Now, select another portion and repeat the process.Once you've identified which "half" of the code contains the problem, then you can narrow the process by "halving" again, rinse and repeat as required until you've found the problem... ;)

Share this post


Link to post
Share on other sites

>i am not familiar with the term race, but it sounds more>likely then a leak, what ever it is it happens quickly. i lost>a hard drive and a panel i had been working on for many>months, bought a new and larger drive, rebult the gauges from>memory in a batch of about 20, all in xml. when i put them in>the panel i started getting this previously unseen error. (you>have run out of available memory, flight sim will shut down,>you may not have sufficent space on your hard drive...) from http://searchstorage.techtarget.com/sDefin...i871100,00.html"A race condition is an undesirable situation that occurs when a device or system attempts to perform two or more operations at the same time, but because of the nature of the device or system, the operations must be done in the proper sequence in order to be done correctly.In computer memory or storage, a race condition may occur if commands to read and write a large amount of data are received at almost the same instant, and the machine attempts to overwrite some or all of the old data while that old data is still being read. The result may be one or more of the following: a computer crash, an "illegal operation," notification and shutdown of the program, errors reading the old data, or errors writing the new data. This can be prevented by serialization of memory or storage access, such that if read and write commands are received close together, the read command is executed and completed first, by default.In a network, a race condition may occur if two users attempt to access an available channel at the same instant, and neither computer receives notification that the channel is occupied before the system grants access. Statistically, this sort of coincidence is most likely to occur in networks having long lag times, such as those that use geostationary satellites. To prevent such a race condition from developing, a priority scheme must be devised. For example, the subscriber whose username begins with the earlier letter of the alphabet (or the lower numeral) may get priority by default when two subscribers attempt to access the system within a prescribed increment of time. Hackers can take advantage of race-condition vulnerabilities to gain unauthorized access to networks.Race conditions occasionally occur in logic gates when certain inputs come into conflict. Because the gate output state takes a finite, nonzero amount of time to react to any change in input states, sensitive circuits or devices following the gate may be fooled by the state of the output, and thereby caused to not operate properly."CheersShad

Share this post


Link to post
Share on other sites

And From wikipediahttp://en.wikipedia.org/wiki/Race_condition"A race hazard (or race condition) is a flaw in a system or process where the output exhibits unexpected critical dependence on the relative timing of events. The term originates with the idea of two signals racing each other to influence the output first."There are lots of things that can cause a race condition in a C esp when dealing with threads.CheersShad

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this