SASGIS - SAS.Планета
View Issue Details
0002610SAS.Планета[All Projects] Багpublic28-01-2015 10:4027-07-2015 20:47
Garl 
zed 
normalminorsometimes
resolvedfixed 
Windows7Professional
141212 
150915150915 
0002610: BerkeleyDB: Invalid floating point operation
При копировании из версионного беркли в обычный
поймал вот такую штуку.
Версионный кэш однозначно битый-перебитый, 10 раз исправленный. но работающий.

может можно игнорировать этот битый тайл и продложить а не вываливаться и ошибкой и прерывать поток.
BerkeleyDB, БД, версионный кэш, кэш
related to 0002611confirmed  Добавить обработку эксепшенов в копировании тайлов 
related to 0002771resolved zed Пропадают тайлы в версионном кеше беркли 
? 28-01-2015SASPlanet.Debug.elf (356,359) 28-01-2015 10:40
https://bugtracker.sasgis.org/file_download.php?file_id=1813&type=bug
log sdb.log (6,314) 28-01-2015 11:19
https://bugtracker.sasgis.org/file_download.php?file_id=1814&type=bug
log sdb_util.log (207,549) 30-01-2015 08:31
https://bugtracker.sasgis.org/file_download.php?file_id=1817&type=bug
Issue History
28-01-2015 10:40GarlNew Issue
28-01-2015 10:40GarlFile Added: 28-01-2015SASPlanet.Debug.elf
28-01-2015 11:17zedNote Added: 0015154
28-01-2015 11:19GarlFile Added: sdb.log
28-01-2015 11:34zedNote Added: 0015155
28-01-2015 11:42GarlRelationship addedparent of 0002611
28-01-2015 11:49zedRelationship replacedrelated to 0002611
28-01-2015 19:21zedNote Added: 0015159
29-01-2015 05:26GarlNote Added: 0015160
29-01-2015 07:36zedNote Added: 0015161
29-01-2015 07:40GarlNote Added: 0015162
29-01-2015 07:50zedNote Added: 0015164
29-01-2015 07:52GarlNote Added: 0015165
29-01-2015 08:03GarlNote Edited: 0015165bug_revision_view_page.php?bugnote_id=15165#r6385
29-01-2015 08:34zedNote Added: 0015166
29-01-2015 12:44GarlNote Added: 0015168
30-01-2015 07:22zedNote Added: 0015175
30-01-2015 08:20vdemidovStatusnew => confirmed
30-01-2015 08:20vdemidovProduct Version.Nightly => 141212
30-01-2015 08:20vdemidovTarget Version => 24xxxx
30-01-2015 08:31GarlFile Added: sdb_util.log
30-01-2015 08:41GarlNote Added: 0015181
30-01-2015 10:20zedNote Added: 0015184
30-01-2015 14:31GarlNote Added: 0015185
30-01-2015 17:09zedNote Added: 0015186
30-01-2015 17:24zedNote Added: 0015187
31-01-2015 20:42vdemidovStatusconfirmed => feedback
02-02-2015 07:28GarlNote Added: 0015214
02-02-2015 07:28GarlStatusfeedback => new
02-02-2015 07:57vdemidovStatusnew => feedback
03-02-2015 10:25GarlNote Added: 0015222
03-02-2015 10:25GarlStatusfeedback => new
03-02-2015 10:26GarlNote Added: 0015223
03-02-2015 11:35zedNote Added: 0015224
03-02-2015 11:43GarlNote Added: 0015225
04-02-2015 13:30zedNote Added: 0015226
04-02-2015 13:32zedStatusnew => resolved
04-02-2015 13:32zedFixed in Version => 150915
04-02-2015 13:32zedResolutionopen => fixed
04-02-2015 13:32zedAssigned To => zed
04-02-2015 13:33zedTarget Version24xxxx => 150915
04-02-2015 13:33zedSummaryInvalid floating point operation. => BerkeleyDB: Invalid floating point operation
04-02-2015 13:34zedTag Attached: BerkeleyDB
04-02-2015 13:34zedTag Attached: БД
04-02-2015 13:34zedTag Attached: версионный кэш
04-02-2015 13:34zedTag Attached: кэш
27-07-2015 20:47zedRelationship addedrelated to 0002771

Notes
(0015154)
zed   
28-01-2015 11:17   
Можно cделать обработку эксепшенов в TThreadCopyFromStorageToStorage при получении тайлов.

Но эта конкретная ошибка какая-то странная. Судя по всему у тайла контрольная сумма сошлась, но что-то пошло не так. Можешь sdb.log приложить?
(0015155)
zed   
28-01-2015 11:34   
Да, дела. В общем, как лечить Беркли и из-за чего там вылазит эта ошибка мне не понятно, поэтому тикет наверное можно оставить в подвешенном состоянии. А вот добавить обработку эксепшенов в копировании тайлов можно, но это уже "хотелка" и её бы в отдельный тикет вынести.
(0015159)
zed   
28-01-2015 19:21   
А кэш большой? Попробуй более-менее локализовать проблему: на каком зуме, в каком sdb файле. Потом сделай копию кэша, сделай ему Reset LSN и пришли мне тот sdb, чтобы я мог у себя воспроизвести баг и вылечить его.
(0015160)
Garl   
29-01-2015 05:26   
T:\cache_dbv\sat_all_v1\z18\78\46\313.186.sdbv - 3,799,575,552
весь кеш весит 42 гига.

проблемный тайл знаю, есть ещё 1 или 2 таких же.
z18
x80281
y47850

оно того стоит?
(0015161)
zed   
29-01-2015 07:36   
Хотелось бы докопаться до сути.
(0015162)
Garl   
29-01-2015 07:40   
просто 1 файл T:\cache_dbv\sat_all_v1\z18\78\46\313.186.sdbv + логи нам толку не дсат?
(0015164)
zed   
29-01-2015 07:50   
Да, этого вполне должно хватить. Только предварительно сделай db_recover, скопируй один sdb с логами в новую папку и проверь, что воспроизводится.
(0015165)
Garl   
29-01-2015 07:52   
(edited on: 29-01-2015 08:03)
сделал просто recover
1 файл базы + env вылеты есть

(0015166)
zed   
29-01-2015 08:34   
Жду ссылку на архив.
(0015168)
Garl   
29-01-2015 12:44   
https://cloud.mail.ru/public/35c8e558f3b5/test_dbv.7z
(0015175)
zed   
30-01-2015 07:22   
Что-то не хочет он у меня открываться. У тебя он db_verify проходит без ошибок?
(0015181)
Garl   
30-01-2015 08:41   
видать с ошибками.
кэш версионный это критично?
(0015184)
zed   
30-01-2015 10:20   
Понятно что версионный.
У тебя точно открывается то, что лежит в архиве? Какая прописана версия и по каким координатам открываешь?
(0015185)
Garl   
30-01-2015 14:31   
N43°37'23,42" E40°29'59,04"
зум 18

а после верифи - перестал вообще чего-либо показывать...
(0015186)
zed   
30-01-2015 17:09   
Странно, db_verify по-идее должен работать в режиме только чтения и никаких изменений в БД он не вносит.
(0015187)
zed   
30-01-2015 17:24   
В присланном тобой файле, начиная со смещения 0x35E00000 (это 862 Мб ровненько) идут сплошные нули. Поэтому он так хорошо и сжался. Возможно заглючил архиватор или ещё что. Проверь.

Контрольная сумма (md5): cc8fa8f9e38a87b8835410e7c1a33524 *313.186.sdbv
(0015214)
Garl   
02-02-2015 07:28   
ага файл получился битый, перепаковываю и перезаливаю.
баг всё ещё присутствует.
(0015222)
Garl   
03-02-2015 10:25   
как то так:
https://cloud.mail.ru/public/a59e89d02749/test_dbv.7z.004
https://cloud.mail.ru/public/835459c7f175/test_dbv.7z.003
https://cloud.mail.ru/public/498702348beb/test_dbv.7z.002
https://cloud.mail.ru/public/ebdbef5a67e5/test_dbv.7z.001
(0015223)
Garl   
03-02-2015 10:26   
а почему перестал после Верифи работать: оно переименовало файл в .bad
(0015224)
zed   
03-02-2015 11:35   
Ещё контрольную сумму дай на всякий случай.
(0015225)
Garl   
03-02-2015 11:43   
3893a20723c979fdb7e203a0d36adebd *z18/78/46/313.186.sdbv
(0015226)
zed   
04-02-2015 13:30   
Добавил пару дополнительных проверок, чтобы не падало при получении неожиданных данный, а просто удаляло невалидные записи. Вопрос о том, как там эти невалидные записи оказываются, остаётся открытым. У записей контрольная сумма сходится, zlib их нормально распаковывает, но внутри бывает мусор.

Возможно, кэш создавался во времена активной разработки Беркли, когда могли быть какие-то баги (тайлы рядом с "дырками" датируются концом 2013 г.). Если такое поведение с внезапным появлением дырок будет наблюдаться на текущих версиях SAS со свежим кэшем, нужно будет думать дополнительно.

О том, что из кэша удалены невалидные данные, будут записи в sdb.log вроде таких:

> 04-02-2015 15:29:16.460 EBerkeleyDBBadValue: Read meta-value element error - bad TileSize: -2140771306
> 04-02-2015 15:29:16.460 Broken Versioned Meta Data removed from db