обратная связь - информация об ошибке

[Алексей++]

Многие программы, например Outpost ( да и всё подряд в Винде) при обнаружении ошибки в себе предлагают отправить дамп памяти разработчику для анализа.
Со своей стороны, несколько раз сталкивался с ситуацией, когда пользователи не могут внятно рассказать, когда ошибка появилась, то да сё, и вот интерисует - какую именно информацию достаточно сохранить, чтобы промоделировать или повторить возникнувшую ошибку ?

[Антон (LogRus)]

Обычно дампа и логов достаточно. Всё зависит от программы.

[Алексей++]

LogRus, тогда вопрос - насколько обильными должны быть логи, например порядок вызовов некоторых функций ?

программа - скажем, абстрактная, для начала

--
вообще, есть ли какие нибудь правила создания логов ?
(вроде устоявшихся приёмов)

[Антон (LogRus)]

Алексей1153++, какие тут правила делай, как тебе удобней

К каждой программе индивидуальный подход.
например:
1. логирование всех вызовов методов с выводом входных параметров
2. логирование в котрольных точках
3. периодическое дампирование данных
4. сброс дампа окружения при возникновении ошибки
5. естественно сброс дампа памяти
6. использование доктора ватсона при ошибка которые ты не можешь нормально поймать(на вроде ошибок доступа к памяти)
7. использование кольцевого лог буфера работы(с временными штампами) который сбрасывается на диск по требованию или при ошибке, полезно, если логи нужны только за последние несколько минут(часов) работы приложения, на случай возникновения критической/фатальной ошибки

естественно лучше дополнительно задавать уровень логов, что бы при штатной работе небыло оверхеда лишнего
в логгер можно засуть и профайлер, очень полезная вешь при поиске bottle neck-ов производительности(на случай, если нет возможности использовать VTune, например, ошибка проявляется только у конкретного клиента)

[Алексей++]

что есть VTune ?

насчёт

1. логирование всех вызовов методов с выводом входных параметров

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

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

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

[Антон (LogRus)]

VTune такая фиговина для профилирования программы с очень обширным набором способов профилирования
http://www.intel.com/cd/software/products/asmo-na/eng/vtune/239144.htm

у них еще есть всякие thred checker и thread profiler для тюнинга многопоточности

пунктами 1, 2, 3, 4, 6,7 пользуемся активно(+ профайлер)

касательно лога в памяти, не припомню случая, что бы лог терялся, даже при ошибках доступа памяти(перехватываются сигналы SIGSEGV, SIGABRT)

про мапированный в память файл не знаю.

[Алексей++]

сигналы SIGSEGV, SIGABRT

а вот тут попордробнее )  Что за сигналы и как перехватываются ?

а с файлом потом попробую ближе к делу

[Антон (LogRus)]

это синалы которые посылаются приложению в различных ситуациях
вот выдержка из msdn

signal ConstantsSee Also
signal, raise | Global Constants
#include <signal.h>
Remarks
The sig argument must be one of the manifest constants listed below (defined in SIGNAL.H).

SIGABRT
Abnormal termination. The default action terminates the calling program with exit code 3.
SIGFPE
Floating-point error, such as overflow, division by zero, or invalid operation. The default action terminates the calling program.
SIGILL
Illegal instruction. The default action terminates the calling program.
SIGINT
CTRL+C interrupt. The default action issues INT 23H.
SIGSEGV
Illegal storage access. The default action terminates the calling program.
SIGTERM
Termination request sent to the program. The default action terminates the calling program.

по умолчанию получение этих сигналов приводит к завершению приложения
если хочешь при получении сигнала сделать какуето еще работу то нужно переопределить обработчик
делается примерно так:

Код:

		void sig_handler_(int v)
		{
			switch (v)
			{
			case SIGABRT:
				DoSomeWork();
				def_sigabr_handler(v);
				break;
			case SIGSEGV:
				DoSomeWork();
				def_sigsegv_handler(v);
				break;
			default:
				exit();
			}
			
		}
typedef void (__cdecl *sighandler_t)(int);
sighandler_t def_sigabr_handler = signal(SIGABRT, new_sig_handler);
sighandler_t def_sigsegv_handler = signal(SIGABRT, new_sig_handler);

[Алексей++]

спасибо, буду разбираться ...

одно непонятно ещё - где этот обработчик должен быть размещён ?

[Антон (LogRus)]

без разницы, лишбы был и был установлен, через signal, как обработчик

[Алексей++]

ага, получилось )

Код:

#include <signal.h>
void __cdecl sig_handler_(int v)
{
	switch (v)
	{
		case SIGINT:	{::AfxMessageBox("SIGINT");}	break;
		case SIGILL:	{::AfxMessageBox("SIGILL");}	break;
		case SIGFPE:	{::AfxMessageBox("SIGFPE");}	break;
		case SIGSEGV:	{::AfxMessageBox("SIGSEGV");}	break;
		case SIGTERM:	{::AfxMessageBox("SIGTERM");}	break;
		case SIGBREAK:	{::AfxMessageBox("SIGBREAK");}	break;
		case SIGABRT:	{::AfxMessageBox("SIGABRT");}	break;
		default:		{::AfxMessageBox("default");}	break;
	}

	exit(0);
}

осталось понять, как все сигналы туда направить разом (или просто надо перечислить все ? )

Код:

	signal(SIGINT  ,sig_handler_);
	signal(SIGILL  ,sig_handler_);
	signal(SIGFPE  ,sig_handler_);
	signal(SIGSEGV ,sig_handler_);
	signal(SIGTERM ,sig_handler_);
	signal(SIGBREAK,sig_handler_);
	signal(SIGABRT ,sig_handler_);

так ?

просто , скажем, throw ловится , попытка полезть в "неправильную" память (скажем *0 ) ловится, а вот деление на ноль не ловится.
И вообще, как это всё протестировать - какие именно ситуации какой сигнал генерируют ?

[Антон (LogRus)]

насчет того, как все сигналы завернуть в один обработчик, то твой код верен

А вот когда каждый из них генерится так фиг его знает
У нас обработчики переопределены только для двух описанных сигналов, и вроде этого вполне всем хватает.
SIGTERM вообще наверное лучше не трогать, он посылается кажется например, если ты из TaskManager убиваешь процесс, я не думаю что при этом следует вообще, что-то программе делать, если конечно нет реальной необходимости обратать именно конкретный случай как-то специфично.

Кстати рекомендую, сохранять обработчики по умолчанию и в своём обработчике после выполнения работы по сохранению логов и прочего, вызывать обработчик по умолчанию.

[Алексей++]

понятно, спасиб

А что будет, если не верну дефолтный обработчег ?

[Антон (LogRus)]

если ты его не вернёшь тогда фиг с ним
только я говорил не вернуть, а вызвать как в приведённом ранее коде

[Алексей++]

ааа, точняк ))