(from Jari's reply to Christopher)


The questions was because it's the connection between the doc window and the enigma document database that malfunctions before the overwrite bug strikes. And I would assume that the first place to look would be at places that in some way access the table (or array or collection or whatever the tecnical term might be in this case) that handles the mapping.
When this happens would most probably be when document windows are opened/closed or when dowcument windows are switched.
Plug-ins have limited access to this info as well (in Fin2003 I was able to cause a similar problem myself by writing a buggy plug-in).

Hi Jari,

I have been doing some reading and what you are saying here jibes (there's that word again) with some of the things I have been reading...So for those of us on the list with insomnia, here they are...

<http://www.embedded.com/story/OEG20020222S0026>

This part interested me... "One particular problem often arises when there is more than one pointer to a specific block. If the first entity owns the memory and wants to free it, then it must first consider whether any other pointers point at that location. If any do, and the first entity frees the memory, those other pointers become dangling pointers-pointers that point to space that is no longer valid. When the dangling pointer is used, you may happen to get the correct data, but eventually the memory will be reused (via another call to malloc()) leading to unpleasant interactions between the dangling pointer and the new owner of that piece of memory. A dangling pointer is the opposite of a leak."

So, in a low memory situation, memory will be reused more quickly as the system grasps for whatever it can get a hold of. Does this make sense?


This link is very interesting!! <http://www.embedded.com/2000/0004/0004feat2.htm>


<http://developer.apple.com/documentation/QuickTime/INMAC/MACWIN/imIntroMemMgmt.8.htm>

The above is an older article...so some of it is obsolete but many of the concepts still apply I believe. See heap fragmentation, dangling pointers, invalid handles (I think handles are now called events in OS X...but not completely sure) and low memory conditions.

"<http://homepage.mac.com/simx/mughelp/English/overview.html>

This is why OS X uses so much memory (from the above link): " Also, Mac OS X tends to eat up all available memory, even if there is a lot of it available. This is because Mac OS X caches as much data as it can in memory, so that it can potentially reuse that data without having to re-cache it (the UNIX term for caching data in memory is "paging in" memory). Mac OS X's performance drops when all available memory is used, because it has to start removing things from memory ("paging out"), which has a performance hit. This problem is much more prevalent in Mac OS X because applications are not limited to a specific amount of memory; they just take as much as they need, so free memory dwindles fast."


An "interesting" thing about the bug (based on the reports I've seen) here is that it always seems to point at another existing document database, never to a "wild" value.

This interests me too....


Anyway, I think you can avoid to get files overwritten by pressing Command+Shift+D (unsure about the keystroke here for the Mac, it should be the keystroke for "redraw" with the "Shift" key added to it) before saving the file.

In Mac this is command-D :-)

That will refresh the window contents based on the current data connected to the window (it will not use any buffers like "redraw" does). That should at least make it possible to assure that it's the correct data that will be written to the file.

I haven't tried this when the bug bites but if it happens again I certainly will try it.. What I have been doing is NOT saving documents in order to not corrupt the backups. Then I go to the backup folder and replace the files that have been overwritten with the intact backups.


The thing is...and maybe someone can either affirm or deny this for sure...on the Mac platform, the file is actually overwritten permanently rather than what happens in Windows if I am understanding correctly i.e. the information in the window being incorrect but not Command+Shift+D will restore it as you mentioned.

Thanks Jari...I'm curious to hear if any of this rings a bell for you..

-K
--
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale

Reply via email to