> 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. I tested it also on 64-bit platform (with sqlite.net) - and it causes the same OOM error. I can use all of my 32 GB, but I can't due to library limitations. IMHO it's a little bit incorrect. Maybe a simple solution exists like change int32 to int64 somewhere? >> 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 > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- ? ?????????, Artem mailto:devspec at yandex.ru
