Documentation Source Text

Check-in [20b925f012]
Login

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

Overview
Comment:Fix typos in the howtocorrupt.html document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 20b925f012a3900a5a57570a53666fb8fa3eeaf4a85780101de23a5ce5698299
User & Date: drh 2017-04-11 19:19:55
Context
2017-04-11
23:14
Fix a typo on the compile.html page. check-in: 5c613c450a user: drh tags: trunk
19:19
Fix typos in the howtocorrupt.html document. check-in: 20b925f012 user: drh tags: trunk
19:15
Update the JSON1 documentation to state the 2000-level limit on recursion. check-in: 0bcdcaff9c user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/howtocorrupt.in.

310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
...
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
...
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
...
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418

<p>We are told that in some flash memory controllers the wear-leveling logic
can cause random filesystem damage if power is interrupted during a write.
This can manifest, for example, as random changes in the middle of a file
that was not even open at the time of the power loss.  So, for example,
a device would be writing content into an MP3 file in flash memory when a
power loss occurs, and that could result in an SQLite database being
corrupted even though the database as not even in use at the time of the
power loss.</p>

<tcl>hd_fragment fakeusb</tcl>
<h2> Fake capacity USB sticks</h2>

<p>There are many fraudulent USB sticks in circulation that report to have
a high capacity (ex: 8GB) but are really only capable of storing a much
................................................................................
been instances where application code errors have caused SQLite to
malfunction subtly so as to corrupt the database file rather than
panicking.</p>

<p>The memory corruption problem becomes more acute when
using [memory-mapped I/O].
When all or part of the database file is mapped into the application's
address space, then a stray pointer the overwrites any part of that
mapped space will immediately corrupt the database file, without
requiring the application to do a subsequent write() system call.</p>

<h1> Other operating system problems</h1>

<p>Sometimes operating systems will exhibit non-standard behavior which
can lead to problems.  Sometimes this non-standard behavior is deliberate,
................................................................................
perform, the possibility of database corruption exists.</p>

<h2> Linux Threads</h2>

<p>Some older versions of Linux used the LinuxThreads library for thread
support.  LinuxThreads is similar to Pthreads, but is subtly different
with respect to handling of POSIX advisory locks.  SQLite versions
2.2.3 through 3.6.23 recognized that LinuxThreads where being used at
runtime and took appropriate action to work around the non-standard
behavior of LinuxThreads.  But most modern Linux implementations make
use of the newer, and correct, NPTL implementation of Pthreads.  Beginning
with SQLite [version 3.7.0] ([dateof:3.7.0]), the use of NPTL is assumed.
No checks are 
made.  Hence, recent versions of SQLite will subtly malfunction and may 
corrupt database files if used in multi-threaded application that run
................................................................................
<tcl>hd_fragment cfgerr cfgerrors*</tcl>
<h1>SQLite Configuration Errors</h1>

<p>SQLite has many built-in protections against database corruption.
But many of these protections can be disabled by configuration options.
If protections are disabled, database corruption may occur.

<p>The following are examples of disabling the built-in protections
mechanisms of SQLite:

<ul>
<li><p>Setting [PRAGMA synchronous=OFF] can cause the database to
go corrupt if there is an operating-system crass or power failure,
though this setting is safe from damage due to application crashes.








|







 







|







 







|







 







|







310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
...
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
...
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
...
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418

<p>We are told that in some flash memory controllers the wear-leveling logic
can cause random filesystem damage if power is interrupted during a write.
This can manifest, for example, as random changes in the middle of a file
that was not even open at the time of the power loss.  So, for example,
a device would be writing content into an MP3 file in flash memory when a
power loss occurs, and that could result in an SQLite database being
corrupted even though the database was not even in use at the time of the
power loss.</p>

<tcl>hd_fragment fakeusb</tcl>
<h2> Fake capacity USB sticks</h2>

<p>There are many fraudulent USB sticks in circulation that report to have
a high capacity (ex: 8GB) but are really only capable of storing a much
................................................................................
been instances where application code errors have caused SQLite to
malfunction subtly so as to corrupt the database file rather than
panicking.</p>

<p>The memory corruption problem becomes more acute when
using [memory-mapped I/O].
When all or part of the database file is mapped into the application's
address space, then a stray pointer that overwrites any part of that
mapped space will immediately corrupt the database file, without
requiring the application to do a subsequent write() system call.</p>

<h1> Other operating system problems</h1>

<p>Sometimes operating systems will exhibit non-standard behavior which
can lead to problems.  Sometimes this non-standard behavior is deliberate,
................................................................................
perform, the possibility of database corruption exists.</p>

<h2> Linux Threads</h2>

<p>Some older versions of Linux used the LinuxThreads library for thread
support.  LinuxThreads is similar to Pthreads, but is subtly different
with respect to handling of POSIX advisory locks.  SQLite versions
2.2.3 through 3.6.23 recognized that LinuxThreads were being used at
runtime and took appropriate action to work around the non-standard
behavior of LinuxThreads.  But most modern Linux implementations make
use of the newer, and correct, NPTL implementation of Pthreads.  Beginning
with SQLite [version 3.7.0] ([dateof:3.7.0]), the use of NPTL is assumed.
No checks are 
made.  Hence, recent versions of SQLite will subtly malfunction and may 
corrupt database files if used in multi-threaded application that run
................................................................................
<tcl>hd_fragment cfgerr cfgerrors*</tcl>
<h1>SQLite Configuration Errors</h1>

<p>SQLite has many built-in protections against database corruption.
But many of these protections can be disabled by configuration options.
If protections are disabled, database corruption may occur.

<p>The following are examples of disabling the built-in protection
mechanisms of SQLite:

<ul>
<li><p>Setting [PRAGMA synchronous=OFF] can cause the database to
go corrupt if there is an operating-system crass or power failure,
though this setting is safe from damage due to application crashes.