Memory use ramps up after saving > crash Topic is solved

[JonR]

Dan that's done. I will let you have anything useful/interesting.

Unless others have this issue it's not high priority. The lists are being saved ok before the crash (and as you suggested I do have all the precautions in place anyway).

Perspectives of complexity: Like everyone I seem to be playing whackamole with complex systems - health, car, computer etc. So as long as it's working I'm grateful..!

Jon

[abstr]

Thanks for your patience :)

[JonR]

Dan - an update! TDL crashed today with the logger on and I did some digging too. So I attached the log file ...

This time is a big change bc my primary TDL list called 0_0.TDL actually got reduced to zero file size. Maybe a consequence of the complexity of that file? I reinstated from the backup copy no problem -I mean it works fine when TDL is running. No problems at all.

Although the log says I was only working for ten mins - that is true but I had been working for a couple of hours before. The reason I restarted TDL was because I had opened /created a few lists - and also had set the tab colours on some -and I didn't want to lose that work if it crashed! Maybe there's some clue there because my subconcsious might be making a connection that I couldn't say for sure - e.g. colouring the tabs is risky??

My activities today haven't been heavy: some new items added. But perhaps also an issue I 'feel' rather than know is cutting and pasting between lists - even when the target list is 'mounted' already it seems to me there is an undue pause - and sometimes the TDL window will freeze with the message in the title bar 'xxx has stopped responding' or ... sorry I can't remember the words(!)

I attach an Excel wb with a log of what my relevant TDL file directories looked like at the time. Perhaps that might shed light on the sequence of events? e.g. csv export files were not all created as expected prior to the crash.

I also found an anomoly in the time log csv for 0_0 - but I have no idea what the connection would be to cause a crash: An item title I created by pasting from outside contained a tab symbol that was hidden (TDL doesn't show tabs apparently unless in edit mode?). This caused the columns in the log csv for that entry to be messed up.

Dan I am sorry to be a nuisance! I thought that something obvious might appear but I just don't know enough. Seeing the log file with so much Windows stuff going on blows my mind.

Thanks,

Jon

[JonR]

Dan - another twist - another crash. Just doing the same as before with same set of lists. The same behaviour (i.e. some part of the saving process is the trigger) but this time my 0_0.tdl remained intact.

(I had already removed the hidden tab symbol, but no idea if that is even an issue. It turns out there are many others I didn't know about hidden in titles. Do you think this is an issue? It would take a while but I could delete them.)

It's a longer logging file bc I had been working for longer? But I'm guessing the thing that matters is the last line...? 'zero seconds'...

I haven't mentioned memory for a while but wondering if the number of sheets open (14 in total with about 4 or 5 'mounted') - or the total size of the entire working set in memory - is an issue? Todays crashing perhaps marks a threshold of the number/size of open sheets? It has been a few days since the previous crash and I had been keeping the numbers low for that reason.

Also my layman observation that moving even a single item from one list to another seems to be an 'effort' for the PC... My old laptop actually revs up the fan to cope! One of the processor cores is at max for a while - Just now I saw the same behaviour a few mins before this crash - this time I wasn't moving anything but was in list mode and selecting a bunch of rows to reset priority of them all - it said 'not responding' for a few mins... but it eventually recovered and carried on.

That's all I can think of for now.

Thanks,

Jon

[JonR]

Dan

Just another layman input - my first instinct per the title of this thread still bothers me - and I observed it graphically again today - ie some activity during the save/backup/export process causes the memory use to shoot up. Why would it do that?

(Also a total aside - lots of memory is occupied during launch, seemingly ramping up as each list is launched. But during later use when a list that isn't 'mounted' is opened, the memory used doesn't seem to change? So what is the point of keeping lists unmounted? What are they doing which takes the time to open them?)

So anyway my work-around is to keep the lists to a minimum and monitor the memory rising and restart manually every few hours. I tested memory use for a blank list of 15mb or so and my complex core set of say 5 lists is around 90mb at startup. If It reaches 200mb then I know trouble is brewing.

Also without bleating on about my little problem too much.. did I mention I have a lot of custom fields and I realised these were being spread around my set of lists by copying items from the primary list to others (and so TDL kindly automatically imports the active custom fields from the source list to the destination list...).

But everything's still working, so not a big priority.

Thanks, Jon.

[abstr]

Hi Jon

If you're still having crashes could you experiment with disabling 'Auto-export-on-save'?

I can understand if this is an inconvenience because 'auto-export' forms part of your workflow but I've had another crash report that is hinting at a problem with this functionality. And if the two issues are the same then this might certainly account for memory leakage.

[JonR]

Dan Sorry for huge delay but yes I did stop auto-export to csv and not had any crashes since.

[abstr]

Thanks for the feedback Jon.

BTW if you decide to give auto-exporting another go when 8.0 (formally 7.3) is released it would be worth following these steps so that there is more technical info to send me when/if it goes belly-up again (originally from this Stack Overflow post).

This sort of info helped me fix another crash in 8.0 that I was otherwise unable to explain.