>>>>> On Wed, 04 Mar 2009 21:40:52 +0000, Tanguy Fautré said:
>
> We've figured the try/except modification was safe for the following
> reasons.
>
> - The traversal is read-only. Trapping an access violation/segfault in
> this case is safe (i.e. we do not modify an unknown memory location).
>
> - The try/except block breaks the inner loop, and the traversal moves on
> to the next heap list. This also avoids infinite loops.
>
> - The try/except block is mandated by the WinCE MSDN doc.
Agreed try/except looks like a safe way to catch this particular failure mode,
but the cause of the failure is unknown, so you can't say that it avoids
infinite loops. E.g. suppose that free heap blocks are chained together like
this:
struct freeblock {
struct freeblock *next;
...
}
Now suppose that some data structure is allocated from a free block with the
first word pointing to itself like this:
struct loopy {
struct loopy *self; /* Always points to this loopy itself. */
...
}
If the snapshot code is buggy, then Heap32Next might return the block itself,
so causing an infinite loop.
Moreover, the code in Heap32Next might get into a loop and never return in
some cases.
I'm not saying that these problems will deifnitely occur, but if they might
occur then OpenSSL should not be using Heap32Next in multithreaded programs.
__Martin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
