51557 2010-12-23 12:59:25 -0800 Visiting macnn.com often causes SQL spew via geolocation database 2011-07-28 07:59:11 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED InRadar P2 Normal --- 65289 1 simon.fraser steveblock commit-queue jorlow levin sam simon.fraser steveblock oldest_to_newest 326239 0 simon.fraser 2010-12-23 12:59:25 -0800 Sometimes, when loading macnn.com, I get this output on the console: ERROR: SQLite database failed to load from Cause - out of memory (/OpenSource/WebCore/platform/sql/SQLiteDatabase.cpp:70 bool WebCore::SQLiteDatabase::open(const WTF::String&, bool)) This is coming out of geolocation code: #0 WebCore::SQLiteDatabase::open (this=0x13739ad20, filename=@0x10bcc9008, forWebSQLDatabase=false) at /Volumes/InternalData/Development/webkit/OpenSource/WebCore/platform/sql/SQLiteDatabase.cpp:71 #1 0x000000010320e81c in WebCore::GeolocationPositionCache::readFromDatabaseImpl (this=0x10bcc8f10) at /Volumes/InternalData/Development/webkit/OpenSource/WebCore/page/GeolocationPositionCache.cpp:140 #2 0x000000010320ecb9 in WebCore::GeolocationPositionCache::readFromDatabase (cache=0x10bcc8f10) at /Volumes/InternalData/Development/webkit/OpenSource/WebCore/page/GeolocationPositionCache.cpp:132 #3 0x000000010320f504 in WebCore::CrossThreadTask1<WebCore::GeolocationPositionCache*, WebCore::GeolocationPositionCache*>::performTask (this=0x10bccd4c0, context=0x0) at CrossThreadTask.h:81 #4 0x000000010320ed29 in WebCore::GeolocationPositionCache::threadEntryPointImpl (this=0x10bcc8f10) at /Volumes/InternalData/Development/webkit/OpenSource/WebCore/page/GeolocationPositionCache.cpp:121 #5 0x000000010320ed57 in WebCore::GeolocationPositionCache::threadEntryPoint (object=0x10bcc8f10) at /Volumes/InternalData/Development/webkit/OpenSource/WebCore/page/GeolocationPositionCache.cpp:113 #6 0x0000000101a8d149 in WTF::threadEntryPoint (contextData=0x10bcbb0b0) at /Volumes/InternalData/Development/webkit/OpenSource/JavaScriptCore/wtf/Threading.cpp:65 filename is a null string. So: 1. Why is getting window.geolocatiaon spawning a thread and trying to open a database? 2. Why is the database path empty? 3. Why is the SQL error so totally bogus? 326240 1 simon.fraser 2010-12-23 12:59:44 -0800 <rdar://problem/8800389> 326270 2 steveblock 2010-12-23 13:56:43 -0800 Apologies. This was caused by http://trac.webkit.org/changeset/74354 I'll look into this ASAP, but please feel free to roll back my change if required. 327642 3 steveblock 2010-12-29 11:42:51 -0800 > 1. Why is getting window.geolocatiaon spawning a thread and trying to open a database? This thread is to handle reading from and writing to the database used to cache Geolocation positions. We start the thread as soon as the navigator.geolocation object is accessed so that it's ready when Geolocation is used. > 2. Why is the database path empty? This path can be set by calling GeolocationPositionCache::setDatabasePath(). It seems this is not called by the Mac port (Geolocation will work even without a cache). Prior to the refactoring in http://trac.webkit.org/changeset/74226, if the path is not set we early-out when trying to open the DB. Since that refactoring, if the path is not set we use an empty path so the DB open fails. I'll send a patch to restore the early-out behaviour to avoid the log spew. > 3. Why is the SQL error so totally bogus? I have no idea. I don't think this is specific to Geolocation. > Apologies. This was caused by http://trac.webkit.org/changeset/74354 It seems this is not the cause after all. 327647 4 77634 steveblock 2010-12-29 11:45:13 -0800 Created attachment 77634 Patch 327702 5 77634 sam 2010-12-29 14:24:15 -0800 Comment on attachment 77634 Patch Why are we hitting the cache when just fetching the geolocation object. This seems silly since people often fetch the geolocation object in feature detection, even if they are not using it. r=me. 327869 6 steveblock 2010-12-30 02:53:13 -0800 > Why are we hitting the cache when just fetching the geolocation object. The idea is to start the DB thread as soon as navigator.geolocation is accessed. Then when a Geolocation method is called, we potentially use a cached position if one is available, but we don't wait for the cache. If we don't start the DB thread until a Geolocation method is called, the cache will almost certainly never be used for this first method call. > This > seems silly since people often fetch the geolocation object in feature > detection, even if they are not using it. Really, do you think it's likely that people feature detect for a feature they don't plan to use? An alternative is to change the logic such that the DB thread is not started until a Geolocation method is called, but then have the Geolocation object wait for a cache response before instructing the GeolocationController to do work to get a position fix. This is a more involved change which could complicate the logic considerably. I'll look into it. 327876 7 77634 commit-queue 2010-12-30 03:32:31 -0800 Comment on attachment 77634 Patch Clearing flags on attachment: 77634 Committed r74794: <http://trac.webkit.org/changeset/74794> 327877 8 commit-queue 2010-12-30 03:32:37 -0800 All reviewed patches have been landed. Closing bug. 328184 9 simon.fraser 2010-12-31 09:09:40 -0800 (In reply to comment #3) > > 1. Why is getting window.geolocatiaon spawning a thread and trying to open a database? > This thread is to handle reading from and writing to the database used to cache Geolocation positions. We start the thread as soon as the navigator.geolocation object is accessed so that it's ready when Geolocation is used. I agree with Sam that this should not happen. Please file a bug on this too. > > 2. Why is the database path empty? > This path can be set by calling GeolocationPositionCache::setDatabasePath(). It seems this is not called by the Mac port Please file a bug on that. 328508 10 steveblock 2011-01-03 03:25:45 -0800 > I agree with Sam that this should not happen. Please file a bug on this too. Filed Bug 51814 > > This path can be set by calling GeolocationPositionCache::setDatabasePath(). > > It seems this is not called by the Mac port > Please file a bug on that. Filed Bug 51813. 77634 2010-12-29 11:45:13 -0800 2010-12-30 03:32:30 -0800 Patch bug-51557-20101229194511.patch text/plain 3032 steveblock SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA3NDc1MCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMjUgQEAKKzIwMTAtMTItMjkgIFN0ZXZlIEJsb2NrICA8c3RldmVibG9ja0Bnb29n bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IFZpc2l0aW5nIG1hY25uLmNvbSBvZnRlbiBjYXVzZXMgU1FMIHNwZXcgdmlhIGdlb2xvY2F0aW9u IGRhdGFiYXNlCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9p ZD01MTU1NworCisgICAgICAgIElmIHRoZSBHZW9sb2NhdGlvbiBwb3NpdGlvbiBjYWNoZSBkYXRh YmFzZSBwYXRoIGhhcyBub3QgYmVlbiBzZXQsIGVhcmx5LW91dAorICAgICAgICByYXRoZXIgdGhh biB1c2luZyBhbiBlbXB0eSBwYXRoIGFuZCB0aHVzIGZhaWxpbmcgdG8gb3BlbiB0aGUgZGF0YWJh c2UuCisgICAgICAgIFRoaXMgYXZvaWRzIFNRTCBsb2cgc3Bldy4KKworICAgICAgICBBbHNvLCBh dm9pZCBzdGFydGluZyB0aGUgZGF0YWJhc2UgdGhyZWFkIHVudGlsIHRoZSBwYXRoIGhhcyBiZWVu IHNldCwgYW5kCisgICAgICAgIHNob3J0ZW4gdGhlIHRocmVhZCBuYW1lIHRvIGF2b2lkIHdhcm5p bmdzIGR1ZSB0byBleGNlZWRpbmcgMzAgY2hhcmFjdGVycy4KKworICAgICAgICBObyBuZXcgdGVz dHMsIGltcGxlbWVudGF0aW9uIGNsZWFuLXVwIG9ubHkuCisKKyAgICAgICAgKiBwYWdlL0dlb2xv Y2F0aW9uUG9zaXRpb25DYWNoZS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpHZW9sb2NhdGlvblBv c2l0aW9uQ2FjaGU6OmFkZFVzZXIpOgorICAgICAgICAoV2ViQ29yZTo6R2VvbG9jYXRpb25Qb3Np dGlvbkNhY2hlOjpyZW1vdmVVc2VyKToKKyAgICAgICAgKFdlYkNvcmU6Okdlb2xvY2F0aW9uUG9z aXRpb25DYWNoZTo6c2V0RGF0YWJhc2VQYXRoKToKKyAgICAgICAgKFdlYkNvcmU6Okdlb2xvY2F0 aW9uUG9zaXRpb25DYWNoZTo6c3RhcnRCYWNrZ3JvdW5kVGhyZWFkKToKKwogMjAxMC0xMi0yOSAg QWxleGFuZGVyIFBhdmxvdiAgPGFwYXZsb3ZAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJldmll d2VkIGJ5IFl1cnkgU2VtaWtoYXRza3kuCkluZGV4OiBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb25Q b3NpdGlvbkNhY2hlLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb25Q b3NpdGlvbkNhY2hlLmNwcAkocmV2aXNpb24gNzQ3NDQpCisrKyBXZWJDb3JlL3BhZ2UvR2VvbG9j YXRpb25Qb3NpdGlvbkNhY2hlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNjAsNyArNjAsOCBAQCBH ZW9sb2NhdGlvblBvc2l0aW9uQ2FjaGU6Okdlb2xvY2F0aW9uUG9zCiB2b2lkIEdlb2xvY2F0aW9u UG9zaXRpb25DYWNoZTo6YWRkVXNlcigpCiB7CiAgICAgQVNTRVJUKG51bVVzZXJzID49IDApOwot ICAgIGlmICghbnVtVXNlcnMgJiYgIW1fdGhyZWFkSWQpIHsKKyAgICBNdXRleExvY2tlciBkYXRh YmFzZUxvY2sobV9kYXRhYmFzZUZpbGVNdXRleCk7CisgICAgaWYgKCFudW1Vc2VycyAmJiAhbV90 aHJlYWRJZCAmJiAhbV9kYXRhYmFzZUZpbGUuaXNOdWxsKCkpIHsKICAgICAgICAgc3RhcnRCYWNr Z3JvdW5kVGhyZWFkKCk7CiAgICAgICAgIE11dGV4TG9ja2VyIGxvY2sobV9jYWNoZWRQb3NpdGlv bk11dGV4KTsKICAgICAgICAgaWYgKCFtX2NhY2hlZFBvc2l0aW9uKQpAQCAtNzQsNyArNzUsNyBA QCB2b2lkIEdlb2xvY2F0aW9uUG9zaXRpb25DYWNoZTo6cmVtb3ZlVXNlCiAgICAgTXV0ZXhMb2Nr ZXIgbG9jayhtX2NhY2hlZFBvc2l0aW9uTXV0ZXgpOwogICAgIC0tbnVtVXNlcnM7CiAgICAgQVNT RVJUKG51bVVzZXJzID49IDApOwotICAgIGlmICghbnVtVXNlcnMgJiYgbV9jYWNoZWRQb3NpdGlv bikKKyAgICBpZiAoIW51bVVzZXJzICYmIG1fY2FjaGVkUG9zaXRpb24gJiYgbV90aHJlYWRJZCkK ICAgICAgICAgdHJpZ2dlcldyaXRlVG9EYXRhYmFzZSgpOwogfQogCkBAIC04NSw4ICs4NiwxMSBA QCB2b2lkIEdlb2xvY2F0aW9uUG9zaXRpb25DYWNoZTo6c2V0RGF0YWJhCiAgICAgTXV0ZXhMb2Nr ZXIgbG9jayhtX2RhdGFiYXNlRmlsZU11dGV4KTsKICAgICBpZiAobV9kYXRhYmFzZUZpbGUgIT0g bmV3RmlsZSkgewogICAgICAgICBtX2RhdGFiYXNlRmlsZSA9IG5ld0ZpbGU7Ci0gICAgICAgIGlm IChudW1Vc2VycyAmJiAhbV9jYWNoZWRQb3NpdGlvbikKLSAgICAgICAgICAgIHRyaWdnZXJSZWFk RnJvbURhdGFiYXNlKCk7CisgICAgICAgIGlmIChudW1Vc2VycyAmJiAhbV90aHJlYWRJZCkgewor ICAgICAgICAgICAgc3RhcnRCYWNrZ3JvdW5kVGhyZWFkKCk7CisgICAgICAgICAgICBpZiAoIW1f Y2FjaGVkUG9zaXRpb24pCisgICAgICAgICAgICAgICAgdHJpZ2dlclJlYWRGcm9tRGF0YWJhc2Uo KTsKKyAgICAgICAgfQogICAgIH0KIH0KIApAQCAtMTA1LDcgKzEwOSw3IEBAIEdlb3Bvc2l0aW9u KiBHZW9sb2NhdGlvblBvc2l0aW9uQ2FjaGU6OmMKIHZvaWQgR2VvbG9jYXRpb25Qb3NpdGlvbkNh Y2hlOjpzdGFydEJhY2tncm91bmRUaHJlYWQoKQogewogICAgIC8vIEZJWE1FOiBDb25zaWRlciBz aGFyaW5nIHRoaXMgdGhyZWFkIHdpdGggb3RoZXIgYmFja2dyb3VuZCB0YXNrcy4KLSAgICBtX3Ro cmVhZElkID0gY3JlYXRlVGhyZWFkKHRocmVhZEVudHJ5UG9pbnQsIHRoaXMsICJXZWJDb3JlOiBH ZW9sb2NhdGlvblBvc2l0aW9uQ2FjaGUiKTsKKyAgICBtX3RocmVhZElkID0gY3JlYXRlVGhyZWFk KHRocmVhZEVudHJ5UG9pbnQsIHRoaXMsICJXZWJDb3JlOiBHZW9sb2NhdGlvbiBjYWNoZSIpOwog fQogCiB2b2lkKiBHZW9sb2NhdGlvblBvc2l0aW9uQ2FjaGU6OnRocmVhZEVudHJ5UG9pbnQodm9p ZCogb2JqZWN0KQo=