Spliff
08-09-2022, 04:52 PM
I have 16 gb of RAM of which, most of the time, about 7 to 9 gb are not used / "needed". Thus, I can permit myself to have 6 or 8 UR files open / loaded concurrently, including ^x in one and ^v in another, and the like; this in general works smoothly, so this morning, too, and I just need more RAM than about 8 gb when lots of Firefox tabs are open (then FF may take 3, 4 gb alone), but this was not the case this morning, just 6 UR files, plus 4 or 5 FF tabs, and FreeCommander and AutoHotkey, nothing more, from a fresh start this morning. Thus, there were no general memory problems and there could not be, and needless to say, I never have any problems on my pc except within UR.
Now, from one of those 6 UR files (let's call it source.db), I wanted to separate one part, so I loaded a quite tiny 7th UR file (let's call it problem.db), saved it "as", i.e. under a new name (let's call it part.db), deleted its current content, and compacted-and-repaired it (i.e. the part.db, waiting for new content); then, from the file to be split up (i.e. source.db), I cut the part-to-be-separated, into part.db.
All this was smooth and without problems, so I had:
0.db = my main UR file
some other UR files
source.db = now without the "part" part
part.db = the ex "problem.db" I had previously renamed to part.db
(and problem.db, when and by "saving as" it, was relegated from work memory, back to file, i.e. remained unchanged on hdd)
Now, we have to observe that problem.db HAD been in memory for a short time (or even then had remained there, afterwards?), while I had "saved it as" it to part.db, and then, as "part.db" now, it had remained in memory, with its old, its "problem" content, while I, as described above, had deleted that old content, then doing the compact-and-repair: then only, that old, "problem" content (about 2,500 items) should have been flushed from memory, probably, but then, I don't know how UR manages memory, it seems it does NOT load the full files (when with 20,000 or more items) into memory?
Whatever, the "problem" content from problem.db had been discarded with problem.db from memory (untouched on hdd), and had been deleted and compacted from memory, and the source.db content had been split up between source.db and part.db (from which the "problem" content had been "compacted-out" previously, as described.
I then could not create any other new item within 0.db, and it remains locked.
From the above description, it should be clear that 0.db was in no way implicated into what I had done, 0.db had just and also been open within memory.
I have now spent the whole day with futile tries to repair 0.db, my backup being several days old and me having done lots of things in 0.db during the last days, but not also today, it just was in memory, as it always is my pc is "on".
It can't even be repaired by SysTools SQLite Database Recovery (150$), but I was able to copy all its content into a new db, which I then opened in Navicat, and Navicat shows me that the (original and current) problem.db content is mixed up into it, and this is confirmed by the respective item counts: The item count of the new db (as said, created from scratch and then filled with the copied-over contents of the locked 0.db) is the combined item count of the locked 0.db and the problem.db (problem.db is fine, as are source.db and part.db, the problem is just that its content has scrambled 0.db).
The above is a minute description of what I have done up to the disaster; it's obvious that either at the "save problem.db as part.db" (then with the "problem" content still, before further processing), or later on, perhaps when I then, after deletion of the problem.db content from part.db, "compacted-repaired" the part.db, that then-flushed "problem" content got mixed up with the 0.db content in memory, and at the next automatic "save" of 0.db, even 0.db's hdd copy got scrambled.
So, I "worked" on part.db, while 0.db was just open at the same time, and UR.exe obviously was administering both DB's work memory space, and obviously, UR's work memory administration went awry (memory allocation fault).
Now this might be a fault in my work memory, or a bug in UR.exe, while much more than just 2 gb of my work memory were used by my 6 or then 7 UR files, which totaled about 4 or 5 gb, and yes, I have to bars of 8 gb each, so it's possible that the work memory allocation of 0 was spread over both memory bars.
I have never had such file mix-ups with "third-party" data though, so that at this moment in time, I rather lean on thinking there might be a quite hidden bug in UR.exe, and which only shows in rare moments, and when the combined size of open UR's files is way over the late 32bit 2 or 3 gb memory limit.
This being said, Task Manager now tells me I use about 50 p.c. of my memory (i.e. again about 8 gb of 16, FF with 1,5 gb of that), with 2 p.c. CPU, and with my 6 UR files now open combine just under 50 MB of memory - obviously, when just "open", even very big UR files don't take much memory, but upon the copying of big datasets from one file to another, that should be quite different, as it should be upon compact-and-repair.
Fact is, there was no deliberate copying of the 2,500 "problem" items, into 0.db, and that data never has even been in 0.db - but it now is, and 0.db is definitely locked.
I see my UR files as tabs in one window, with just one but combined tab in the task bar (UR setting "Always one for each open database", but then combined into one by my Windows settings). So, one UR.exe is managing half a dozen of UR files concurrently, and their respective memory allocations, and then, with too much total file size (even on hdd) - since the number of open files obviously isn't the problem -, there might appear a rare problem?
EDIT
I was slightly mistaken above, my PC has got just 1, 16 gb, bar, the second slot is free (I have another PC which had only 8 gb, so I had bought a second 8 gb bar for that, so I confounded.
I just ran mdsched (the MS tool), took 30 minutes for 2 runs ("passes"), didn't give me a "result" anywhere (or I rather don't know where to find it), but I stared 30 minutes on the screen, for both passes, and both times from 1 to 99 p.c., and it always said, "No problems found yet.", up to and after second pass's 99 p.c., then it rebooted automatically.
I know that's not a proof "it's" not my pc, but it's a strong indication, together with the fact that I have never encountered such memory allocation problems in any other situation and especially with some other application involved.
Now, from one of those 6 UR files (let's call it source.db), I wanted to separate one part, so I loaded a quite tiny 7th UR file (let's call it problem.db), saved it "as", i.e. under a new name (let's call it part.db), deleted its current content, and compacted-and-repaired it (i.e. the part.db, waiting for new content); then, from the file to be split up (i.e. source.db), I cut the part-to-be-separated, into part.db.
All this was smooth and without problems, so I had:
0.db = my main UR file
some other UR files
source.db = now without the "part" part
part.db = the ex "problem.db" I had previously renamed to part.db
(and problem.db, when and by "saving as" it, was relegated from work memory, back to file, i.e. remained unchanged on hdd)
Now, we have to observe that problem.db HAD been in memory for a short time (or even then had remained there, afterwards?), while I had "saved it as" it to part.db, and then, as "part.db" now, it had remained in memory, with its old, its "problem" content, while I, as described above, had deleted that old content, then doing the compact-and-repair: then only, that old, "problem" content (about 2,500 items) should have been flushed from memory, probably, but then, I don't know how UR manages memory, it seems it does NOT load the full files (when with 20,000 or more items) into memory?
Whatever, the "problem" content from problem.db had been discarded with problem.db from memory (untouched on hdd), and had been deleted and compacted from memory, and the source.db content had been split up between source.db and part.db (from which the "problem" content had been "compacted-out" previously, as described.
I then could not create any other new item within 0.db, and it remains locked.
From the above description, it should be clear that 0.db was in no way implicated into what I had done, 0.db had just and also been open within memory.
I have now spent the whole day with futile tries to repair 0.db, my backup being several days old and me having done lots of things in 0.db during the last days, but not also today, it just was in memory, as it always is my pc is "on".
It can't even be repaired by SysTools SQLite Database Recovery (150$), but I was able to copy all its content into a new db, which I then opened in Navicat, and Navicat shows me that the (original and current) problem.db content is mixed up into it, and this is confirmed by the respective item counts: The item count of the new db (as said, created from scratch and then filled with the copied-over contents of the locked 0.db) is the combined item count of the locked 0.db and the problem.db (problem.db is fine, as are source.db and part.db, the problem is just that its content has scrambled 0.db).
The above is a minute description of what I have done up to the disaster; it's obvious that either at the "save problem.db as part.db" (then with the "problem" content still, before further processing), or later on, perhaps when I then, after deletion of the problem.db content from part.db, "compacted-repaired" the part.db, that then-flushed "problem" content got mixed up with the 0.db content in memory, and at the next automatic "save" of 0.db, even 0.db's hdd copy got scrambled.
So, I "worked" on part.db, while 0.db was just open at the same time, and UR.exe obviously was administering both DB's work memory space, and obviously, UR's work memory administration went awry (memory allocation fault).
Now this might be a fault in my work memory, or a bug in UR.exe, while much more than just 2 gb of my work memory were used by my 6 or then 7 UR files, which totaled about 4 or 5 gb, and yes, I have to bars of 8 gb each, so it's possible that the work memory allocation of 0 was spread over both memory bars.
I have never had such file mix-ups with "third-party" data though, so that at this moment in time, I rather lean on thinking there might be a quite hidden bug in UR.exe, and which only shows in rare moments, and when the combined size of open UR's files is way over the late 32bit 2 or 3 gb memory limit.
This being said, Task Manager now tells me I use about 50 p.c. of my memory (i.e. again about 8 gb of 16, FF with 1,5 gb of that), with 2 p.c. CPU, and with my 6 UR files now open combine just under 50 MB of memory - obviously, when just "open", even very big UR files don't take much memory, but upon the copying of big datasets from one file to another, that should be quite different, as it should be upon compact-and-repair.
Fact is, there was no deliberate copying of the 2,500 "problem" items, into 0.db, and that data never has even been in 0.db - but it now is, and 0.db is definitely locked.
I see my UR files as tabs in one window, with just one but combined tab in the task bar (UR setting "Always one for each open database", but then combined into one by my Windows settings). So, one UR.exe is managing half a dozen of UR files concurrently, and their respective memory allocations, and then, with too much total file size (even on hdd) - since the number of open files obviously isn't the problem -, there might appear a rare problem?
EDIT
I was slightly mistaken above, my PC has got just 1, 16 gb, bar, the second slot is free (I have another PC which had only 8 gb, so I had bought a second 8 gb bar for that, so I confounded.
I just ran mdsched (the MS tool), took 30 minutes for 2 runs ("passes"), didn't give me a "result" anywhere (or I rather don't know where to find it), but I stared 30 minutes on the screen, for both passes, and both times from 1 to 99 p.c., and it always said, "No problems found yet.", up to and after second pass's 99 p.c., then it rebooted automatically.
I know that's not a proof "it's" not my pc, but it's a strong indication, together with the fact that I have never encountered such memory allocation problems in any other situation and especially with some other application involved.