powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Помогите, пожалуйста, с malloc в shared library, gcc, linux
25 сообщений из 58, страница 2 из 3
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279208
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012However, one counter-example occurs on PPC64 kernels whereby a kernel using 64K as a base page size
still use 4K pages for the MMU on older processors.
To, this patch reports "MMUPageSize" as the page size by the MMU.
Хм.
Вопрос, конечно, интересный, но 64К в 1000 раз меньше 65404 kB. Но подумать надо.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279209
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_fВопрос, конечно, интересный, но 64К в 1000 раз меньше 65404 kB. Но подумать надо.Ну загляните в исходники Linux.
Здается мне в данном случае речь идет о 65404 bytes /то бишь 64К/.
Хотя не уверен, что прав ...
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279210
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyЕсли .SO собрана со статическим рантаймом, то у нее будет своя куча. Причем не только куча, но и все остальные структуры рантайма.

Кстати, вполне вероятно, что память занимает вовсе не куча.

Чтобы увидеть выделения памяти запустите программу в strace. Там среди прочих mmap будет и создание кучи.

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

При этом я гарантирую, что приведённый псевдокод есть сокращение реального, просто вместо цикла (зацикленного навечно здесь) идет реальный цикл с кучей строк.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279212
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот вам отличный рессурс https://github.com/krf/dotfiles/ My dotfiles http://kfunk.org.

Посмотрите на содержимое поддиректории bin.
В частности на https://github.com/krf/dotfiles/blob/master/bin/smem.pl
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279213
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyЕсли .SO собрана со статическим рантаймом, то у нее будет своя куча. Причем не только куча, но и все остальные структуры рантайма.

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

И, вероятно, Dimitry Sibiryakov, в чём то прав и правильно ткнул меня носом.
Dimitry Sibiryakov, приношу свои извинения, я был не прав, вспылив :)

Прошу прощения, у меня уже полночь, завтра продолжу.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279214
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012,

Спасибо, посмотрю.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279215
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ой не пойму я чего ты к этим мегабайтам прицепился... Они же виртуальные. Реальное ОЗУ
выделяется по 4к гораздо позже.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279224
Вася Уткин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovНо, как бы то ни было, при создании кучи идёт выделение исключительно виртуальной памяти и
никакой резервации физической. О чём и говорят цифры в стартовом посте.

Собственно вот ответ.

Andrej_f[/src]
var.1 top:
Код: plaintext
1.
2.
3.
  PID USER        PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
26820 looser      20   0   74340   3408   2536 S   0,0  0,0   0:00.01 test
26821 looser      20   0   74340   3408   2536 S   0,0  0,0   0:00.01 test


var.2 top:
Код: plaintext
1.
2.
3.
  PID USER        PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
26596 looser      20   0  139876   3452   2580 S   0,0  0,0   0:00.04 test
26597 looser      20   0  139876   3452   2580 S   0,0  0,0   0:00.04 test


VIRT 139876 это не выделенная память, а выделенная непрерывная область адресов VMA виртуальной памяти, которая пока uncommited. После первого обращения к ней, например, инициализации будет происходить постраничный commit с созданием PTE для каждой страницы - т.е. выделением физической памяти. Видимо рантайм используя mmap() заранее выделил непрерывную область адресов, чтобы если в неё накомитишь мелких объектов, а потом удалишь их, чтобы можно было её повторно использовать для больших объектов/массивов.
Обычно она выделяется функциями VirtualAllocEx() в Windows, или mmap() в POSIX (Linux, ...).
Её можно выделять хоть в миллион раз больше реальной физической памяти.

Any way to reserve but not commit memory in linux?

https://www.opennet.ru/base/sys/procps_info.txt.html VIRT -- общий объем виртуальной памяти, используемой процессом,
включает в себя: область кода (CODE), данные (DATA), разделяемые
библиотеки (SHARED) и страницы, перемещенные в swap-область
памяти. Если приложение потребовало от ядра выделить ему 100Мб
памяти, а использует всего 5 Мб, данный столбец всё равно будет
показывать цифру 100.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279232
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_f,
суть проблемы - нервная диагностика.

хочешь верной - запусти под valgrind.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279339
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вася Уткин,

По вашей ссылке:авторThe Linux equivalent of VirtualAlloc() is mmap(), which provides the same behaviours. However as a commenter points out, reservation of contiguous memory is the behaviour of calls to malloc() as long as the memory is not initialized (such as by calloc() , or user code).Кроме того, инфа на "стаковерфлов" не от разработчиков linux/gnu, полностью ей доверять нельзя.

Своими же глазами я вижу, что каждый запущенный поток, вызвавший malloc/calloc, получает отдельные 65 мегабайт памяти. У меня пока висит чуть более 10 потоков, занимающих вместе полтора гига, пусть даже и VIRT, пусть она и не commited, а только reserved, но где написано, что зарезервированная память отдается другим потокам/процессам/системе при общей нехватке?

Мне нужны сотни потоков, не жрущие каждый по ненужным им десяткам мегабайт.
Пока что я выяснил, что функции, неявно использующие malloc при вызове из потока вызывают "утечку" памяти. Меняю их.
Да, память должна возвращаться системе после уничтожения потока, но нерационально выделять/резервировать так много.

MasterZivхочешь верной - запусти под valgrindЗапускал. Утечек он не находит (кроме pthread_create в определенных случаях, но это фича valgrind). Но он и не считает утечкой то, что считаю я, с его точки зрения такой расход памяти нормален (технически это не утечка), с моей нет.

Буду отписываться по мере продвижения.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279341
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_fгде написано, что зарезервированная память отдается другим потокам/процессам/системе при
общей нехватке?

Нигде. Потому что она не отдаётся. У каждого 32-х разрядного процесса свои собственные
четыре гигабайта адресного пространства. Процесс чисто технически не может поделиться ими
с кем-то ещё.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279344
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

Хорошо, это я уже понял, непонятно другое - в мануалах пишут о том, что потоки в линуксе используют общее адресное пространство основного процесса.
Я же вижу, что каждый отдельный поток получает собственную кучу как только запрашивает кусочек памяти.
И да, технически эта новая куча становится частью общего пространства, только вот используется только этим потоком, заставляя каждый новый поток получать десятки мегабайт в ответ на запрос десятка байт.
Или я чего то не понимаю.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279345
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_fзаставляя каждый новый поток получать десятки мегабайт в ответ на запрос десятка байт.
Или я чего то не понимаю.
Ты не понимаешь, что память выделяется страницами по 4к. А твоими мегабайтами выделяется
адресное пространство. Это две разные вещи.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279350
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей /без обид/.
Расскажу вам об том как нахожу ответ на свои вопроса.
В редких случаях /близко к нулю/ у кого-то прошу совета.
Почему?
Иначе мысль начинает думать не как решить вопрос, а у кого найти ответ.
И времени при этом тратится больше и знаний от этого "не приходят".

Ни к тому это вам написал, чтобы вы в форуме не просили помощи ...
Ваше право выбрать более приемлемый для вас путь.

PS: Организация памяти процесса https://habrahabr.ru/company/smart_soft/blog/185226/
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279354
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012PS: Организация памяти процесса https://habrahabr.ru/company/smart_soft/blog/185226/ http://duartes.org/gustavo/blog/category/linux/
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279359
Вася Уткин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Andrej_fВася Уткин,

По вашей ссылке:авторThe Linux equivalent of VirtualAlloc() is mmap(), which provides the same behaviours. However as a commenter points out, reservation of contiguous memory is the behaviour of calls to malloc() as long as the memory is not initialized (such as by calloc() , or user code).Кроме того, инфа на "стаковерфлов" не от разработчиков linux/gnu , полностью ей доверять нельзя.

Своими же глазами я вижу, что каждый запущенный поток, вызвавший malloc/calloc, получает отдельные 65 мегабайт памяти. У меня пока висит чуть более 10 потоков, занимающих вместе полтора гига, пусть даже и VIRT, пусть она и не commited, а только reserved , но где написано, что зарезервированная память отдается другим потокам/процессам/системе при общей нехватке?

Людям с репутацией 200 000 на стаковерфлов доверять нельзя, а мне можно.
А если серьёзно, мои программы и по 1 Петабайту VIRT памяти имеют на железе с 0.25 терабайта RAM, ничего не свопят и работают так быстро, как ни у кого, и чего?
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279360
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И снова о памяти в Linux - /proc/meminfo http://markelov.blogspot.com/2009/01/linux-procmeminfo.html
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279362
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вася УткинА если серьёзно, мои программы и по 1 Петабайту VIRT памяти имеют на железе с 0.25 терабайта RAM, ничего не свопят и работают так быстро, как ни у кого, и чего?Помнится в 2000-х у меня на DX-33 c 2MB RAM /без hdd и дисководов/ WIN-98 работала.
Мини ядро было собрано на базе Slacware.
И сейчас уж не помню, как Windows 98 грузил ... /но стартовала и работала/.
Вот это действительно интересно.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279381
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_fУ меня пока висит чуть более 10 потоков, занимающих вместе полтора гига, пусть даже и VIRT, пусть она и не commited, а только reserved, но где написано, что зарезервированная память отдается другим потокам/процессам/системе при общей нехватке?
Не смущает что есть два разных термина reserved и commited ? Если бы память сразу отдавалась, то зачем два разных слова для одного и того же действия?

reserved просто сообщает ОС что конкретное виртуальное адресное пространство может быть использовано программой. В случае обращения программой в это место ОС подставит реальную память т.е. commited, причем не одним большим куском, а страницами по 4 Кб, т.е. например создашь массив на 10 Кб, займешь всего 12 Кб реальной.

Почитай что такое виртуальная память и как она устроена.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279455
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тут много всяких нелинейностей. Поскольку автор не юзает выделенную память
то по всей видимости работает механизм optimistic memory allocation.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279465
д0k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Владимир2012Вообщем вот ответ:

However, one counter-example occurs on PPC64 kernels whereby a kernel using 64K as a base page size
still use 4K pages for the MMU on older processors.
To, this patch reports "MMUPageSize" as the page size by the MMU.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
cat /proc/26596/smaps:
7faf58021000-7faf5c000000 ---p 00000000 00:00 0
Size:              65404 kB
Rss:                   0 kB                                amount of the mapping that is currently resident in RAM ("Rss")
Pss:                   0 kB                                the process proportional share of this mapping ("Pss")
Shared_Clean:          0 kB                                number of clean and dirty private pages in the mapping
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB                                amount of memory currently marked as referenced or accessed
Anonymous:             0 kB                                amount of memory that does not belong to any file
AnonHugePages:         0 kB
Swap:                  0 kB
KernelPageSize:        4 kB                                entry is the page size used by the kernel to back a VMA. This matches the size used by the MMU in the majority of cases.
MMUPageSize:           4 kB
Locked:                0 kB




прошу прощения ,
но это не ответ, ибо у
авторuname -a
Linux ws-dbn 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux


принципиально другая аппаратная архитектура ...
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39279490
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
д0kпрошу прощения ,
но это не ответ, ибо у
авторuname -a
Linux ws-dbn 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
принципиально другая аппаратная архитектура ...Let it be.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39287752
Andrej_f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Короче, я добился того, чего хотел.
Я не буду спорить ни с кем по поводу виртуальности адресного пространства или фрагментации памяти - для этого я слишком туп.
Для себя я добился снижения показателя VIRT в примерно 10 раз и вообще его бесконтрольного роста.
Для тех, кому интересно, ниже результаты моих изысканий. Остальные могут пинаться, сколько влезет.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
1.
В потоках нельзя использовать функции, явно или не явно использующие выделение памяти
(см. таблицу)
----------------+-------------+-----------
Функция	        |  Замена     | 	Примечание
----------------+-------------+-----------
malloc,calloc   |  alloca     | выделение памяти в стеке, нельзя использовать free к такому объекту
dlopen          |             | загружать библиотеки вне потока, передавая в поток результат
fopen	        | open        | вместо FILE* будет int, вместо fwrite - write, и т.д.
pthread_create	|             | не вызывать из потока
pthread_exit  	| return      | http://stackoverflow.com/questions/3844678/pthread-exit-vs-return
mktime,localtime| timegm      | http://man7.org/linux/man-pages/man3/timegm.3.html (nonstandard GNU extensions)
Примечание:
timegm (nonstandard GNU extensions)- легко заменить на самописную, гуглится несколько вариантов

2.
В потоках нельзя использовать неинициализированные переменные вне функций:
	такие переменные являются глобальными и при первой инипциализации под них выделяется память
	в общем адресном пространстве программы, но блоками по несколько мегобайт:
	static __thread int a = 0;        // можно
	static __thread char *b = NULL;  // нельзя
	static __thread char c[512];     // нельзя

3.
Заканчивать поток функцией pthread_exit(void *retval) не желательно, так как она неявно использует malloc
(http://stackoverflow.com/questions/3844678/pthread-exit-vs-return)
лучше использовать return NULL;

4.
Если в потоке используются shared library, то даже изначальная инициализация внеблоковых static __thread
переменных не спасает от выделения памяти под них в момент первой модификации/обращения.
Решение:
Внеблоковые переменные надо убирать в функции и делать их static и вообще избегать использования
глобальных переменных в shared library.

Попытка изменения размера стека привела к следующему:
да, взятый прямо из man код примера установки размера стека для потока
(man pthread_create (http://man7.org/linux/man-pages/man3/pthread_create.3.html))
работает очень хорошо, но при этом выход из потока, не важно через pthread_exit или 
return не уничтожает стек автоматически, его теперь надо уничтожать вручную с помощью free.
Это означает, что detached потоки будут отжтрать память не возвращая её системе.
Передать указатель на стек в такой поток можно, но попытка применить к нему free
из этого потока вызывает крах системы.
Т.е. потоки с регулирыемым стеком не могут быть detached.
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39287800
Фотография Новый Год
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_fКороче, я добился того, чего хотел.
Я не буду спорить ни с кем по поводу виртуальности адресного пространства или фрагментации памяти - для этого я слишком туп.
Для себя я добился снижения показателя VIRT в примерно 10 раз и вообще его бесконтрольного роста.
Для тех, кому интересно, ниже результаты моих изысканий. Остальные могут пинаться, сколько влезет.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
1.
В потоках нельзя использовать функции, явно или не явно использующие выделение памяти
(см. таблицу)
----------------+-------------+-----------
Функция	        |  Замена     | 	Примечание
----------------+-------------+-----------
malloc,calloc   |  alloca     | выделение памяти в стеке, нельзя использовать free к такому объекту
dlopen          |             | загружать библиотеки вне потока, передавая в поток результат
fopen	        | open        | вместо FILE* будет int, вместо fwrite - write, и т.д.
pthread_create	|             | не вызывать из потока
pthread_exit  	| return      | http://stackoverflow.com/questions/3844678/pthread-exit-vs-return
mktime,localtime| timegm      | http://man7.org/linux/man-pages/man3/timegm.3.html (nonstandard GNU extensions)
Примечание:
timegm (nonstandard GNU extensions)- легко заменить на самописную, гуглится несколько вариантов

2.
В потоках нельзя использовать неинициализированные переменные вне функций:
	такие переменные являются глобальными и при первой инипциализации под них выделяется память
	в общем адресном пространстве программы, но блоками по несколько мегобайт:
	static __thread int a = 0;        // можно
	static __thread char *b = NULL;  // нельзя
	static __thread char c[512];     // нельзя

3.
Заканчивать поток функцией pthread_exit(void *retval) не желательно, так как она неявно использует malloc
(http://stackoverflow.com/questions/3844678/pthread-exit-vs-return)
лучше использовать return NULL;

4.
Если в потоке используются shared library, то даже изначальная инициализация внеблоковых static __thread
переменных не спасает от выделения памяти под них в момент первой модификации/обращения.
Решение:
Внеблоковые переменные надо убирать в функции и делать их static и вообще избегать использования
глобальных переменных в shared library.

Попытка изменения размера стека привела к следующему:
да, взятый прямо из man код примера установки размера стека для потока
(man pthread_create (http://man7.org/linux/man-pages/man3/pthread_create.3.html))
работает очень хорошо, но при этом выход из потока, не важно через pthread_exit или 
return не уничтожает стек автоматически, его теперь надо уничтожать вручную с помощью free.
Это означает, что detached потоки будут отжтрать память не возвращая её системе.
Передать указатель на стек в такой поток можно, но попытка применить к нему free
из этого потока вызывает крах системы.
Т.е. потоки с регулирыемым стеком не могут быть detached.



мне кажется, что многое из этого не правильно
...
Рейтинг: 0 / 0
Помогите, пожалуйста, с malloc в shared library, gcc, linux
    #39287801
Фотография Новый Год
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrej_f
Код: plaintext
1.
2.
3.
4.
----------------+-------------+-----------
Функция	        |  Замена     | 	Примечание
----------------+-------------+-----------
malloc,calloc   |  alloca     | выделение памяти в стеке, нельзя использовать free к такому объекту



у тебя вот тут то же самое, что alloca()

void *db_thread(void *)
{
char c[100];
sleep(9);
return NULL;
}

попробуй подставить вместо 100 переменную, очень удивишься
gcc позволяет создавать массивы переменной длины, если явно их не запретить
...
Рейтинг: 0 / 0
25 сообщений из 58, страница 2 из 3
Форумы / C++ [игнор отключен] [закрыт для гостей] / Помогите, пожалуйста, с malloc в shared library, gcc, linux
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]