Ada_Ru форум

Обсуждение языка Ада

Утечка памяти

Оставить новое сообщение

Сообщения

KsiCom
Утечка памяти
2011-07-31 10:51:56

Вот такая простая программа:

 

gmod.ads

------------------------------------------------

with Ada.Numerics.Generic_Real_Arrays;

 

generic

with package Real_Arrays is new Ada.Numerics.Generic_Real_Arrays (<>); use Real_Arrays;

package Gmod is

 

procedure Proc1;

 

end Gmod;

------------------------------------------------

 

gmod.adb

------------------------------------------------

package body Gmod is

 

procedure Proc1 is

X, Y : Real_Vector (1 .. 10) := (others => 0.0);

begin

loop

X := X + Y;

end loop;

end Proc1;

 

end Gmod;

------------------------------------------------

 

lmod.ads

------------------------------------------------

with Ada.Numerics.Real_Arrays;

with Gmod;

 

package Lmod is new Gmod (Ada.Numerics.Real_Arrays);

------------------------------------------------

 

test1.adb

------------------------------------------------

with Lmod;

 

procedure Test1 is

begin

Lmod.Proc1;

end Test1;

------------------------------------------------

 

собирал и выполнял так:

 

[ksicom@x58l GNAT_BUG]$ gnatmake -g test1 -largs -lgmem

gcc -c -g test1.adb

gcc -c -g lmod.ads

gcc -c -g gmod.adb

gnatbind -x test1.ali

gnatlink test1.ali -g -lgmem

[ksicom@x58l GNAT_BUG]$ ./test1.

Killed

[ksicom@x58l GNAT_BUG]$ gnatmem 10 test1

Global information

------------------

Total number of allocations :187317

Total number of deallocations : 0

Final Water Mark (non freed mem) :1835.70 Megabytes

High Water Mark :1835.70 Megabytes

 

Allocation Root # 1

-------------------

Number of non freed allocations :187317

Final Water Mark (non freed mem) :1835.70 Megabytes

High Water Mark :1835.70 Megabytes

Backtrace :

??:0 system.secondary_stack.ss_allocate

??:0 <ada__numerics__real_arrays__instantiations__Oadd__3Xnn> gmod.adb:7 lmod.proc1

test1.adb:5 test1

b~test1.adb:157 main

 

[ksicom@x58l GNAT_BUG]$.

 

Проверял на GNAT2008,9,10,11

ОС: Archlinux, CentOS4.9

 

Если with package из generic перенести в сам пакет в виде package Real_Arrays is ..., то всё нормально работает.

Ошибка в компиляторе?

On Sun, 31 Jul 2011 14:51:56 +0400, you wrote:

 

Вот такая простая программа:

 

procedure Proc1 is

X, Y : Real_Vector (1 .. 10) := (others => 0.0);

begin

loop

X := X + Y;

end loop;

end Proc1;

 

Этот цикл никогда не заканчивается.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Вот такая простая программа:

 

procedure Proc1 is

X, Y : Real_Vector (1 .. 10) := (others => 0.0);

begin

loop

X := X + Y;

end loop;

end Proc1;

 

Этот цикл никогда не заканчивается.

 

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

On Sun, 31 Jul 2011 18:37:33 +0400, you wrote:

 

Вот такая простая программа:

 

procedure Proc1 is

X, Y : Real_Vector (1 .. 10) := (others => 0.0);

begin

loop

X := X + Y;

end loop;

end Proc1;

 

Этот цикл никогда не заканчивается.

 

Если бы не было утечки памяти, то этот цикл крутился бы бесконечно. >Но из-за утечки она убивается ОС, когда занимает всю память. В принципе >можно было бы и без бесконечного цикла, но так нагляднее демонстрируется >проблема.

 

В GNAT Pro 6.3.1 и под Fedora 15 проблемы не увидел.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

В GNAT Pro 6.3.1 и под Fedora 15 проблемы не увидел.

 

GNAT Pro 6.3.1 соответствует примерно GPL GNAT 2010?

 

А сколько памяти занимает программа при работе?

 

Попробовал ещё под Windows XP. (GPL GNAT 2010)

Вылетает через пару минут работы с сообщением:

 

raised STORAGE_ERROR : heap exhausted

 

При выполнении размер программы в памяти скачет в диапазоне 10 .. 300 Mb

On Sun, 31 Jul 2011 21:44:16 +0400, you wrote:

 

В GNAT Pro 6.3.1 и под Fedora 15 проблемы не увидел.

 

GNAT Pro 6.3.1 соответствует примерно GPL GNAT 2010?

 

Нет. Но похоже, что таки иногда вылетает, не понятно когда.

 

А сколько памяти занимает программа при работе?

 

До 40 Mb. Причем, в самом начале хватает аж гигабайт, а потом отдает.

Попробовал ещё под Windows XP. (GPL GNAT 2010)

Вылетает через пару минут работы с сообщением:

 

raised STORAGE_ERROR : heap exhausted

 

При выполнении размер программы в памяти скачет в диапазоне 10 .. 300 Mb

 

Под Fedora - 310 Mb, но не вылетел а стабилизировался.

 

Очень похоже на баг. Ошибка похоже в операции +. Почему она использует "кучу" не понятно.

 

Надо будет проверить на GNAT Pro 6.4, но у меня его сейчас под рукой нет.

Вообще, с generic-ами традиционно засада, но обычно на этапе компиляции, а не во-время исполнении. Это что-то новенькое.

 

Когда выйду из отпуска, проверю отдельно, так как весь наш текущий проект сильно завязан на generic-и. Тогда может буду "рапорт" писать. Но Вы тоже пишите, т.к. каналы Pro и FSF совсем разные, как я понимаю.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Очень похоже на баг. Ошибка похоже в операции +. Почему она использует "кучу" не понятно.

 

Тоже самое с операцией " * ", остальные не проверял.

Если вместо with package в generic просто создать пакет Real_Arrays внутри пакета

Gmod, то всё работает нормально. Хотя это конечно не выход.

 

Когда выйду из отпуска, проверю отдельно, так как весь наш текущий проект сильно завязан на generic-и. Тогда может буду "рапорт" писать. Но Вы тоже пишите, т.к. каналы Pro и FSF совсем разные, как я понимаю.

 

Отправил описание проблемы на report@adacore.com

On Sun, 31 Jul 2011 23:28:21 +0400, you wrote:

 

Когда выйду из отпуска, проверю отдельно, так как весь наш текущий проект сильно завязан на generic-и. Тогда может буду "рапорт" писать. Но Вы тоже пишите, т.к. каналы Pro и FSF совсем разные, как я понимаю.

 

Отправил описание проблемы на report@...

 

Ошибка наличествует и в GNAT Pro 6.4.2 (20110614-45). Я отправил report (K907-017).

 

Скорее всего это не связано с собственно Ada.Numberics, а относится к определенным комбинациям подстановки generic-ов. Так что важно этот bag проанализировать и убить.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти