Documentation Source Text

Check-in [bf0de31094]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix typo in malloc.html.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: bf0de3109460d830a25d0bcdd56742e13de65088
User & Date: drh 2013-11-25 13:23:27.826
Context
2013-11-26
17:47
Add the double-to-int casting change to the change log. Set the release date (tenatively) to 2013-12-10. (check-in: 45cab1f685 user: drh tags: trunk)
2013-11-25
13:23
Fix typo in malloc.html. (check-in: bf0de31094 user: drh tags: trunk)
2013-11-21
23:43
Update the change log to mention recent VDBE performance enhancements. (check-in: 7113f9f169 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/malloc.in.
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
and the rest of SQLite.  The overlay passes most memory allocation
requests straight through to the underlying allocator and passes the
results back up to the requester.  But the overlay can be set to 
cause the Nth memory allocation to fail.  To run an OOM test, the overlay
is first set to fail on the first allocation attempt.  Then some test
script is run and verification that the allocation was correctly caught
and handled is made.  Then the overlay is set to fail on the second
allocation and the test repeats.  The failure point continues to advice
one allocation at a time until the entire test procedure runs to
completion without hitting a memory allocation error.  This whole
test sequence run twice.  On the first pass, the
overlay is set to fail only the Nth allocation.  On the second pass,
the overlay is set to fail the Nth and all subsequent allocations.</p>

<p>Note that the memory leak detection logic continues to work even







|







165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
and the rest of SQLite.  The overlay passes most memory allocation
requests straight through to the underlying allocator and passes the
results back up to the requester.  But the overlay can be set to 
cause the Nth memory allocation to fail.  To run an OOM test, the overlay
is first set to fail on the first allocation attempt.  Then some test
script is run and verification that the allocation was correctly caught
and handled is made.  Then the overlay is set to fail on the second
allocation and the test repeats.  The failure point continues to advance
one allocation at a time until the entire test procedure runs to
completion without hitting a memory allocation error.  This whole
test sequence run twice.  On the first pass, the
overlay is set to fail only the Nth allocation.  On the second pass,
the overlay is set to fail the Nth and all subsequent allocations.</p>

<p>Note that the memory leak detection logic continues to work even