SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002610SAS.Планета[All Projects] Багpublic28-01-2015 10:4027-07-2015 20:47
ReporterGarl 
Assigned Tozed 
PrioritynormalSeverityminorReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformWindowsOS7OS VersionProfessional
Product Version141212 
Target Version150915Fixed in Version150915 
Summary0002610: BerkeleyDB: Invalid floating point operation
DescriptionПри копировании из версионного беркли в обычный
поймал вот такую штуку.
Версионный кэш однозначно битый-перебитый, 10 раз исправленный. но работающий.

может можно игнорировать этот битый тайл и продложить а не вываливаться и ошибкой и прерывать поток.
TagsBerkeleyDB, БД, версионный кэш, кэш
Attached Files? file icon 28-01-2015SASPlanet.Debug.elf [^] (356,359 bytes) 28-01-2015 10:40
log file icon sdb.log [^] (6,314 bytes) 28-01-2015 11:19
log file icon sdb_util.log [^] (207,549 bytes) 30-01-2015 08:31

- Relationships
related to 0002611confirmed Добавить обработку эксепшенов в копировании тайлов 
related to 0002771resolvedzed Пропадают тайлы в версионном кеше беркли 

-  Notes
(0015154)
zed (manager)
28-01-2015 11:17

Можно cделать обработку эксепшенов в TThreadCopyFromStorageToStorage при получении тайлов.

Но эта конкретная ошибка какая-то странная. Судя по всему у тайла контрольная сумма сошлась, но что-то пошло не так. Можешь sdb.log приложить?
(0015155)
zed (manager)
28-01-2015 11:34

Да, дела. В общем, как лечить Беркли и из-за чего там вылазит эта ошибка мне не понятно, поэтому тикет наверное можно оставить в подвешенном состоянии. А вот добавить обработку эксепшенов в копировании тайлов можно, но это уже "хотелка" и её бы в отдельный тикет вынести.
(0015159)
zed (manager)
28-01-2015 19:21

А кэш большой? Попробуй более-менее локализовать проблему: на каком зуме, в каком sdb файле. Потом сделай копию кэша, сделай ему Reset LSN и пришли мне тот sdb, чтобы я мог у себя воспроизвести баг и вылечить его.
(0015160)
Garl (manager)
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 (manager)
29-01-2015 07:36

Хотелось бы докопаться до сути.
(0015162)
Garl (manager)
29-01-2015 07:40

просто 1 файл T:\cache_dbv\sat_all_v1\z18\78\46\313.186.sdbv + логи нам толку не дсат?
(0015164)
zed (manager)
29-01-2015 07:50

Да, этого вполне должно хватить. Только предварительно сделай db_recover, скопируй один sdb с логами в новую папку и проверь, что воспроизводится.
(0015165)
Garl (manager)
29-01-2015 07:52
edited on: 29-01-2015 08:03

сделал просто recover
1 файл базы + env вылеты есть

(0015166)
zed (manager)
29-01-2015 08:34

Жду ссылку на архив.
(0015168)
Garl (manager)
29-01-2015 12:44

https://cloud.mail.ru/public/35c8e558f3b5/test_dbv.7z
(0015175)
zed (manager)
30-01-2015 07:22

Что-то не хочет он у меня открываться. У тебя он db_verify проходит без ошибок?
(0015181)
Garl (manager)
30-01-2015 08:41

видать с ошибками.
кэш версионный это критично?
(0015184)
zed (manager)
30-01-2015 10:20

Понятно что версионный.
У тебя точно открывается то, что лежит в архиве? Какая прописана версия и по каким координатам открываешь?
(0015185)
Garl (manager)
30-01-2015 14:31

N43°37'23,42" E40°29'59,04"
зум 18

а после верифи - перестал вообще чего-либо показывать...
(0015186)
zed (manager)
30-01-2015 17:09

Странно, db_verify по-идее должен работать в режиме только чтения и никаких изменений в БД он не вносит.
(0015187)
zed (manager)
30-01-2015 17:24

В присланном тобой файле, начиная со смещения 0x35E00000 (это 862 Мб ровненько) идут сплошные нули. Поэтому он так хорошо и сжался. Возможно заглючил архиватор или ещё что. Проверь.

Контрольная сумма (md5): cc8fa8f9e38a87b8835410e7c1a33524 *313.186.sdbv
(0015214)
Garl (manager)
02-02-2015 07:28

ага файл получился битый, перепаковываю и перезаливаю.
баг всё ещё присутствует.
(0015222)
Garl (manager)
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 (manager)
03-02-2015 10:26

а почему перестал после Верифи работать: оно переименовало файл в .bad
(0015224)
zed (manager)
03-02-2015 11:35

Ещё контрольную сумму дай на всякий случай.
(0015225)
Garl (manager)
03-02-2015 11:43

3893a20723c979fdb7e203a0d36adebd *z18/78/46/313.186.sdbv
(0015226)
zed (manager)
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

- Users who viewed this issue
User List Anonymous (3550x), netsky (1x), aflexus (1x), zed (1x)
Total Views 3553
Last View 29-03-2024 00:04

- Issue History
Date Modified Username Field Change
28-01-2015 10:40 Garl New Issue
28-01-2015 10:40 Garl File Added: 28-01-2015SASPlanet.Debug.elf
28-01-2015 11:17 zed Note Added: 0015154
28-01-2015 11:19 Garl File Added: sdb.log
28-01-2015 11:34 zed Note Added: 0015155
28-01-2015 11:42 Garl Relationship added parent of 0002611
28-01-2015 11:49 zed Relationship replaced related to 0002611
28-01-2015 19:21 zed Note Added: 0015159
29-01-2015 05:26 Garl Note Added: 0015160
29-01-2015 07:36 zed Note Added: 0015161
29-01-2015 07:40 Garl Note Added: 0015162
29-01-2015 07:50 zed Note Added: 0015164
29-01-2015 07:52 Garl Note Added: 0015165
29-01-2015 08:03 Garl Note Edited: 0015165 View Revisions
29-01-2015 08:34 zed Note Added: 0015166
29-01-2015 12:44 Garl Note Added: 0015168
30-01-2015 07:22 zed Note Added: 0015175
30-01-2015 08:20 vdemidov Status new => confirmed
30-01-2015 08:20 vdemidov Product Version .Nightly => 141212
30-01-2015 08:20 vdemidov Target Version => 24xxxx
30-01-2015 08:31 Garl File Added: sdb_util.log
30-01-2015 08:41 Garl Note Added: 0015181
30-01-2015 10:20 zed Note Added: 0015184
30-01-2015 14:31 Garl Note Added: 0015185
30-01-2015 17:09 zed Note Added: 0015186
30-01-2015 17:24 zed Note Added: 0015187
31-01-2015 20:42 vdemidov Status confirmed => feedback
02-02-2015 07:28 Garl Note Added: 0015214
02-02-2015 07:28 Garl Status feedback => new
02-02-2015 07:57 vdemidov Status new => feedback
03-02-2015 10:25 Garl Note Added: 0015222
03-02-2015 10:25 Garl Status feedback => new
03-02-2015 10:26 Garl Note Added: 0015223
03-02-2015 11:35 zed Note Added: 0015224
03-02-2015 11:43 Garl Note Added: 0015225
04-02-2015 13:30 zed Note Added: 0015226
04-02-2015 13:32 zed Status new => resolved
04-02-2015 13:32 zed Fixed in Version => 150915
04-02-2015 13:32 zed Resolution open => fixed
04-02-2015 13:32 zed Assigned To => zed
04-02-2015 13:33 zed Target Version 24xxxx => 150915
04-02-2015 13:33 zed Summary Invalid floating point operation. => BerkeleyDB: Invalid floating point operation
04-02-2015 13:34 zed Tag Attached: BerkeleyDB
04-02-2015 13:34 zed Tag Attached: БД
04-02-2015 13:34 zed Tag Attached: версионный кэш
04-02-2015 13:34 zed Tag Attached: кэш
27-07-2015 20:47 zed Relationship added related to 0002771



Copyright © 2007 - 2024 SAS.Planet Team