Подача команды с использованием перенаправления файла или конвейера не всегда работает
Основные практические различия между контейнером Docker и виртуальной машиной:
Образ Docker — это просто базовый образ исходной системы(
debootstapпомогает получить этот базовый образ ), и, конечно, он может (или нет )содержать ядро, initrd... Но ядро, initrd... не имеют смысла вместо исследований, разработки, других зависимостей пакетов. Так что, если они не нужны, то их можно смело удалять.Контейнеры Docker запускаются в другом пространстве имен , которое скрывает реальные системные процессы, сетевые подключения... от воздействия контейнера. Проще говоря, вы не можете
killреальный системный процесс из контейнера Docker, но вы можете видеть процесс контейнера Docker как обычный процесс из реальной системы и делать с ним что угодно. VM организована сложнее вместо пространства имен концепции :все VM запускаются как огромные приложения, которые управляются программным обеспечением VM (VirtualBox, VMware... ). Программное обеспечение VM перехватывает все системные вызовы из этого приложения и передает их на реальное оборудование. Поэтому они медленнее, чем концепция контейнера.Контейнеры Docker обеспечивают поддержку среды, которая необходима для запуска некоторых приложений (определенных версий библиотек, программных компонентов... ), но не ядра. Поэтому, если ваше приложение использует новые функции ядра, они не будут работать.
Контейнеры Docker часто не содержат полного образа системы, поскольку основной целью концепции Docker является совместное использование приложений. Основной целью VM является совместное использование операционных систем.
Нет никакой разницы в реальной системе, которая запускает определенный образ Docker (, за исключением случаев, когда ваше приложение зависит от конкретного ядра ).
От участников comp.lang.fortran:
Одна из проблем заключается в том, что основной цикл:
done =.false.
do while (.not. done)
call main_menu(command)
call run_command(command, surf, options, done, ioerror)
end do
вызывает «выполнить команду _»:
subroutine run_command(command, surf, options, done, ioerror)
...
logical, intent(out) :: done
integer, intent(inout) :: ioerror
gfortran, похоже, предполагает, что, поскольку значение 'done' никогда не используется командой 'run _', нет смысла фактически выполнять оператор 'done =.false'. и поскольку «выполнить команду _» на самом деле не присваивает своему аргументу «выполнено» что-либо, если только не увидит команду «выход», «выполнено» остается неинициализированным, когда основной цикл проверяет его. Иногда оно ложно, а иногда содержит мусор, и в этом случае оно оценивается как истинное, и основной цикл завершается досрочно.
Изменение намерения «done» на «inout», кажется, решило проблему.
Установка «done» перед оператором «select case» в команде run _также работает:
done =.false.
select case (command)
...
Я предполагаю, что это правильный способ исправить это, и что поведение компилятора, хотя и удивительное для некоторых из нас (, включая меня ), на самом деле является правильным.
valgrind помог найти это.
И с другого плаката:
В том же духе несколько случаев
type(options_type), intent(out) :: opt
в файле menu.f90 следует изменить на
type(options_type), intent(inout) :: opt
или предложение о намерении следует опустить, потому что аргумент с намерением (out )становится неопределенным при входе в подпрограмму и остается неопределенным, пока не получит значение в подпрограмме перед возвратом.
Другие предложения включали компиляцию и запуск с параметрами для проверки границ массива и т. д.
Я пытался скомпилировать программу со старыми версиями gfortran (gfortran 7.x и 8.x ), и все работает правильно. Но проблема сохраняется с более новыми версиями gfortran (9.x и 10.x ). Однако я решил это странное поведение в gfortran 9.x и 10.x, добавив флаг -Ogили -O0при компиляции программы.
Причина, по которой это происходит, объясняется в ответе @RoboNerd.