ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / C++ [игнор отключен] [закрыт для гостей] / Требуется оценить трудоемкость задачи
24 сообщений из 24, страница 1 из 1
Требуется оценить трудоемкость задачи
    #33835296
avk-75
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avk-75
Гость
Есть приложение Win32, в котором предусмотрен режим ведения протокола путем записи в текстовый файл. Приложение часто падает по GPF. При этом, самые важные участки протокола, по которым разработчик может понять, в чем причина падения, в протоколе не сохраняются, т.к. данные в протокол выводятся порциями – для ускорения работы: файл протокола открывается, какое-то время туда пишутся данные, потом через какое-то время он закрывается и открывается вновь для записи новой порции данных. Соответственно, самый важный кусок данных, «относящихся» к падению приложения, в протокол обычно не сохраняется, т.к. файл не успевает закрыться по причине падения приложения.

Можно ли сделать примерно следующее? Написать программу, которая будет каким-то образом перехватывать обращения к функциям записи в файл, и делить поток вывода в файл, например, по имени файла – если идет запись в файл с определенным именем, то кидать эти данные не на диск, а отправлять по TCP/IP другому приложению, которая будет данные ловить и сохранять себе в память. Если же идет запись в файл с именем, отличным от заданного, вызывать стандартный обработчик записи в файл.

Интересна принципиальная возможность такого решения и возможная трудоемкость.

Спасибо.
...
Рейтинг: 0 / 0
06.07.2006, 12:38
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835354
Maksim UM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maksim UM
Гость
не проще попробовать после каждой записи в файл
делать что-то вроде FlushFileBuffers?
перехватывать конечно возможно.
вопрос только какими функциями пользуется
программа (стандартными виндовыми WriteFile...,
mfc, borland vcl...)
есть программа filemon которая позволяет смотреть
что делается с файлами (не помню, пишет ли она в лог
сами данные)
...
Рейтинг: 0 / 0
06.07.2006, 12:55
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835356
Guest1232123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest1232123
Гость
мысли в слух

Как я понимаю вы хотите внешним приложением перехватить сам WriteFile мне кажется, что это слишком, вот мои мысли по этому вопросу.

Я не понял кто разработчик. Если это вы, т.е. вы имеете доступ к исходным текстам, то решить эту проблему не сложно. Например, периодически сбрасывать буфер файла на диск(flush), выбрать быстрый диск, вариантов очень много.

Но с другой стороны раз вы хотите создать внешнее приложение, то значит программист не вы, а нужно это программистам, пусть они и морочатся с этим им это во много раз проще.

Если приложение держит лог в памяти и сбрасывает его только по наполнению, то заставить приложение сбросить может только приложение или какие-либо функции приложения.

это задача разработчиков и передачей по сети это не решить.

единственное, возможно, я не так понял про что разговор.
и я не знаю что такое GPF, т.е. возможно, если узнаю, то всё станет ясно:)
...
Рейтинг: 0 / 0
06.07.2006, 12:55
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835451
maXmo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maXmo
Участник
Если ты разработчик, то напиши нормальное сохранение в лог. Если нет, то зачем тебе эти данные, всё равно ошибку ты не исправишь.
...
Рейтинг: 0 / 0
06.07.2006, 13:19
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835462
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
Предложите разработчикам заменить функцию буферизации логов функцией непосредственной записи на диск.
...
Рейтинг: 0 / 0
06.07.2006, 13:22
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835626
avk-75
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avk-75
Гость
Пояснения.

1. Доступа к коду нет, программа разрабатывается сторонней организацией. Таким образом:
· FlushFileBuffers – если это совет как организовать протоколирование, он не подходит, т.к. доступа к коду нет;
· каким функциями пользуется программа - не известно, это нужно выяснять (думаю, что выяснить это можно);
· я почитал описание FileMon; она мониторит откуда, в какие файлы и что было записано; мне же важно вообще не писать в файл (а писать в память, например) чтобы выиграть в скорости;
2. "пусть программисты и морочатся с этим им это во много раз проще." . Программисты говорят, что единственный вариант поймать падение приложения в протокол – это закрывать файл протокола после записи каждой строки и снова его открывать. Но в этом случае приложение начинает работать настолько медленно, что в режиме реальной работы использовать данный подход невозможно (окна открываются по полминуты и.т.п.). Падения же происходят в случайные моменты времени, поэтому воспроизвести падения специально не представляется возможным.
3. "Если приложение держит лог в памяти и сбрасывает его только по наполнению, то заставить приложение сбросить может только приложение или какие-либо функции приложения." . Во-первых - см. п.1, во-вторых, если приложение держит лог в памяти, то после падения приложения лог в памяти пропадает вместе с упавшей задачей…
4. "передачей по сети это не решить" . Идея состоит в том, чтобы писать лог действительно в память, но не в память приложения, которое падает, а в память другого приложения. Передача по сети – это один из способов направить данные другому приложению. Потом запускать это приложение на компьютерах у пользователей и ловить падения в режиме реальной работы.
5. GPF –General Protection Faults
...
Рейтинг: 0 / 0
06.07.2006, 14:09
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835717
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
avk-75Пояснения.

Программисты говорят, что единственный вариант поймать падение приложения в протокол – это закрывать файл протокола после записи каждой строки и снова его открывать.

пробовали послать их подальше и не плотить денек ?
...
Рейтинг: 0 / 0
06.07.2006, 14:37
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835740
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
SoftIce
...
Рейтинг: 0 / 0
06.07.2006, 14:42
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835784
Dmitrii K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitrii K.
Участник
Gluk (Kazan) avk-75Пояснения.

Программисты говорят, что единственный вариант поймать падение приложения в протокол – это закрывать файл протокола после записи каждой строки и снова его открывать.

пробовали послать их подальше и не платить денек ?
+1
Это их проблемы, а не ваши, пусть сами и решают...

А если они не умеют не падать часто в GPF, то пусть сами напишут утилитку, которая будет ловить месаги (ну или сокеты, Shared Memory и т.д. и т.п.) и записывать лог на диск. Это разгрузит основную прогу от работы с медленными дисками (раз уж это так критично с т.з. производительности) + "утилита" сможет мониторить состояние основной задади и восстанавливать её после падения...
...
Рейтинг: 0 / 0
06.07.2006, 14:55
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835959
Maksim UM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maksim UM
Гость
Полностью согласен, что прогу должны писать сами программисты.
Как уже сказали, если данные не пишутся стандартными функциями
в файл, то ловить нечего (неизвестно что).
Для того, чтобы данные были точно записаны на диск нужно просто
после записи данных делать сброс буфферов (flush).
...
Рейтинг: 0 / 0
06.07.2006, 15:30
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33835999
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
Пускай разветвлят логи. По старому и в сокет.
...
Рейтинг: 0 / 0
06.07.2006, 15:38
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836094
avk-75
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avk-75
Гость
"Как уже сказали, если данные не пишутся стандартными функциями
в файл, то ловить нечего (неизвестно что)."

Согласен. Тут необходимо знать - как осуществляется запись в файл протокола. Если какое-то время данные для протокола пишутся просто в память приложения (не файловыми функциями), а потом в какие-то моменты времени сбрасываются на диск, то ловить нечего. Если данные пишутся на диск все время стандартными функциями, но без Flash’а – тогда можно пытаться ловить…

Тогда изменю вопрос. Способы, как это можно сделать самим разработчикам. Здесь приводилось два:
- Сокеты
- Shared Memory

Есть ли еще варианты? Поясню: данных в протокол выводится очень много (на самом деле очень много). Если передавать через сеть, возможно падение производительности сети. Про Shared Memory не слышал… А задача, напомню, - быстро писать данные протокола куда-то (если в память, то по крайней мере не в память падающего приложения).

P.S.
Стоп! А может какой-нибудь виртуальный диск сделать (как в DOS’е было – RAMDRIVE)?
...
Рейтинг: 0 / 0
06.07.2006, 15:58
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836116
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
avk-75Если передавать через сеть, возможно падение производительности сети.

Есстественно через циклический интерфейс на этот же компьютер
...
Рейтинг: 0 / 0
06.07.2006, 16:02
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836150
Guest1232123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest1232123
Гость
Да можно всё сделать и по разному.
Данных ооочень много, много на сколько, сотни килобайтов, мегабайтов, гигабайтов?

И виртуальный диск можно сделать, и в файл в памяти можно писать, и скорее всего можно успеть на обычный диск данные скидывать(ведь там тоже через дисковый кэш всё работает это ведь не дос без смартдрайва) всё что хочешь!

Сейчас ведь вопрос уже в другом - кто это должен делать.
Этим должны заниматься разработчики, и им должно быть лучше видно как это сделать учитывая текущую специфику. А гадать тут бесполезно, если они не решили эту задачу, то и другую могут не решить, вопрос не технический.
%)
...
Рейтинг: 0 / 0
06.07.2006, 16:07
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836176
LeonM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeonM
Участник
авторданных в протокол выводится очень много
неправильный мониторинг
авторвиртуальный диск
файл в памяти
авторне в память падающего приложения
wm_copymemory
файл в памяти
...
Рейтинг: 0 / 0
06.07.2006, 16:13
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836200
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kolobok0
Участник
avk-75Тогда изменю вопрос. Способы, как это можно сделать самим разработчикам. Здесь приводилось два:
- Сокеты
- Shared Memory
Есть ли еще варианты? Поясню: данных в протокол выводится очень много (на самом деле очень много). Если передавать через сеть, возможно падение производительности сети. Про Shared Memory не слышал… А задача, напомню, - быстро писать данные протокола куда-то (если в память, то по крайней мере не в память падающего приложения).

P.S.
Стоп! А может какой-нибудь виртуальный диск сделать (как в DOS’е было – RAMDRIVE)?

1) если использовать сокеты, то а) нужно использовать моментальную отправку (могут быть маленьчкие тайм ауты на некоторых протоколах - к примеру TCP/IP) б) сам протокол занимает время (разруливание колизий, обрыв связи и прочее)...
2) шаред мемори - это в принцепе и есть один из самых быстрых способов под форточками передать кусок данных в другой процесс.
3) виртуальный диск - думаю скорость данного решения под вопросом... Помимо маршалинга (что и в шаред мемори) надо будет заботиться о форматировании на уровне фата и прочее...

Пару слов о задачи...
1) Чтобы локализовать проблемы в программе существуют различные методы. Приведённая Вами - одна из них. Но технологически она предназначена (её плюсы) - не лежат в плоскости падежей программного обеспечения. Обычно данный способ лучше даёт насчупать логические ошибки в многопоточном приложении(ях).
2) Для локализации падежа, лучше подходит методология разделения кода "по отсекам", с помощью трай-кэтч блоков и типизирования исключений. Точнее даже я бы так сказал - не типизирования, а однозначной идентификации некоего своего типа эксепшенов (дешевше при производстве обходиться). Получаемый стэк падежа при ошибках - достаточно точно описывает причины и однозначно указывает на проблемы.

с уважением
(круглый)
ЗЫ
Вы даже не представляете, сколько людей в IT области занимаются тем, чем в общем то и не умели никогда...
ЗЫ ЗЫ
Пожелаю удачи Вам и программистам исполнителям - она потребуется...
...
Рейтинг: 0 / 0
06.07.2006, 16:18
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836390
avk-75
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avk-75
Гость
To Guest1232123:
"вопрос уже в другом - кто это должен делать"

Зависит от выбранного способа: если организовать виртуальный диск, это можно сделать самостоятельно, если же что-то дописывать в приложении, конечно, лучше чтобы делал разработчик.

Данных выводятся в протокол - десятки мегабайт.
...
Рейтинг: 0 / 0
06.07.2006, 17:02
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836396
avk-75
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avk-75
Гость
Просто разработчикам тоже нужна идея…
...
Рейтинг: 0 / 0
06.07.2006, 17:03
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836442
Dmitrii K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitrii K.
Участник
avk-75
Зависит от выбранного способа: если организовать виртуальный диск, это можно сделать самостоятельно
Зависит от того, как они пишут в лог... может и не помочь...
avk-75Данных выводятся в протокол - десятки мегабайт.
Это в секунду? ) Что за задача такая?
avk-75Просто разработчикам тоже нужна идея…
Это уже не разработчики, а просто кодеры...
Студенты вам пишут, что-ли?

Короче, расслабьтесь, и напрягайте их.
...
Рейтинг: 0 / 0
06.07.2006, 17:19
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836659
avk-75
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avk-75
Гость
Ну допустим… я прикинул - в секунду выводится в протокол от 10 до 900 килобайт текста.
...
Рейтинг: 0 / 0
06.07.2006, 18:28
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836685
Гвест23123123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гвест23123123
Гость
avk-75Просто разработчикам тоже нужна идея…

повторюсь - задача решаема и думаю легко.

идеи разработчикам:

общие
1. Структурировать программу.
2. задействовать механизм обработки исключений.
http://www.sql.ru/forum/actualthread.aspx?tid=311723#2851060

конкретные
1. сколько времени будет идти поток, если пару секунд, то и винт с виндовым кешем справится. Во всяком случае это быстрее чем сеть.
2. хотя что я то напрягаюсь, удачи!
...
Рейтинг: 0 / 0
06.07.2006, 18:36
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33836824
Staub
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Staub
Гость
avk-75Есть приложение Win32, в котором предусмотрен режим ведения протокола путем записи в текстовый файл. Приложение часто падает по GPF. При этом, самые важные участки протокола, по которым разработчик может понять, в чем причина падения, в протоколе не сохраняются.

Так всегда былоб что если приложение падает и в это мне виноват клиент, значит виноват разработчик. на то они и программисты, что приложения пишут. Начинать лучше с самого простого-не верю если они даже не догадываются какой кусок кода вызывает падение. Если знают, то надо использовать мех-м обработки исключений, типа try, throw и catch. А если таким программерам сказать написать еще и стороннюю программу, которая это все будет проверять-больше времени уйдет.да и в итоге-не работаает их программа, а ДОЛЖНА работать.не верю что опытный программист не догадываеься хоть примерно о том, что не так.
...
Рейтинг: 0 / 0
06.07.2006, 19:39
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33837265
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
avk-75Ну допустим… я прикинул - в секунду выводится в протокол от 10 до 900 килобайт текста.

Не верте им, что закрытие и открытие файла сильно затормозит приложение.
...
Рейтинг: 0 / 0
07.07.2006, 09:27
| Ответить | Цитировать | Написать  
Требуется оценить трудоемкость задачи
    #33838124
Barlone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Barlone
Участник
Есть в Win32 API функция OutputDebugString и есть у sysinternals утилитка DebugView позволяющая перехватывать вывод этой функции. Для разаботчиков трудоемкость вставки вызова этой функции вместо или вместе с записью в файл наверное невелика.
...
Рейтинг: 0 / 0
07.07.2006, 13:00
| Ответить | Цитировать | Написать  
24 сообщений из 24, страница 1 из 1
Форумы / C++ [игнор отключен] [закрыт для гостей] / Требуется оценить трудоемкость задачи
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/search_topic.php?author=Tekila&author_mode=last_posts&do_search=1]:
 0ms
get settings:
 9ms
get forum list:
 15ms
get settings:
 7ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 39ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 70ms
get tp. blocked users:
 2ms
others: 638ms
total:  806ms
созд. / загр.: 806ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]