On Apr 29, 2015 2:55 AM, "Dan Kennedy" <danielk1977 at gmail.com> wrote: > > On 04/29/2015 03:39 PM, Scott Robison wrote: >> >> On windows, malloc returns null if the allocation fails. Sqlite detects >> this and returns an error. >> >> On linux, malloc may return a non null yet invalid pointer and only fail >> when the memory is accessed because it wasn't really available. > > > That we're getting a segfault instead of SQLITE_NOMEM is not an SQLite bug. > > But that SQLite is requesting a ridiculously large allocation (assuming that is what is happening) is less than ideal as well though. Even if it's not technically a "bug".
Agreed. My point is only that it is not a bug that can be fixed by checking for null or some such. The algorithm fails on all 32 bit platforms for really large data sets. Windows & BSD (at least) appear to return a null pointer allowing the failure to be detected and handled gracefully. Linux by default makes that impossible with optimistic allocations. > It's just that working around the large allocation in question (if we're right about which one it is) is tricky to do. And tricky to test too. I'll get you some more data to verify my memory. > > Dan. > > > > > >> >> If Sqlite is not at fault when posix APIs lie about file locking, I don't >> think Sqlite is responsible when malloc lies about what should be >> considered a failed memory allocation which should return null. SDR
