Отладка ошибки недопустимого адресного пространства

Я создал код C++, использующий OpenACC, и скомпилировал его с помощью компилятора PGI для использования на графическом процессоре Tesla.

Компиляция проходит успешно без каких-либо предупреждений.

Запускаю программу и получаю две ошибки:

call to cuStreamSynchronize returned error 717: Invalid address space
call to cuMemFreeHost returned error 717: Invalid address space

Интернет, похоже, мало что знает об этом, кроме предложения включение единой памяти, чтобы проблема автоматически заметалась под ковер. Я не сторонник такого решения.

Как мне отладить это?

С кодом C++, работающим только на ЦП, я запускал gdb, выполнял обратную трассировку и говорил: «Ага!»

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

Запасной вариант — начать комментировать строки до тех пор, пока проблема не исчезнет, ​​но это тоже кажется неоптимальным.


c++ debugging openacc
person Richard    schedule 06.09.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете использовать «cuda-gdb» для отладки кода устройства или использовать «cuda-memcheck» для проверки ошибок памяти.

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

Я не видел эту ошибку раньше и не вижу никаких предыдущих отчетов об ошибках, поэтому могу только теоретизировать относительно причины. Одна из возможностей — если у вас есть переменная с общей памятью (скаляр или массив в предложении «private» или директива «cache»), которая передается из внешнего группового цикла в векторную процедуру. В этом случае векторная процедура может обращаться к переменной, как если бы она находилась в глобальной памяти.

Скорее всего, какой бы ни была причина, это ошибка компилятора. Если возможно, опубликуйте или отправьте в службу поддержки клиентов PGI ([email protected]) воспроизводящийся пример, и я передам его нашим инженерам-компиляторам для изучения.

Я также могу попытаться найти обходной путь, когда лучше пойму причину. А пока вы можете попробовать скомпилировать с "-ta=tesla:nollvm,keepgpu". «nollvm» заставит компилятор генерировать промежуточную версию CUDA C ядер OpenACC, в отличие от генератора кода устройства LLVM по умолчанию. «keepgpu» сохранит промежуточный файл «.gpu», который вы можете проверить.

person Mat Colgrove    schedule 06.09.2017
comment
Спасибо, Мэт! Вероятно, пройдет пара дней, прежде чем я смогу это проверить, но я отправил электронное письмо с кодом нарушения (достаточно коротким, чтобы его можно было воспроизвести) на адрес, который вы предложили. - person Richard; 07.09.2017
comment
Проблема в том, что у вас есть локальная переменная, используемая в atomic. Atomics позволяет использовать только общую или глобальную память. Я отправил вам обновленный исходный файл с предлагаемыми изменениями, которые решают эту проблему и улучшают производительность вашего кода. - person Mat Colgrove; 07.09.2017

arrow_upward
0
arrow_downward

Есть несколько полезных переменных среды, которые помогают в отладке. Любая комбинация может быть включена:

export PGI_ACC_TIME=1   #Profile time usage
export PGI_ACC_NOTIFY=1 #Set to values 0-3 where 3 is the most detailed
export PGI_ACC_DEBUG=1  #Extra debugging info
person Richard    schedule 23.09.2017