Ghost apps? Symbolic views that just won't go away.

[cyrille de brébisson]

Hello,

The calculator will perform a FS flush when you turn the calc off to make sure buffers are written out.

I doubt that flash bit changes are the cause, especially as the flash has a heavy error correction code (can correct up to 4 bad bit per 512 and detect a further 4 if I remember well).

The only thing that could, in theory cause the problem would be a crash/reboot after a delete as the FS would not flush at that point.

I did spend quite a bit of time on all that and could never find the issue.

The underlying OS is NOT chineese quality. This was prime G1. As was made evident by the bug in realloc which, for a while caused instability until I was able to find and prove that it was wrongly implemented*
The G2 uses FReeRtos.

Cyrille

*The giest of it is that a malloc would take 16 bytes minimum, with 8 bites allocated for the data. 8 bytes (header) was a doubely linked list of memory blocks, and, upon a (free) 8 bytes (formally data) was used as a doubly linked list of freed blocks.
So, allocate 20 bytes, the system would allocate 8+20=28 bytes. All good so far.
Then, do a realloc to REDUCE the block size to 4, the system WOULD do it, reducing the block to 8+4, and creating a new free block (16 bytes) with the freed space. (which is the core of the bug). Now, allocate 4 or 8 bytes. It would use the newly freed block, allocating all 16 bytes (minimum space). Now, free your original block (which is now only 8+4 bytes long), and it would write the freed block list, overriding the header of the 2nd block -> crash!
Took me 2 month of work, reverse engineering the malloc scheme (I did not have the sources) and building test cases to prove to the ODM that they was such a critical bug in their trusted OS that they had used for over 15 years on millions of products :-)