On Mon, Dec 1, 2014 at 5:46 PM, Hadley Wickham <h.wick...@gmail.com> wrote:
> Hi, > > I'm the maintainer of RSQLite, the R language binding for SQLite. > Recently, CRAN (the common R archive network) has started running all > R packages with USBAN. This reveals a problem in sqlite.c > ( > http://www.stats.ox.ac.uk/pub/bdr/memtests/UBSAN-gcc/RSQLite/tests/testthat.Rout > ) > > > library(RSQLite) > > con <- dbConnect(SQLite(), dbname = tempfile()) > sqlite/sqlite3.c:63931:5: runtime error: null pointer passed as > argument 2, which is declared to never be null > sqlite/sqlite3.c:63932:5: runtime error: null pointer passed as > argument 1, which is declared to never be null > I'm not sure what USBAN is, and a quick search using Firefox (which as of this morning takes me to Yahoo instead of Google) doesn't provide any clues. But apparently there is an issue in USBAN in that it does not allow calls to memcpy() and memset() with NULL pointers even it the count field (the third parameter) is zero. I couldn't find anything in the memcpy() or memset() documentation that disallowed this case. And SQLite has been doing that for many years on a huge variety of systems without any problems. So I think perhaps USBAN (whatever it is) is being a little overzealous in its constraints. > > The block of code that refers to is: > > if( p->azVar ){ > p->nzVar = pParse->nzVar; > memcpy(p->azVar, pParse->azVar, p->nzVar*sizeof(p->azVar[0])); > memset(pParse->azVar, 0, pParse->nzVar*sizeof(pParse->azVar[0])); > } > > So maybe the check should be on (pParse->azVar) ? > No, that would result in NULL pointer dereferences following an out-of-memory condition. The correct work-around (it isn't really a bug fix) is to test pParse->nzVar in addition to p->azVar. See https://www.sqlite.org/src/info/0d04f380e1bd17104b3cf76b64d0cfc79a726606 for the change. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users