Amplify the comment on renderLogMsg() that explains the problems associated

with calling sqlite3_log() from deep within the memory allocator.

FossilOrigin-Name: a73d7128fbca8dde5e90bd46ee915e39ae07dd1f

ext/ota/sqlite3ota.h

@@ -416,4 +416,3 @@ int sqlite3ota_create_vfs(const char *zName, const char *zParent);
 void sqlite3ota_destroy_vfs(const char *zName);
 
 #endif /* _SQLITE3OTA_H */
-

manifest

@@ -1,5 +1,5 @@
-C Further\srefine\sFTS5\scleanup\sin\sMakefiles.
-D 2015-07-14T21:56:53.776
+C Amplify\sthe\scomment\son\srenderLogMsg()\sthat\sexplains\sthe\sproblems\sassociated\nwith\scalling\ssqlite3_log()\sfrom\sdeep\swithin\sthe\smemory\sallocator.
+D 2015-07-14T22:43:37.988
 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f
 F Makefile.in 6e8af213d49e6325bf283ebed7662254f8e15bda
 F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23
@@ -217,7 +217,7 @@ F ext/ota/otacrash.test 8346192b2d46cbe7787d5d65904d81d3262a3cbf
 F ext/ota/otafault.test 8c43586c2b96ca16bbce00b5d7e7d67316126db8
 F ext/ota/otafault2.test fa202a98ca221faec318f3e5c5f39485b1256561
 F ext/ota/sqlite3ota.c 21575d86eac30482a9bfbb2a531f433015e0e03c
-F ext/ota/sqlite3ota.h 00028de37eede471ff1947d455cc3f33d3a911c6
+F ext/ota/sqlite3ota.h 4c66588429338b8977f33caa4c1d026d16fc383e
 F ext/ota/test_ota.c a876f88550d7d59a3ef62d4c1a5c04c4c2f1ebe1
 F ext/rtree/README 6315c0d73ebf0ec40dedb5aa0e942bc8b54e3761
 F ext/rtree/rtree.c 0f9b595bd0debcbedf1d7a63d0e0678d619e6c9c
@@ -323,7 +323,7 @@ F src/pcache1.c 3f4c87cf913f2de8189026d9a5223ddaf55eaf6b
 F src/pragma.c c1f4d012ea9f6b1ce52d341b2cd0ad72d560afd7
 F src/pragma.h b8632d7cdda7b25323fa580e3e558a4f0d4502cc
 F src/prepare.c 82e5db1013846a819f198336fed72c44c974e7b1
-F src/printf.c db11b5960105ee661dcac690f2ae6276e49bf251
+F src/printf.c 2bc439ff20a4aad0e0ad50a37a67b5eae7d20edc
 F src/random.c ba2679f80ec82c4190062d756f22d0c358180696
 F src/resolve.c 2d47554370de8de6dd5be060cef9559eec315005
 F src/rowset.c eccf6af6d620aaa4579bd3b72c1b6395d9e9fa1e
@@ -1365,7 +1365,7 @@ F tool/vdbe_profile.tcl 67746953071a9f8f2f668b73fe899074e2c6d8c1
 F tool/warnings-clang.sh f6aa929dc20ef1f856af04a730772f59283631d4
 F tool/warnings.sh 48bd54594752d5be3337f12c72f28d2080cb630b
 F tool/win/sqlite.vsix deb315d026cc8400325c5863eef847784a219a2f
-P 6db90ca2b4ac806b42532072ebe6b2a4a7b9713d
-R 8e7a1fc75fdd853e0505391914a90ba5
-U mistachkin
-Z 9c90a50d81f502459cfc9d381f2f84f0
+P b53a95063cf6b8ee8cad77e9fff4c50a356c43bb
+R 26006e835c43647146db287bec9bd4c4
+U drh
+Z dc5623ac8940b300cc2e3eac0d79ceed

manifest.uuid

@@ -1 +1 @@
-b53a95063cf6b8ee8cad77e9fff4c50a356c43bb
+a73d7128fbca8dde5e90bd46ee915e39ae07dd1f

src/printf.c

@@ -1012,6 +1012,11 @@ char *sqlite3_snprintf(int n, char *zBuf, const char *zFormat, ...){
 ** sqlite3_log() must render into a static buffer.  It cannot dynamically
 ** allocate memory because it might be called while the memory allocator
 ** mutex is held.
+**
+** sqlite3VXPrintf() might ask for *temporary* memory allocations for
+** certain format characters (%q) or for very large precisions or widths.
+** Care must be taken that any sqlite3_log() calls that occur while the
+** memory mutex is held do not use these mechanisms.
 */
 static void renderLogMsg(int iErrCode, const char *zFormat, va_list ap){
   StrAccum acc;                          /* String accumulator */