Самая гнусная ошибка?

← →
Новый русский (2011-11-30 19:50) [0]

По мне то, когда какая-нибудь "зараза" портит стек, а сказывается это в другом месте.

А по вам?

← →
ProgRAMmer Dimonych © (2011-11-30 19:54) [1]

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

← →
Ega23 © (2011-11-30 19:55) [2]

Неправильная женитьба. Тогда эта зараза портит жизнь, а сказывается это на работе.

← →
TUser © (2011-11-30 19:57) [3]

Удалено модератором

← →
И. Павел © (2011-11-30 20:15) [4]

Access violation

← →
Rouse_ © (2011-11-30 20:17) [5]

Ошибка лишь тогда ошибка, когда ее нельзя исправить.

← →
Юрий_ (2011-11-30 20:43) [6]

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

← →
Jeer © (2011-11-30 20:43) [7]

> Ошибка лишь тогда ошибка, когда ее нельзя исправить.

"Ошибка, не подлежащая исправлению - катастрофа" (С) Jeer

← →
Mystic © (2011-11-30 20:48) [8]

Ошибки синхронизации потоков

← →
alexdn © (2011-11-30 20:51) [9]

a:real;
a:=выражение с делением;
if a=0 then {до сих пор не знаю что делать..}

← →
alexdn © (2011-11-30 20:55) [10]

точнее так if frac(a)=0 then ..

← →
Anatoly Podgoretsky © (2011-11-30 20:57) [11]

> Новый русский (30.11.2011 19:50:00) [0]

Та за которую не заплатят

← →
Styx (2011-11-30 20:57) [12]

> Jeer © (30.11.11 20:43) [7]
>
> > Ошибка лишь тогда ошибка, когда ее нельзя исправить.
>
>
> "Ошибка, не подлежащая исправлению - катастрофа" (С) Jeer
>
>

http://gorodlgov.ru/node/5857

← →
Jeer © (2011-11-30 20:59) [13]

> Mystic © (30.11.11 20:48) [8]
>
> Ошибки синхронизации потоков

Приходится изобретать свои решения - Delphi не лучший инструмент для "многосознательной жизни".
Принцип довольно простой: "Результат должен быть один и в заданное "время".
По другому - всегда есть место для "стрелки" и "разруливания".
Если совсем просто - "Жизнь складывается из отрезков"
или совсем хрестоматийное: "Разделяй и властвуй".

← →
Dimka Maslov © (2011-11-30 21:01) [14]

> Как то раз искали недели две причину

Я несколько лет не мог понять, почему прога вылетает. Оказалось выход за границы массива. Причём когда в куче память выделалась системой с небольшим запасом (в большинства случаев) - ошибка не происходила. Но если сразу за массивом шла недоступная область...

← →
alexdn © (2011-11-30 21:09) [15]

> alexdn © (30.11.11 20:55) [10]
вот так сказать графическое отображение
procedure TForm1.Button1Click(Sender: TObject);
var x,y,z:real;
begin
x:=35.87;
y:=0.17;
z:=x/y;
if frac(z)=0 then label1.Caption:=floattostr(z);
end;

← →
Jeer © (2011-11-30 21:16) [16]

> alexdn © (30.11.11 21:09) [15]

И что ?

← →
Kerk © (2011-11-30 21:19) [17]

У Дональда, нашего, Кнута есть замечательная работа: The Errors of TeX. Он много лет вел дневник ошибок возникающих в TeX и затем классифицировал их, разбив на 15 категорий. Целиком эту работу мне найти пока не удалось, читал выжимку в книжке, но надежд не оставляю.

← →
Rouse_ © (2011-11-30 21:19) [18]

> Jeer © (30.11.11 20:59) [13]
> Delphi не лучший инструмент для "многосознательной жизни".

Нормальный инструмент

← →
Kerk © (2011-11-30 21:20) [19]

> alexdn © (30.11.11 20:51) [9]
>
> a:real;
> a:=выражение с делением;
> if a=0 then {до сих пор не знаю что делать..}

Сравнивай не с нулем, а проверяй на попадание в диапазон [-e, e]
Где e - малое число.

У тебя вычислительной математики чтоли не было?

← →
Kerk © (2011-11-30 21:22) [20]

С потоками в Delphi OTL неплохо помогает http://code.google.com/p/omnithreadlibrary/
Ну и без этой библиотеки вроде проблем нет, разве что писанины больше

← →
Rouse_ © (2011-11-30 21:27) [21]

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

← →
Jeer © (2011-11-30 21:38) [22]

> Rouse_ © (30.11.11 21:19) [18]
> Нормальный инструмент

Лучший инструмент создан давно - топор :)

P.S.
Если смотреть за метаморфозами изменения подхода к программированию нитей в версиях Delphi - разница заметна.
Отчасти - вызвана изменениями в платформе, но более - лавированием.

← →
Ega23 © (2011-11-30 22:24) [23]

> if frac(z)=0 then

if Abs(frac(z)) <= Epsilon then ...

← →
Кто б сомневался © (2011-11-30 23:07) [24]

> Mystic © (30.11.11 20:48) [8]
>
> Ошибки синхронизации потоков
>

Если использовать крит секции, Interlocked функции (почаще кстати - это самый простой и быстрый вариант), OnTerminate (когда то я "забыл" про него - запомнил надолго :) потока - никаких проблем не будет.
Обычно на такие элементарные ошибки натыкаются те кто только начала работать с многопоточными проектами, и я в свое время тоже натыкался.

← →
sniknik © (2011-11-30 23:52) [25]

> Самая гнусная ошибка?
чужая... со своими проблем нет.

← →
Petr V. Abramov © (2011-11-30 23:56) [26]

ошибка проектирования, остальные или легко устраняются, или не фатальны :)

← →
Германн © (2011-12-01 00:53) [27]

> Самая гнусная ошибка?

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

P.S. Правда такое было давно. До покупки Эврики. :)

← →
DiamondShark © (2011-12-01 02:53) [28]

> какая-нибудь "зараза" портит стек

> Повреждение кучи.

> Access violation

В типобезопасных средах этого не бывает.

← →
RTFM (2011-12-01 03:16) [29]

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

А вот многопоточность или повреждения стека....

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

KilkennyCat © (01.12.11 03:18) [30]
менеджеры, постановщики задач, это вообще отдельная песня. неважно на какой стадии проект.

← →
Компромисс (2011-12-01 09:49) [32]

> > Самая гнусная ошибка?
> чужая... со своими проблем нет.

+1.

Буквально вчера. Запускаю чужую консольную программу, %ERRORLEVEL% становится 128, никаких сообщений никуда не выводится. По документации 128 - General Error. 3 часа убил, пробуя разные догадки, пока не нашел ту же программу с оконным интерфейсом, в которой данная ошибка не гасилась, а отображалась пользователю.

> Компромисс (01.12.2011 09:49:32) [32]

Гашение ошибки не ошибка, а диверсия

> Самая гнусная ошибка?

В ДНК

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

← →
Компромисс (2011-12-01 12:23) [36]

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

Проверяйте текст ошибки. Если совпадает с "ошибка формата запроса", показывайте сообщение "Ошибка не у нас, все претензии пишите по адресу..." :)

Пока вы тут про кучу говорили, я несколько часов вылавливал ошибку:

fInBuffer: PByteArray; ... ZeroMemory(@fInBuffer, IN_BUFFER_SIZE);

Собака такая собака ))

> показывайте сообщение "Ошибка не у нас, все претензии пишите по адресу..." :)
разбираться все одно нам, с какой бы "стороны" не обратились (то что после "претензий по адресу" проблему перенаправят нам вне сомнений), ввести лишнее звено в цепочку значит добавить проблем.

p.s. если бы "ТАМ" были адекватные, они бы после первого раза все бы поменяли.
p.p.s. а вообще - "не учите меня жить, лучше помогите материально".

> Если использовать крит секции, Interlocked функции (почаще
> кстати - это самый простой и быстрый вариант), OnTerminate
> (когда то я "забыл" про него - запомнил надолго :) потока
> - никаких проблем не будет.
> Обычно на такие элементарные ошибки натыкаются те кто только
> начала работать с многопоточными проектами, и я в свое время
> тоже натыкался.

Есть еще посылка сообщений и прочие радости. Более того, есть инструменты для верификации многопоточных алгоритмов. Но все равно количество вариантов обычно растет комбинаторно, всегда можно что-то упустить и потом искать. Race condition все-таки не самая редкая ошибка :)

Самая гнусная ошибка? Найти похожие ветки