Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
FB 2.5.6. Сегодня сервер с такой причиной: internal Firebird consistency check (EVL_expr: invalid operation (232), file: evl.cpp line: 1219). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. Есть возможность выяснить примерную причину этого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 07:52 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
включить трейс и посмотреть какой именно запрос к этому приводит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 09:58 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
dimitr, Насколько я понял, это не порча БД, а просто попытка выполнения какого-то корявого запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 10:10 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
dimitr, Проработали сегодня весь рабочий день, багчек не появлялся. Поэтому вопрос - есть ли возможность в случае такого багчека выводить стек вызовов и/или запрос, на котором он сработал? Потому что настраивать трейс только ради гипотетической возможности повторно на него наткнуться - считаю лишним. Так же было бы отличным сообщать имя пользователя в логах. Например: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 10:22 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
В трекер писать про оба этих момента? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 10:23 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
IMHO, там вообще сервер ошибку лучше бы кидал, а не багчек. Юзера и запрос писать в лог считаю излишним (при ошибке в процедуре выводить весь ее текст?). К слову, ошибка может быть исправлена в 3-ке. А может и не быть . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 10:43 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
dimitrIMHO, там вообще сервер ошибку лучше бы кидал, а не багчек. Кстати да, так было бы отлично. dimitrЮзера и запрос писать в лог считаю излишним В данном случае про пользователя я не только про этот багчек, а про все сообщения. Сейчас вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Предлагаю вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. dimitr (при ошибке в процедуре выводить весь ее текст?). Возможно. Суть в том, чтобы сразу была инфа, у кого и в каком месте это случилось. dimitrК слову, ошибка может быть исправлена в 3-ке. А может и не быть . Корявый запрос мог быть запущен только кем-то из разрабов, то есть мной и моим напарником. Но ни я, ни он в это время не работали с БД. Поэтому хз, что там могло приключиться. Вот был бы пользователь указан - можно было бы допросить, учитывая, что багчек повторился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2016, 11:01 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
Сегодня сервер снова останавливался с такой же причиной. Но здесь было проще - это точно мой запрос. Поиск причин привел к вот такому запросу, который FB 2.5.6 не переваривает: Код: sql 1. 2. 3. 4. На FB 3.0.2 остановки нет, так что здесь что похожее на CORE-1605 . Но на 3.0.2 получается странный результат. Вот этот запрос выдает 106717: Код: sql 1. 2. 3. 4. А вот этот - NULL: Код: sql 1. 2. 3. 4. Нет ли здесь бага? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 08:10 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
Добавил CORE-5563 , чтобы было обычное исключение вместо bugcheck. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 08:19 |
|
||
|
Bugcheck
|
|||
|---|---|---|---|
|
#18+
Добавил CORE-5564 для улучшения информативности сообщений в firebird.log. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 08:27 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=39344043&tid=1561546]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
58ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 283ms |
| total: | 419ms |

| 0 / 0 |
