Порча памяти в FFTW

[jur]

Продолжение темы "Давайте поговорим об exeption'ах?"

Спасибо, друзья, за ценные мысли!

Ну и тяжело же с этими вопросами...  Угрохал больше недели на предмет обнаружения ошибки переполнения буфера. Объясню. Я применяю известную библиотеку FFTW. Она обладает функцией вычисления так называемого плана расчета FFT. Я сделал класс, который заготавливает массивы, вычисляет планы, а потом производит полезную работу.

Столкнулся с ситуацией, когда ошибка в моей части (запись массива результата) портит находящийся за нею в классе план. Результат: в библиотеке FFT производится вызов функции по не существующему адресу. Пытаюсь отлаживать - в стеке вызовов пару точек системной DLL... (по-моему NTDLL.DLL)

Где искать, куды бечь?... Как отловить порчу полезных данных?

Может и против такой напасти существует "противоядие"?

Спасибо, друзья!

[Dimka]

jur, а почему надежды возлагаются на отладчик? По коду не отследить размеры буферов?

P.S. В библиотеке свои менеджеры памяти и свои особенности типа:

Код: (C)

fftw_complex *sourceIntensities = (fftw_complex *)fftw_malloc(sizeof(fftw_complex) * input.widthPx);

Их тоже кто-нибудь мог не знать/забыть и потому проигнорировать.

[lapulya]

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

Причем, может это связано, как заметил Димка, именно с распределением памяти (кто ее выделяет и как, и кто ее освобождает и как), а не с выходом за пределы массива при записи, гадать можно очень долго.

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

[jur]

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

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

Т.е. я представляю это дело так. Заводим эксепшен на выход за границы массива. В функции работы с массивом устанавливаем его границы. Когда границы будут нарушены, мы тут же вывалимся в эксепшен и сможем локализовать проблему. Вот как-то так...

[RXL]

Может просто стоит выделять массив большего размера? Ведь FFT дает на один элемент больше, чем исходные семплы, а длина свертки - сумма длин семпла и фильтра.

[jur]

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

Да и ошибку оставлять нельзя. Ведь выходной массив-то неправильный!

Нашел очень интересную штуковину. В меню "Debug -> Exceptions...". Похоже, что это именно то, что мне нужно. Вот картинка:

Подскажите, пожалуйста, как этот механизм использовать?

[Dimka]

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

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

Компиляторы некоторых языков (того же Pascal) умеют контролировать выход за пределы массива, но это относится к массивам, размеры которых заданы на этапе компиляции.

А вообще непонятно. Если ты знаешь, что проблема именно в переполнении массива, то почему не переработать алгоритм? В место, где выделяется память, передать информацию о необходимом размере массива.

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

[jur]

Компиляторы некоторых языков (того же Pascal) умеют контролировать выход за пределы массива, но это относится к массивам, размеры которых заданы на этапе компиляции.

Естественно отпадает.

А вообще непонятно. Если ты знаешь, что проблема именно в переполнении массива, то почему не переработать алгоритм? В место, где выделяется память, передать информацию о необходимом размере массива.

Так алгоритм-то верный! :-) Только не хотелось бы при записи каждого байта контролировать правильность адреса. Тут вот в чем дело. Я знаю, что запись может производиться только в правильный адрес. Но я допустил ошибку (грубо говоря, к примеру объявил указатель на слово вместо указателя на байт). Поэтому было бы неплохо, если бы при входе в функцию я установил границы массива и сразу отловил ошибку.

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

Ошибок проектирования нет, есть простые ошибки в кодировании :-)

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

Думается, что перехватив это исключение я сумел бы найти, где "собака порылась"...

[Вад]

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

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

Кстати, в твоём случае тоже можно было бы использовать вектор, если написать к нему аллокатор, использующий функции FFTW для управления памятью.

[lapulya]

одна из прелестей С++ это скорость работы, так вот для достижения этой скорости никаких лишних проверок (для быстродействия это именно лишняя) в рантайм нет и это очень хорошо (имхо).

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

[Антон (LogRus)]

jur, среда разработки какая?
скомпилированная с которыми хитрыми параметрами программа в MSVC бросает исключения при записи за пределы массива и контролируется целостность памяти на входе и выходе из фукнций
довольно занятная хрень.

вот тебе отправная точка для изысканий:
http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/69d85d29-8e1f-4fa3-9ab6-4752b9d82a59


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

Код:

for(int i=0; i != size; ++i)

и завести привычку писать

Код:

T* array_end = array + size;
for(T* it = array; it != array_end; ++it)

кстати большинство (если не все) алгоритмов STL прекрасно работают с указателями вместо итераторов

Кстати насчёт аллокатора полностью поддерживаю

[Вад]

LogRus, собственно, я так и делаю (особенно когда приходится писать не на C++, а на C/ObjectiveC ), но, согласись, такой стиль требует несколько большей дисциплины, чем просто создать контейнер и использовать его итераторы. Ошибку сделать проще. Хотя, может, есть доля правды в том, что избегание ошибок чужими руками (через те же контейнеры) не дисциплинирует должным образом

[Dimka]

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

[jur]

Кстати, в твоём случае тоже можно было бы использовать вектор, если написать к нему аллокатор, использующий функции FFTW для управления памятью.

Вся беда в том, что эту ошибку я допустил в довольно громоздкой процедуре фильтрации сигнала. Там вычисляется 20 FFT и еще всякие математики. Пришлось опуститься до отдельных инструкций SSE для оптимизации быстродействия (компилятор тут, естественно, оказался абсолютно бессилен). Поэтому я не представляю себе путей использования штучек ООП в данном конкретном случае. Прошу меня простить, что сразу не указал особенности моей среды.

jur, среда разработки какая?
скомпилированная с которыми хитрыми параметрами программа в MSVC бросает исключения при записи за пределы массива и контролируется целостность памяти на входе и выходе из фукнций
довольно занятная хрень.

Я работаю в Студии 2008 (прошу прощения, что сразу не указал). Заметил, что компилятор довольно хорош. Начинаю склоняться к мнению, что современные компиляторы уже не нуждаются в ассемблерной оптимизации руками. (Кроме моего случая с командами SSE и SSE2.)

вот тебе отправная точка для изысканий:
http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/69d85d29-8e1f-4fa3-9ab6-4752b9d82a59

Так там чегой-то про утечку памяти... А у меня утечек нет, просто память портится не там, где надо.

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

Ведь это же прекрасно! Разве не так? :-)

[jur]

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

Кстати должен сказать, что у меня совсем нет опыта работы с контейнерами и итераторами. Я пришел из embedded, где 51-й или AVR с PIC'ами рулят :-) Если сказать точнее, то я продолжаю быть embedded'щиком, который вынужден использовать всю эту вындусячную хрень. Правда, справедливости ради, эта "вындусячная хрень" здорово помогает избавляться от "изобретания велосипеда". В моем случае - это DirectX 9. Из плюсов еще отметил бы независимость от аппаратуры. Винда ставится - все, нет вопросов! :-)

[Вад]

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

Скажем, у STL для таких вещей есть отладочные макросы, проверяющие обращение за пределы массива. assert-ы в нужных местах стоят, и всё.

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

[lapulya]

jur,

Ведь если ошибок нет, то накладние расходы исчезающе малы...

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

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

[jur]

Скажем, у STL для таких вещей есть отладочные макросы, проверяющие обращение за пределы массива. assert-ы в нужных местах стоят, и всё.

Очень слаб я еще в вопросах STL... Буду заниматься углублением понимания этих вещей...

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

Я имел ввиду другое. Если я соответствующим образом задал отладочные регистры процессора, то он аппаратно обнаружит нарушение памяти и сообщит мне об этом.

jur,

Ведь если ошибок нет, то накладние расходы исчезающе малы...

Да как же они малы, когда ты предлагаешь проверять каждое обращение к любому элементу каждого массива?

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

Хочу сказать. Большое спасибо, друзья! С вашей помощью я примерно определился, куда следует копать: учиться использовать более изощренные возможности, которые предоставляют современные технологии программирования. Тяжело это embedded'щику...

Спасибо!

[Dimka]

Тут ещё всё сильно зависит от языка программирования. Например, в Pascal и Ada можно написать так:

Код: (Pascal)

type
  TRange = 1..1000;
  TArray = array [TRange] of Word;
var
  a: TArray;
  i: TRange;
  x: Word;
begin
  { что-то делаем }
  a[i] := x;
  { что-то делаем }
end.

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

[jur]

Тут ещё всё сильно зависит от языка программирования. Например, в Pascal и Ada можно написать так:
...
Здесь контроль осуществляется не только за границами массива, но и за диапазоном допустимых значений индекса массива i - этой переменной просто нельзя присвоить неподходящее для массива значение, возникнет ошибка.

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

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

Впрочем, на Интеловской платформе, похоже, моё пожелание неосуществимо... Жаль... Все у них, начиная с уродливого 8080 (даже 8008), не как у людей...

Придется углубляться в STL'ы всякие. Для моих задач это все абсолютно лишняя хренотень, но раз эта хренотень может помочь в поиске ошибок, то придется этот балласт тянуть на горбу... (Или попробовать разработать какие-нить макросы, которые с одной стороны не сильно гробят быстродействие, а с другой стороны помогают в отладке. В идеале после отладки их можно было бы отключить и не расходовать на них ресурсы процессора. А с третьей стороны, законы Мерфи бессмертны... Как только отключишь отладочные механизмы - сразу повылезают ошибки... Да, очень и очень не даром мы, коллеги, зарабатываем свой хлеб!!! :-)

[Dimka]

Но я хотел получить помощь системы (благодаря аппаратным возможностям процессора) в информировании меня о недозволенном выходе за пределы массива.

Почему именно аппаратным? Всё, о чём тут говорится, сводится к одной мысли: кто-то должен позаботиться о наличии такого механизма. Ты говоришь, что это должен быть разработчик железа; тебе говорят, что не обязательно: во-первых, есть программные среды с подобным контролем, во-вторых, сам разработчик может об этом позаботиться.

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

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

[Антон (LogRus)]

Dimka, +1

[jur]

Почему именно аппаратным?

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

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

А кто же еще, если речь об аппаратной поддержке?!

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

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

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

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

[RXL]

jur, а все правы, но по своему
Знания лишними не бывают, но если времени на них нет, то они лишние.

[Dimka]

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

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

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

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

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

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

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

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

[jur]

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

Да понимаю я... Просто мне хотелось применить еще и аппаратный механизм :-)

А так - да, макросы, ассерты и т.п и т.д. Некоторыми из существующих механизмов я пользоваться умею, некоторые еще изучаю/учусь пользоваться.

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

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

Спасибо за помощь!

P.S. В нашей фирме разрабатываются приборы. УЗИ сканеры для врачей. Для нас важно, чтобы доктор вообще не касался компьютерной специфики, т.к. это ему только мешает. В нашей отрасли подавляющее большинство экранов приборов выглядят, как простейшие поделки 70-х годов на 8-битных процессорах :-) Внутри теперь чаще всего стоят серьезные материнки, или что-то свое, еще более крутое. А на черном экране прибора - УЗИ картинка и несколько строчек текста... По-спартански, короче... :-)

[Dimka]

P.S. В нашей фирме разрабатываются приборы. УЗИ сканеры для врачей. Для нас важно, чтобы доктор вообще не касался компьютерной специфики, т.к. это ему только мешает. В нашей отрасли подавляющее большинство экранов приборов выглядят, как простейшие поделки 70-х годов на 8-битных процессорах Внутри теперь чаще всего стоят серьезные материнки, или что-то свое, еще более крутое. А на черном экране прибора - УЗИ картинка и несколько строчек текста... По-спартански, короче...

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