Max Diesel писал(а): ↑Чт янв 19, 2017 3:14 pm
i3v писал(а): ↑Вт янв 17, 2017 9:06 pm
Ну, надеюсь информация из evtx файла позволит как-то локализовать проблему. Если нет - может тогда какие-то иные идеи есть, как собрать какую-то полезную информацию при таких падениях?
Подозреваю, что не позволит. В журнале события сохраняются лишь события, о причинах их происхождения и способах воспроизведения можно лишь догадываться.
Жаль, я думал fault offset хоть
позволит восстановить место в коде, которое падает (хоть и оно и не позволит понять, при каких именно обстоятельствах, конечно... Но это хотя бы позволило бы переписать немного конкретно это место, чтобы при следующих падениях уже лучше понимать в чём именно проблема...).
Beta 8, кстати, сразу после обновления, тоже сразу после установки 1 раз упала и 1 раз намертво повисла. А потом - нормально... (На всякий случай приложил evtx - вдруг всё-таки пригодится)
Max Diesel писал(а): ↑Чт янв 19, 2017 3:14 pm
i3v писал(а): ↑Вт янв 17, 2017 9:06 pm
А вот с прогрессбаром "сравнения файлов" - опять сейчас воспроизвелось пару раз (beta7).
К сожалению навскидку не удается получить такой результат. Если вдруг обнаружится способ воспроизвести эту проблему, то буду рад его узнать.
Ну, у меня по-прежнему стабильно воспроизводится (то ли поведение то же, что и было, то ли очень похожее) на beta8 Win7 x64 + VirtuaWin:
- Ставим virtuaWin (она лёгкая - установка занимает около минуты, ещё минуты 3 на изучение и изменение, при необходимости, горячих клавиш)
- Ставим на текущем десктопе какое-нибудь "сравнение файлов", так чтоб заняло хотя бы секунд 10
- Переключаемся на другой десктоп
- Ждём некоторое время (с запасом), не переключаясь обратно
- Когда процесс завершается, на текущем десктопе выскакивает соотв. диалоговое окошко. Мы можем нажать "ок" или не нажимать его.
- В любом случае, когда мы переключимся на исходный виртуальный рабочий стол - окно с прогрессбаром "сравнения файлов" будет ещё там. Примерно такая же картинка как тут
- И в любом случае окошко с прогрессбаром уже никак не закрыть.
i3v писал(а): ↑Ср янв 11, 2017 5:22 pm
i3v писал(а): ↑Сб дек 31, 2016 2:22 am
Max Diesel писал(а):
Однако обнаружился-таки фрагмент кода, который работал некорректно в случае, если программа занимала больше 2-х гигабайт памяти. Сложно сказать, мог ли он привести к утечке памяти, но в следующем билде он будет исправлен. Благодарю за содействие.
Здорово! Будем надеяться, что это оно и всё починится!
Судя по всему - правда починилось (в beta 5). Здорово! Хотя я ещё постестю...
Ещё пару раз погоняв на
той же тестовой структуре могу подтвердить, что теперь не падает.
Однако, похоже что где-то там имеется утечка памяти... В пике UC ест до ~11ГБ, а потом отдаёт не всё - после того как я закрываю окно синхронизации UC продолжает кушать около 2ГБ RAM. (В принципе - оно не мешает почти, но всё-таки "плохой признак".)
Если что - вложил ещё fl_error.txt до и после "эксперимента" (правда я не совсем уверен, что измения относятся именно к процессу синхронизации, а не к чему-то другому).
У вас нет необходимых прав для просмотра вложений в этом сообщении.