Постоянно падает на GetFilesW при копировании файлов

[acc15]

Far Manager, version 3.0 (build 4040) x64 NetBox 2.1.39.320

║ Exception: Access violation (read from 0x000000000000040A) ║ ║ Address: 0x000007FEF84DAE63 ║ ║ Function: GetFilesW ║ ║ Module: E:\Utils\Far\Plugins\NetBox\NetBox.dll ║ ║ { Unload plugin } [ Debug ] [ Ignore ] ║

Взрывается каждый раз когда копирую папку с файлами (~70mb) или одиночный файл (~50mb) через SFTP на локальный диск.

Ранее была уже такая проблема https://github.com/michaellukashov/Far-NetBox/issues/73

[VictorVG]

Давайте попробуем исключить часть ошибок b4040. Возьмите b4058 - в нём исправлен ряд недостатков 4040, а по стабильности работы он ему не уступит. И если вам не сложно, то дайте пожалуйста лог соединения, версию ОС и по возможности создайте дамп памяти в момент AV. Для этого можно воспользоваться программой Process Hacker. Текущую версию можно всегда взять тут - http://yadi.sk/d/193Gnglm4Ia5D (архив 7-Zip v9.34 Alpha, LZMA, SOLID, MAXIMUM). Создать дамп памяти процесса не сложно - ПКМ на имени процесса -> Create Dump File... , после сохранения упакуйте его в Zip/7-Zip архив т.к. этот файл будет довольно большим - сотни мегабайт в зависимости от вашего набора плагинов (дамп - это копия области памяти задачи в момент его создания) он поможет установить что происходит в памяти момент сбоя. Сейчас кроме предоставления инструментов с помощью которых можно с вашим участием разобраться в том что происходит в момент аварии на вашей машине никто вам помочь не сможет.

[acc15]

Сейчас проверил x86. Там все работает. И b4040 и b4058

Проблема касается только x64. Проверял на b4040 и b4058.

Информация о ОС: https://dl.dropboxusercontent.com/u/28414631/systeminfo.txt Дамп процесса (сразу после появления окна с ошибкой): https://dl.dropboxusercontent.com/u/28414631/Far_b4058.7z

Проблема воспроизводится на полностью девственном дистрибутиве Far x64 b4040 без каких либо кастомизаций и доп. плагинов. http://www.farmanager.com/files/Far30b4040.x64.20140810.7z

Ошибку проверял с соединением VirtualBox + lubuntu + OpenSSH. Но мне кажется сервер тут совсем ни при чем.

[VictorVG]

Да, тут только Мишу ждать - у меня доступна только х86 система, но что хорошо, то то, что у вас не установилось обновление КВ2984615 (Бюллетень по безопасности (Майкрософт ) MS14-045 (существенный ). Уязвимости драйверов в режиме ядра делают возможным несанкционированное повышение привилегий (2984615). Дата публикации : 12 августа 2014 г .) - МС сама его отозвала из-за допущенных в нём ошибок, и я честно говоря опасался его случайной установки у вас в системе ...

[michaellukashov]

Как раз сервер и может быть причиной. В последней версии плагина добавлена поддержка SFTP version 6, возможно ошибка в этом коде. Попробуйте в настройках сессии поставить использование SFTP version 3. Еще хотелось бы посмотреть файл с логом соединения.

[videvio]

Подтверждаю постоянное падение на Windows XP SP3 (32 бит), Windows Server 2012 R2 (64 бит) и Windows 8.1 (64 бит). Установлены все обновления. Падает примерно в 30% случаях после

1) входа и возврата из спящего режима 2) разрыва соединения по таймауту (даже при включенном keep-alive)

Лог соединения при этом пустой - т.е. обычный стандартный коннект, без каких либо действий все равно приводит к падению после выхода из спящего режима или разрыва коннекта.

Вид сервера не имеет значения - падает как на SFTP, так FTP соединениях, как на обычных VPS-ках (Rusonyx, DitigalOcean с CentOS 6), так и физических серверах с кастомными настройками.

Падает как на 32битном фаре, так и 64битном. Падало всегда с момента пользования NetBox независимо от установленных обновлений.

Пользуемся пока WinSCP-плагином - он не падает.

Особую жесть представляет то, что если вдруг падает WinSCP в момент сохранения измененного файла (раз в год бывает), то редактируемый по SFTP файл остается в папке TEMP. Если падает NetBox - файл в папке TEMP нулевого размера.

Сделаю дилетантское предположение - учитывая, что падение не зависит от внешних условий и часто случается после выхода из спящего режима, возможно проблема в том, что Windows как-то "фризит" ресурсы NetBox. Старый плагин WinSCP после выхода из спящего режима часто сбрасывает соединение без возможности реконнекта. NetBox же всегда предлагает реконнектится или вообще ничего не делает, давая походить по кэшированным папкам, а потом вылет..

[VictorVG]

videvio

Я думаю вы правы в предположении о том, что часть вины за события лежит на спящем режиме. Я с этим встречался, и не раз многие программы после выхода из него начинают сбоить будто ОС некорректно восстанавливает состояние ОЗУ и контекста машины в целом. Потому я стараюсь этого режима избегать где только можно.

[videvio]

Под спящим режимом я понимаю более широкое понятие. Тем более давно уже существует куча их видов, например, гибридный режим.

В последних версиях ОС "спящий режим" стал умнее (он и в Windows XP был умнее - отключение жесткого диска, пониженное питание USB-портов - стандартная опция без входа в ждущий и спящий режимы) .

C целью экономии питания система и без входа в спящий режим может вводить режим экономии (как минимум понижает частоту процессора, отключает винт, снижает питание неиспользуемых USB-портов, вероятно, часть физической оперативки выгружает на диск).

Как это работает, я не знаю, но такое впечатление, что режим умудряется срабатывать даже в момент копирования большого файла (как описано выше). Визуально у меня это заметно на нетбуке с Windows 8 - система запускает только screen saver, переводит винчестер в режим пониженного питания, но до ждущего/спящего режима еще полчаса.

Если я в таком режиме простоя возвращаюсь к работе система на 1-2 секунды задумывается, хотя в ждушем режиме система не была - вероятно она восстанавливает какие-то ресурсы и что-то грузит в физическую память с диска. Если в этот момент переключиться в окно Far-NetBox и попытаться перейти в другую папку при активном соединении - 100% нарываюсь на вылет. Кстати вылеты чаще, если NetBox запущен на обоих вкладках и идет попытка восстановления соединения в обоих окнах.

[VictorVG]

Согласен, и причину явления я хорошо представляю - снижение напряжения питания схем и как следствие падение их частотных характеристик с последующими временными сбоями из-за того, что тактовые частоты синхронизации уже поднялись до номинальных, а вот переходные в процессы каскадах ещё идут несколько десятков, а при длинных цепочках и сотен тактов. Обычные издержки схемотехники. Сам такие задачи по работе часто вынужден решать - электростанцию мне для питания "утюгов" никто не поставит, а обойти утверждённое ТЗ чревато.:) Вот и крутись, особенно когда ТЗ составляли программисты - то, что происходит в схемах и как заваливаются фронты для них тёмный лес и они вечно исходят из предположения что "Мы дали команду и аппаратура мгновенно включилась" а посему пишут фантастические характеристики аппаратуры, особенно по быстродействию и энергопотреблению - "У вас же микросхемы, а им и батарейки хватит!". Ага, мгновенно, и батарейки. Средний БМК которые мы используем на рабочей частоте 5 ГГц потребляет 9 - 10W, и хорошо коли я в него смогу приличный кусок схемы запихнуть, а коли нет? Так что приходится в иную схему и десятки чипов ставить, а их ещё и накормить надо.:)

[michaellukashov]

Воспроизводится ли падение на билде 343? Новую версию можно будет взять из завтрашней ночной сборки официального фара, или взять бинарники по ссылке из последнего комментария к Issue #128

[michaellukashov]

Так есть ли ошибка в последних версиях плагина?

[VictorVG]

Я гибернейтом не пользуюсь - кто мне позволит выключить машины которые должны работать 7/24, так что думаю стоит подождать немного пока автор репорта отпишется.

[videvio]

Вместо гибернейта аналогичная проблема всплывает конкретно на операторе OnLime (Ростелеком) - у них какая-то ущербная система авто-обрывания соединения примерно через 3-4 минуты такая, что программа-клиент не рапортует об этом сразу, что проявляются в Putty и WinSCP - т.е. при фактическом обрыве соединения даже по истечении таймаута Putty думает, что все еще подсоединен к серверу.

Причем не помогают настройки Keep-Alive - интернет-провайдер OnLime рвет соединение в случайный момент времени спустя 3-4 минуты. При этом на обычные http-соединения (по порту 80 и 443) этот автобрыв не распространяется - скачивания даже 60 Гб без использования Download Manager-ов силами Internet Explorer происходят без обрывов.

Немного похоже на поведение после гибернейта, сделанного при активном соединении, ведь по факту после выхода из гибернейта Putty не сразу сообщает о разорванном соединении.

Может ли автор программы в настройки Keep-Alive добавить не только отправку null-пакетов и dummy-пакеты, а какие-нибудь реальные команды (типа скрытый запрос листинга директории - ведь именно на листинге директории после разрыва соединения обычно Fatal error и вылетает)

Ночная сборка не подписана и Windows не дает ее поставить -у нас компании с этим строго, чтобы лишний раз не подвергать опасности сайты клиентов, доступы от которых имеются внутри Far. Я поставлю в ближайшее время на тестовую машину, но вы сами понимаете - ошибка возникает именно во время активного использования. Попробую что-нибудь придумать.

[VictorVG]

Кроме нескольких плагинов почти весь фар не подписан. Это с одной стороны позволяет проще править ошибки в коде, а с другой вызывает подобные проблемы. Я к сожалению не смогу проверить вашу гипотезу о настройках работы с FTP у OnLime - у меня свой канал связи и таких вывертов у нас нет, зато почта может и не прийти месяцами - у каждого свои черти под полом.:) Я конечно могу для тех бинарников что собираю сам склепать самоподписанный сертификат и им их подписывать, но толку с этого будет что мёртвому припарки. Реально за всей этой истерией с сертификатами стоят интересы крупных софтверных компаний которые таким образом добиваются уничтожения СПО как явления ибо при отсутсвии альтернативы люди будут вынуждены покупать их залежалый товар...

Что касается возможного механизма проверки доступности FTP как протокола, то тут надо подумать. С ходу я не готов выдвинуть варинт механизма проверки ибо возможно что сервер не рвёт соединение, а просто закрывает канал перераспределяя его полосу в пользу HTTP, или это может проявляться ошибка в фирмваре оборудования канала. Без реальной проверки мы можем выдвинуть десятки ложных гипотез и не увидить реальную причну явлений.

[videvio]

Мы в итоге у себя посчитатали, что мнение virustotal и его 52 антивирусов достаточно - так что поставил на свою рабочую машину сегодняшний Far - тестирую последнюю сборку

[VictorVG]

Я сам его копилю из исходников, ну и понятно без ошибок не обходится. Вот ит сегодня я перегнул палку :) в одном их Lua скриптов - пришлось лишний код убирать. Коли хотите попробовать, то вот ссылки на мои архивы - http://yadi.sk/d/2Xce3MAAKBJTB FarUE3 и http://yadi.sk/d/3cWa73hVKuhok - обновление для неё. Ругань мухобоек будет, но только на программы от NirSoft - держу из-за толковости. Вопросы по моему проекту можно и тут задать http://forum.ru-board.com/topic.cgi?forum=5&topic=31718&glp#lt

[videvio]

Хех - у меня не работает сохранение изменяемых файлов ( Откатился назад.

[videvio]

(не работает сохранение изменяемых файлов в ходе сесии NetBox в ночной только что скаченной сборке Far)

[acc15]

Прошу прощения что долго не отвечал.

В сборке 343 скачанной отсюда https://yadi.sk/d/fDJFsgc3c6AaY копирование с сервера на локальный диск работает отлично в Far b4040 x64

Осталось зарелизить.

Спасибо большое Михаилу и Виктору за проделанную работу. Теперь я, наконец, могу удалить 32 битный FAR.

[VictorVG]

Так уже в ночнушках Far4 доступна версия v2.1.40.348. v2.1.40.349 я только поставил на сборку. Будет если небеса не упадут на землю где-то через часа полтора у меня по тем же адресам лежать. Просто либы OpenSSL на старенькой машине с 2 Гб ОЗУ собираются минут двадцать пять, ну а после уже всё быстрее идёт - там машине работы меньше.

[VictorVG]

Чуть не забыл архивы подновить. Положил, забирайте:

NetBox v2.1.40.349:

https://yadi.sk/d/fDJFsgc3c6AaY - FarNetBox-2.1.40_Far3_x64.7z https://yadi.sk/d/sZrHvcojc6Aax - FarNetBox-2.1.40_Far3_x86.7z