TX-VersaMail: Lockups?
x...@y.invalid
1) Get mail
2) Tap on the first unread message
VersaMail locks up - rendering the TX unusable until I do a soft boot.
Is it just me? (I have TealScript installed....)
--
PeteCresswell
Paul Nevai
:Seems like just about every time I
Patience... on my TX the lock-up lasts only about 15 to 30 secs. Then all is
back to normal. IMHO, this is just one of the many bugs resulting from the
NVFS implementation. I'd say this happens a couple of times a day.
/PaulN
P.S. Blazer does the same.
Gil Baron
>1) Get mail
>
>2) Tap on the first unread message
>
>VersaMail locks up - rendering the TX unusable until I do a soft boot.
>
>Is it just me? (I have TealScript installed....)
>--
Well I don't have the crash
Tealscript is a very possible cause.
Many developers don't code correxty for vfs devices. Tyica is locking code errors.
--
Gil W0MN
Bailar es vivir
Paul Nevai
:Many developers don't code correxty for vfs devices.
Yes, and that list of developers includes the makers of the built-in apps
such as VersaMail, Blazer, TomTom Navigator [not built-in but marketed by
Palm].
So why do the developers code incorrectly for NVFS devices? Is it possible
that because the NVFS code itself is defective? Just a guess. I wouldn't
know. I haven't seen the code.
Isn't it time to stop blaming the 3rd party developers? Let Palm and their
direct suppliers clean up their act first and then let they educated the
other developers so they can do it too. Doesn't this make sense? In the good
old times, developers used to have plenty of info coming from Palm. With OS
5, the situation has changed. Now "reverse engineering" and "guessing" is the
name of the game.
/PaulN
wood...@sonlightsoftware.com
Gil, you should know better than that (as one of my new Beta Testers)!
That is a mischaracterization of the issue!
> Is it possible that because the NVFS code itself is defective?
No, but a very convenient "grace" has been removed (out of
necessity)...
> Isn't it time to stop blaming the 3rd party developers?
Actually this problem is ENTIRELY the fault of bad programming.
NONE of the Palm tools (even now) will detect the problem and a quirk
of older non-NVFS devices let us "get away with it".
Here is what happened (and why).
In many memory managers there is a concept of handles. This is an
additional layer of indirection which allows the code/developer/app to
maintain a reference to an object in memory but frees up the memory
manager (OS) to move the object (data) around the memory space so long
as the code/developer/app is not accessing it.
It is like you asking me to hold your lunch. I write a "1" on your bag
and hand you a slip marked "1" and put your lunch in the bin marked "1"
and that's a fine system. But what if I need to change things around
for some reason, like I need bigger bins? Well then I can get the
bigger bins and number them any way I choose: let's say by letters. So
I move your lunch out of the "1" box and in that box I put a slip of
paper that says "Q" and move your lunch to the bigger box "Q". So long
as you are not at the counter asking for your lunch, I am safe to move
your lunch to any box I choose provided I update the letter on the slip
that is in box "1". When you go to the "1" box, you may find the note
saying your lunch is in the "Q" box. If you make note of this, change
your mind, go away and come back later and go straight to the "Q" box
without first checking the "1" box, you may be getting the wrong lunch!
You need to go to the "1" box first. It may very well still have "Q"
but if it has "Z", you need to know!
In the Palm OS, apps create a "number" box with MemHandleNew (and a few
other API calls) and the OS will create a private "letter" box that I
don't get to know unless I ask. I can get access to my memory which is
in the "letter" box (and prevent the OS from moving my memory around in
the "letter" boxes) by calling MemHandleLock and giving it my number.
At that point it is safe for me to do whatever i like to the memory (my
lunch). When I am done, I should call MemHandleUnlock to allow the OS
to move it around again. ONCE THE OS MOVES IT AROUND, THE "LETTER" I
GOT EARLIER IS NO LONGER VALID!!! When I am done, I call
MemHandleFree.
All of the non-NVFS devices will only move memory around (move the
lunch from the "Q" box to "Z" box) under very unusual circumstances
(such as exteremely low memory). Historically, a "number" has almost
always mapped to the same "letter". However, due to the particular
requirements of NVFS, this "rule of thumb" had to be broken. In
theory, it shouldn't matter because everybody should be using the
"numbers", not the "letters". In pratcice, however, many of us were
using the "letters" and some of us may not have even realized it. The
application I develop (http://www.PalmYanof.com), for example, was
written incorrectly from Day 1 and because of this, the original GPL
version is now essentially dead unless somebody fixes it (I have posted
the general fix in the Yahoo group if anyone is interested).
So you see what Palm did for NVFS *should* have been just fine because
nobody should have been doing it the wrong way. However, because there
are no tools to detect this problem and the memory almost never gets
moved, developers generally could not know if we had this problem in
our apps. That is until NVFS!
The bad programming that causes the problem is like this:
handle = DmQueryRecord(...);
ptr = MemHandleLock(handle);
MemHandleUnlock(handle);
read from ptr; // (typically only for VERY short period of time
after unlocking)
Alternatively one might have done this:
handle = MemHandleNew(...);
ptr = MemHandleLock(handle);
write to ptr;
MemHandleUnlock(handle);
read from ptr; // (typically only for VERY short period of time
after unlocking)
The results are bad enough like this but even worse if the app *writes*
to the memory!
> Let Palm and their direct suppliers clean up their act first
There is nothing to "clean up" for the released devices HOWEVER...
> and then let them educate the other developers so they can do it too.
Here is truly where Palm (or whatever they call themselves now) dropped
the ball.
I have suggested to Palm, through reasonable channels (their own
internal Usenet Groups) how this whole situation can be immediately
addressed. Just update the debug simulators such that all the APIs
that unlock memory (MemHandleUnlock, et.al.) watch for the lock count
to drop to 0. Whenever this happens, right after the APIs decrement
the count to 0, they should IMMEIDATELY MOVE THE DATA AND OVERWRITE THE
ORIGINAL MEMORY. Half of the time use a long sequence of NULLs and the
other half of the time put a horribly long string (something like, "YOU
ARE ACCESSING MEMORY THROUGH A POINTER WHOSE HANDLE IS NOT LOCKED!"
repeated a few times). This would virtually guarantee that offending
apps will either crash or have strange text output that would be
glaringly obvious during testing. I told Palm about this about a month
ago but sadly received no comment or any response. Too bad.
I *REALLY* think this would be in Palm's VERY best interest to expedite
this update because in my circles the TX is getting a very, Very, VERY
bad name as a crashing piece of junk when, in reality, it is careless
(but wholly ill-equipped, thanks to Palm's neglect at this point)
programmers who are to blame. This change would make it VERY, VERY
easy for us to find these bugs and get them fixed...
Keep in mind that my app has a SEVEN YEAR history of using code like
the examples and runs millions of gremlins and is used by thousands of
users with NO PROBLEM before the TX and LifeDrive were released!
As far as our app, I am almost done with version 3.2 which will fix
this mess for "New Yanoff". I appreciate everyone's patience as we
deal with this (it was not easy to figure out and is plaguing MANY
apps, as you well know). If your app is crashing, be sure to forward
this post to the developer (maybe he'll send me a free registration
key!) and they will be well on their way to fixing it. It couldn't
hurt to copy Palm on your email. Hopefully they will make this change
to the simulators soon...
wood...@sonlightsoftware.com
Make that "http://www.PalmYanoff.com" (with *2* 'f' chars)!
Ray Ingles
wrote:
> I have suggested to Palm, through reasonable channels (their own
> internal Usenet Groups) how this whole situation can be immediately
> addressed. Just update the debug simulators such that all the APIs
> that unlock memory (MemHandleUnlock, et.al.) watch for the lock count
> to drop to 0. Whenever this happens, right after the APIs decrement
> the count to 0, they should IMMEIDATELY MOVE THE DATA AND OVERWRITE THE
> ORIGINAL MEMORY. Half of the time use a long sequence of NULLs and the
> other half of the time put a horribly long string (something like, "YOU
> ARE ACCESSING MEMORY THROUGH A POINTER WHOSE HANDLE IS NOT LOCKED!"
> repeated a few times). This would virtually guarantee that offending
> apps will either crash or have strange text output that would be
> glaringly obvious during testing. I told Palm about this about a month
> ago but sadly received no comment or any response. Too bad.
I'm working on getting the Emulator v3.5 (for the old 68K devices)
compiled and running on Ubuntu Linux, and it definitely requires some
updates. I may see if I can do some tweaking to simulate this feature,
but I suspect the change would have to be made in the ROM image. They
already have debug versions of the ROMs (which are available to
registered developers), I agree this would be a very helpful feature
to add to them.
I'm not sure Palm wants to spend any time supporting the old Palms,
though. There's some hope it might be added to the Simulator (for the
ARM handhelds), though.
--
Sincerely,
Ray Ingles (313) 227-2317
Microsoft Windows - The joke that kills.
wood...@sonlightsoftware.com
> On 2006-01-13, wood...@SonLightSoftware.com <wood...@SonLightSoftware.com>
> wrote:
> I'm working on getting the Emulator v3.5 (for the old 68K devices)
> compiled and running on Ubuntu Linux, and it definitely requires some
> updates. I may see if I can do some tweaking to simulate this feature,
> but I suspect the change would have to be made in the ROM image. They
> already have debug versions of the ROMs (which are available to
> registered developers), I agree this would be a very helpful feature
> to add to them.
Yes, it would have to be in ROMs for the emulators but they don't
support the emulators anymore. The simulators have the ROMs built in.
It *could* be simulated, though. You have to man-in-the-middle the
*Handle*[Ll]ock* APIs. When *HandleUnlock* drops the count to zero,
make a private copy of the bytes and then replace them as I indicated.
Then when the app does a *HandleLock* when the count is 0, put the
bytes back the way they were (from your private copy) before you return.
Ray Ingles
wrote:
> *Handle*[Ll]ock* APIs. When *HandleUnlock* drops the count to zero,
> make a private copy of the bytes and then replace them as I indicated.
> Then when the app does a *HandleLock* when the count is 0, put the
> bytes back the way they were (from your private copy) before you return.
Sounds like a barrel of laughs. :-/ Still, I might see if I can do
something in my copious spare time. :-> Before I give up my Handera
330, either it or I will need to die, and I have some programs I want to
develop for it.
--
Sincerely,
Ray Ingles (313) 227-2317
"When your [profit] margins are more sensitive to Bill Gates'
pricing whims than they are the price of oil, that's an
untenable position for a large company to be in."
-- John Chapman Sr., BP Amoco Technology Executive
Ray Ingles
> On 2006-01-13, wood...@SonLightSoftware.com <wood...@SonLightSoftware.com>
> wrote:
>> It *could* be simulated, though. You have to man-in-the-middle the
>> *Handle*[Ll]ock* APIs. When *HandleUnlock* drops the count to zero,
>> make a private copy of the bytes and then replace them as I indicated.
>> Then when the app does a *HandleLock* when the count is 0, put the
>> bytes back the way they were (from your private copy) before you return.
>
> Sounds like a barrel of laughs.
The fun comes in keeping track of that memory if the OS *does* move
it. Hey, wait a minute - in looking through the Mem* calls, I note the
function "MemHeapScramble(heapID): The system attempts to move each
movable chunk. Useful for debugging." Ooh, and "MemSetDebugMode", though
it looks like some of the really useful commands have been neutered.
--
Sincerely,
Ray Ingles (313) 227-2317
"Anybody who has ever seen a photograph showing the kind of damage that
a trout traveling that fast can inflict on the human skull knows that
such photographs are very valuable. I paid $20 for mine." - Dave Barry
wood...@sonlightsoftware.com
Ray Ingles wrote:
> The fun comes in keeping track of that memory if the OS *does* move
> it.
So what? Before you return the pointer from your spoofed
*MemHandleLock* function (after you call the *real* *MemHandleLock*
function), you write the data that is supposed to be there into the
memory. You only care about tainting the memory where it USED TO BE.
If it moves or not, you don't care since you are going to be restoring
it to whereever it is (supposed to be)now (remember, you saved a copy
of the bytes).
Ray Ingles
wrote:
>> The fun comes in keeping track of that memory if the OS *does* move
>> it.
>
> So what? Before you return the pointer from your spoofed
> *MemHandleLock* function (after you call the *real* *MemHandleLock*
> function), you write the data that is supposed to be there into the
> memory. You only care about tainting the memory where it USED TO BE.
Good point. I would have thought of that once I sat down to do it. :->
If you have a working Emulator handy, can you check to see if
MemHeapScramble() does what it claims to? That'd be a decent tool to use
until the Emulator/Simulator did it natively...
--
Sincerely,
Ray Ingles (313) 227-2317
"Don't change horsemen mid-apocalypse!" - Bush's re-election slogan
Logan Shaw
A nice simple way to implement this would be to relocate the memory
immediately after the lock count drops from 1 to 0, then relocate it
again immediately before the lock count goes from 0 to 1.
- Logan
Gil Baron
>So why do the developers code incorrectly for NVFS devices? Is it possible