|
2009-10-19
| ||
| 10:04 | • Closed ticket [94c04eaadb]: Crash in asyncRead() with large (>2GB) database file plus 2 other changes (artifact: 5332bbd487 user: dan) | |
| 07:50 | Use 64-bit arithmetic in the xRead() method of asyncRead. Fix for [94c04eaadb]. (check-in: ca3e41b057 user: dan tags: trunk) | |
|
2009-10-07
| ||
| 13:55 | • New ticket [94c04eaadb] Crash in asyncRead() with large (>2GB) database file. (artifact: 46c84addca user: dan) | |
| Ticket Hash: | 94c04eaadb5382b3859a50b94c5586e849bd92af | ||
| Title: | Crash in asyncRead() with large (>2GB) database file | ||
| Status: | Closed | Type: | Code_Defect |
| Severity: | Critical | Priority: | Immediate |
| Subsystem: | Extensions | Resolution: | Fixed |
| Last Modified: |
2009-10-19 10:04:01 15.71 years ago |
Created: |
2009-10-07 13:55:06 15.75 years ago |
| Version Found In: | 3.6.18 | ||
| Description: | ||||
I've encountered segmentation fault at sqlite3async.c:715. The problem
is on sqlite3async.c:712:
nCopy = (int)MIN(pWrite->nByte-iBeginIn, iAmt-iBeginOut); My actual numbers: iAmt = 16, iBeginOut = 2147844072. After subtraction we're getting -2147844056 or FFFFFFFF7FFA8028 in hex which after truncating to int gives 7FFA8028, a positive number. And it blows away the next check if( nCopy>0 ). | ||||