Memory leak in 90.1866 (OS X) ?

Sometimes after running many queries across 6-8 tabs, if I don't watch the memory graph, I get a warning dialog suggesting that I close some tabs to free memory. However, all of that tabs listed are shown as using less than 1% memory _in total_. Closing tabs and this dialog result in it being redisplayed almost immediately. It becomes a challenge to close the dialog and exit DbVis to restart before the dialog reappears. Is it possible to add the garbage collection function when this dialog presents, or some other mechanism to restart the app in an orderly fashion? Perhaps an option to save files and restart from the dialog itself?

Hi Matt, Thanks for reporting this. You shouldn't have to restart DbVisualizer just because you get this dialog, just close enough tabs and/or stop tasks to get below the memory threshold to continue. When you click the Close button for a tab, the memory for that tab is released and garbage collection is done. Same thing when you stop a task. You can also click on the trash can icon in the memory monitor in the dialog to run garbage collection. Once you get below the memory threshold, the icon in the dialog's Continue button turns to a green checkbox. The memory listed for each tab is an estimate, but it should be fairly close. That said, this is a brand new feature so I would appreciate if you can tell us more about when this happens so we can fine tune it. Do you have a query returning lots of data running when this happens? Does stopping it release enough memory? Can you describe everything you have opened, with rough size info ("table with x rows and y columns", "a 2 MB script," "two monitors", etc)? A screenshot of the dialog may also help. Best Regards, Hans

I will capture some more data on the next occurrence, but it seems to be related to running queries many times in the same tab. For example, if I am working on a script to clean some dirty data, I may run a test query many times in the same tab. Memory consumption builds over time (many hours). I limit the rows returned to 1000, and the width of the row is usually less than 1KB.

The memory issue occurred again today, and I stopped all running queries and closed all open files, but continued to get the warning message. The only way to get DbVis operational was to restart the app. Screen shots of the process attached. Edited by: MattK on Nov 30, 2012 11:42 AM - screen shots show in the post in reverse order, but are named chronologically.

Hi Matt, Thanks for the screenshots. Unfortunately, they don't show more than that, as you said earlier, far from all memory is accounted for and it does not seem to be released by closing tabs/tasks. Which database/driver do you use? Can you describe a bit more about what you are doing when you see this? For instance, do you just edit a script and rerun it over and over or something else? Does the script create many result sets or just one? Do you pin any result sets or just recreate new ones for every run? Best Regards, Hans

> Which database/driver do you use? Using the DbVis supplied PostgreSQL driver connected to a PostgreSQL 9.2.1 database. > do you just edit a script and rerun it over and over In this case, yes. > Does the script create many result sets or just one? One result set. > Do you pin any result sets or just recreate new ones for every run? Recreate each time.

Hi Matt, Thanks for your help with tis. I still cannot reproduce it, so I hope you can give us more details. Could you post (or email) the DDL for the table or procedure involved, the script, and some sample data? Also any additional details about what you're doing when this happens, if any. Memory leaks are very frustrating so we would really appreciate your help in trying to find this one. Best Regards, Hans

It is happening once or twice a day now, with no discernable pattern of table, query, recordset size. The only common pattern I can identify is that I write a query, execute it, look through the recordset, alter the query, and repeat. This may go though many cycles, and thus I suspect that memory is getting unreleased with each query execution. My Max Rows is set to 10,000 rows, but I will try reducing that to 1,000. I often have 5-6 tabs open, but no more than two are frequently re-executed. The most annoying part, are the dialogs themselves. "High Memory Use Detected" itself is sufficient. But if I select Continue, after closing tabs and the memory issue persists (it always does), I am presented a modal "Still High Usage" dialog. This prevents me from getting to the garbage collection icon or quit in the menu quick enough, and after closing both dialogs, another memory dialog appears. Warning dialogs on top of error dialogs are cumbersome and unnecessary, and in a case today, required I force quit DbVisualizer, as I was not able get to the menu to execute a normal application exit. A single dialog for any error condition should be sufficient. I also want to day that the way DbVis 9.0 keeps even unsaved code across restarts has been a *fantastic* feature. Product: DbVisualizer Pro 9.0 Build: #1902 (2012/11/30 15:08) Java VM: Java HotSpot(TM) 64-Bit Server VM Java Version: 1.6.0_37 Java Vendor: Apple Inc. OS Name: Mac OS X OS Arch: x86_64 OS Version: 10.8.2 Edited by: MattK on Dec 5, 2012 1:18 PM

Here is one new detail: After running a SELECT query, I switched to another application, leaving DbVisualizer running in the background, but with no activity (all queries had completed execution). After about 5-10 minutes, the DbVis dock icon started to bounce, and when I switched back to DbVis, the memory warning dialog appeared, showing the last tab accesses using 10MB of memory. I closed this tab from the memory warning dialog, but the warning repeated, and I shutdown DbVis. Could there be a background process running when no queries are active?

Hi Matt, Thanks for all info. We are looking into what could be going on here. One last question: which Look and Feel do you use? Does switching to another help? Best Regards, Hans

Using Synthetica Standard (hoping for AluOxide someday!!!) Will switch to Mac OSX for a time and see what happens.

Hi Matt, Regarding background processes, there should not be anything of interest running (except the auto-save for SQL Commanders) unless you have monitors running. Could that be what's going on? Best Regards, Hans

No monitors. Just SELECT statements so far.

A quick experiment of running several times a query that returns ~25,000 rows in one tab brings the memory meter to about 200MB. Then another tab that was already open and previously used I execute "SELECT NOW();", and memory jumps to 230MB. While typing this reply, I have seen it move up to 240, 245, 249MB, and back to 230MB, without being touched. The garbage collector button brings it down to 170MB, and it climbs back to 200MB on without any additional interaction. The current limit shows as 505MB, so I am not getting any warnings currently - these details are just for information. Adding - up to 215MB and back to 180MB - without being the active application. Edited by: MattK on Dec 5, 2012 7:19 PM

More observations: While a query is executing, the memory use meter rises up 30-40 MB slowly, then drops back to the level at query start several times, before the DB server has finished the query and begun to send results. If a large record set is returned (~20K rows), and the same query is run but filtered to return only 10 rows, it appears the memory consumed by the recordset is not released, as the memory meter does not drop. Manually executing the garbage collector only releases about 10% of used memory.