-
pierre_le_riche committed revision 5 to the FastMM SVN repository, changing 1 files.
2009-11-09 22:56:39 UTC in FastMM
-
pierre_le_riche committed revision 4 to the FastMM SVN repository, changing 2 files.
2009-11-05 20:31:03 UTC in FastMM
-
pierre_le_riche committed revision 3 to the FastMM SVN repository, changing 3 files.
2009-09-22 13:25:07 UTC in FastMM
-
pierre_le_riche changed the public information on the FastMM project.
2009-09-11 10:30:13 UTC in FastMM
-
pierre_le_riche made 1 file-release changes.
2009-08-28 11:06:01 UTC in FastMM
-
pierre_le_riche made 2 file-release changes.
2009-08-28 11:05:01 UTC in FastMM
-
pierre_le_riche committed revision 2 to the FastMM SVN repository, changing 1 files.
2009-08-28 10:53:29 UTC in FastMM
-
If FastMM raises an exception (other than EOutOfMemory) then it means that the memory pool is corrupted and pretty much "all bets are off". Attempting any kind of recovery after that would be pointless. At that point the safest thing would be for the application to hang, otherwise you risk corrupting data further. (The memory pool is shared across threads, so if one thread corrupts the...
2009-08-19 21:39:12 UTC in FastMM
-
Exceptions raised by the memory manager vary from an access violation (for block corruptions) or an EOutOfMemory exception (for out of memory situations). Unfortunately I don't know what other advice to give you.
FastMM (which is basically the same as the default memory manager) is used in many production multi-threaded applications so I am still doubtful that it is a problem in the memory...
2009-08-19 19:21:30 UTC in FastMM
-
Hi Luigi,
I've gone through the code again - all the calls to LockMediumBlocks have a matching unlock. The only ways that I can see that it could get stuck in the LockMediumBlocks call is if you have either killed or suspended a thread while it was waiting to acquire a medium block lock. The other possbility is a memory error: If a memory error occurs then that can also happen. Do you trap...
2009-08-19 10:42:47 UTC in FastMM
