Как локализовать ошибку SIGSEGV?

[Лекс Айрин]

и книжку "херак, херак и в продакшен" я бы почитал с удовольствием.

Все хотели бы... но так редко бывает. Сейчас, по крайней мере, есть куча инструментов, помогающих программы создавать.

[zub]

Я не в очках, без бороды, да и не програмист совсем)) а програмисты они такие, да. лучше удалить акаунт когда они заходят на форум))
Если херак-херак - глупо потом удивляться мистике и коварству. Отладка это обязательный процесс, часто более долгий чем само написание
Мне вот почемуто думается когда читаю последние топики - что ктото херакает не думая, а потом ктото другой уверен что лазарус и фпц это сырые поделки

[Лекс Айрин]

zub, я в очках и почти бородат))) Но тоже нифига не программист(((

И, думаю, что отладку лучше производить по мере написания кода. Иначе в конце напишешь совсем не то, что хотел.

[azsx]

Если херак-херак - глупо потом удивляться мистике и коварству.

Это только если Вы окончательно веру в снегурочку потеряли. Если надежда еще теплится, что к новому году Вы встретите снегурочку, то и комп у Вас по сути коварная гудящая коробка, стоит под столом, чо то сам себе думает...

Отладка это обязательный процесс, часто более долгий чем само написание

Есть два варианта. Запустить в цикле и заняться другими задачами. Убиться, но найти проблему, стать умнее и потерять это время. Я свой выбор сделал.

читаю последние топики - что ктото херакает не думая, а потом ктото другой уверен что лазарус и фпц это сырые поделки

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

Но тоже нифига не программист(((

боже мой, одни левые личности
У нас разные характеры. Если я решил подружить с девушкой - то я готов на многое. Будет там любовь или мягкая перина меня слабо волнует. зы Конечно, иногда приходится отступать и даже сдаваться.
Если мне надо написать программу, то отладка меня будет волновать только если совсем нифига работать не будет. Это меня пхп испортил.

[Лекс Айрин]

боже мой, одни левые личности

да оно везде практически так. Тем более, что профессионалы предпочитают С, яву и ассемблер. А из паскалеподобных -- дельфи.

Если мне надо написать программу, то отладка меня будет волновать только если совсем нифига работать не будет.

не советую. Со временем ошибки могут наложиться так, что проще будет заново написать. Особенно, если используются некоторые трюки. Кстати, трюки лучше добавлять после того как код полностью рабочий.

[azsx]

Со временем ошибки могут наложиться так, что проще будет заново написать.

Вы очень мудры. Иногда я возвращаюсь к старому коду, который перестал работать. Очень часто я не ищу проблем в старом алгоритме, а переписываю его. Слава богу, что такое бывает крайне редко.

[Лекс Айрин]

Многие так себя ведут. Хотя лучше, конечно, понять.

[zub]

>>Есть два варианта. Запустить в цикле и заняться другими задачами. Убиться, но найти проблему, стать умнее и потерять это время. Я свой выбор сделал.
А если снегурка сбежит? машина мломается? тоже в батник и зациклить?

[azsx]

А если снегурка сбежит?

На земле 7 млрд людей, половина девчонок. Будет конечно сложно, придется погоревать, поплакать, выпить немного. Но всё будет хорошо.
зы
и ваще Вы правы, повторить поиск снегурочки. Только надо заранее поставить условие, если сотая сбежала - то баста. Хорош бегать по бабам, лучше делом займись и т.п.

[Лекс Айрин]

zub, да полно таких... завернут ошибку в try и как будто ее нет. А то, что ее можно предварительно не допустить предпочитают не думать.

Добавлено спустя 1 минуту 33 секунды:

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

А потом удивляются, что европейцы вымирают, а в Китае население продолжает расти..

[Mirage]

Воспроизвести можно все. Было бы желание. И необходимость.
Чтобы найти ошибку надо во-вервых скомпилировать в дебажном режиме. Тогда будет видно где упало.
Во-вторых писать логи, как уже говорили, обязательно.

Судя по симптомам, ошибка в работе с памятью. Либо не выделяется где нужно, либо удаляется то, что потом используется. В языках без автоматического управления памятью, надо иметь четкую стратегию управления ей вручную.
Т.е. для любой структуры данных четко понимать, какая часть программы ей владеет и где и когда их высвобождает.
Это не особо сложно, но надо иметь привычку.

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

[azsx]

Снова хрумер пробивает, вопрос ответ. зы невпопад работает.

[zub]

В чем прикол адмиинистрации править сообщения ботов а не удалять?

[McLion]

В чем прикол адмиинистрации править сообщения ботов а не удалять?

На бот что-то не похоже.

[serbod]

Поделюсь опытом как уменьшить вероятность ошибок. Этот текст я держу в папке с каждым крупным проектом, для себя и потомков. Вообще таких рекомендаций гораздо больше, например Object Pascal Style Guide - это как правила дорожного движения, кто их соблюдает, меньше попадает в аварии.


Все предупреждения компилятора и проверки в рантайме должны быть включены.

Все имена должны иметь однозначный смысл. Короткие имена допустимы только в коротких блоках.

ВНИМАНИЕ! При инициализации и финализации DLL нельзя создавать или удалять фоновые процессы TThread а также любые объекты, использующие TThread! Также внутри DLL нежелательно использовать Sleep(0), но можно Sleep(1) или больше.

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

При работе с динамически создаваемыми объектами следует придерживаться правила, что создание и удаление должно происходить в одном модуле, как можно ближе друг к другу. В идеале так:

Код: Выделить всё

Obj := TObj.Create();
try
  Obj.Use();
finally
  Obj.Free();
end;


Все объекты, доступные за пределами функции/процедуры/метода должны удаляться при помощи FreeAndNil().

Необходимо следить за утечками памяти, объектов USER и GDI. Проверить можно многократным созданием-удалением форм и объектов.

В конструкторе лучше не трогать наследуемые свойства, они могут вызвать цепную реакцию. Только из секции private.

Всегда использовать модификатор const для параметров типа string, record, array, если это не возвращаемый параметр. В этом случае параметр передается по ссылке (не создается временный дубликат) и защищен от записи. Пример: procedure(const AStr: string);

По возможности, вместо CriticalSection использовать атомарные операции InterlockedIncrement / InterlockedExchangeAdd. Для атомарного изменения буфера или объекта заранее подготовить копию с новыми данными и подменить указатель на буфер или объект при помощи InterlockedExchange.

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

procedure(var Str: string) лучше, чем function(): string, поскольку не вызывает блокировки и сброса кеша CPU.

Для парсинга статичный буфер лучше, чем строка или динамический массив. Парсить строки лучше при помощи PosEx() вместо перебора по индексу.

TMemoryStream желательно лишний раз не создавать-удалять и не изменять размер. В пределах размера можно творить что угодно.

И вообще объекты и буферы лучше лишний раз не создавать-удалять, а использовать повторно.

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