Dan Kennedy <danielk1...@...> wrote: > > On Mar 2, 2010, at 6:54 PM, Jonathan Kew wrote: > > > I've run into what appears to be a small bug in this function (from > > sqlite3.c, v 3.6.22). Suggested patch: [snip] > > > > The issue here is that when k reaches zero, the access to escarg[i] > > may try to look one byte beyond the end of the allocated buffer; to > > avoid this, simply reverse the order of the tests so that k is > > checked for non-zero first. > > > > The error is normally harmless, testing a "random" byte and then > > exiting the loop anyway because of the value of k, but it can cause > > a bus error in the (extremely rare) event that the buffer is > > allocated exactly at the end of a virtual memory page, and the > > following page is unallocated. (This was encountered when running > > under Guard Malloc.) > > Shouldn't escarg[] contain a nul-terminated string?
Yes, I wondered that too when I looked at it again later. In which case the code ought to be safe. > How did you provoke the error under Guard Malloc? Do you > have a stack trace? I'm thinking the error might be caused > by some bug in the caller. This occurred during starting up a debug build of Firefox. No specific action appeared to provoke it, the application was loading its "history" db, etc. Unfortunately, I don't have a backtrace saved, and when I tried again yesterday, it did not recur. I did confirm at the time that the bus error was due to the attempt to read escarg[i], and that k had reached zero, which was why I jumped to the conclusion that it was an incorrectly handled edge case. But if it's true that escarg[] should always be a nul-terminated string (are you confident of this? I haven't studied the code to check where it comes from), then I'd agree that this appears to point to a bug in the caller rather than in sqlite itself. Thanks, Jonathan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
