Board.KolibriOS.org

Удаляя с помощью kfar каталог с большим количеством вложенных файлов, процессор нереально грузился. Решил посмотреть в cpu. Вот что увидил - загрузка процессора > 100%. Использовалась последняя ночная сборка.

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

Проблема в вызове функции 67 в MainLoop (основной цикл) приложения. Если вызывается 1 раз для контроля ширины и высоты окна приложения, то проявляется баг. Если вызвать 2 раза: 1 для высоты и 1 для ширины соответсвенно (или наоборот), то бага нету.

Вот собственно примеры демонстрирующие этот баг: 1.asm без бага, 2.asm с багом.

mcall 68,22
Можно создать только две именованные области. При попытке создания третьей области поток вываливается.
Каждая именованная область создавалась в уникальном приложении (адресные пространства не пресекаются, не поток), имена областей отличаются. Если завершать одно из двух приложений, то можно снова запустить второе, но запуск третьего опять приведет к падению. update 22.15 МСК
Ситуация еще хитрее, если области были просто запрошены, то запрос третьей приводит к вываливанию потока и всех дальнейших попыток получить новую именованную область. Однако если выделенную область какой-нибудь поток открыл на чтение-запись (при наличии разрешения на запись), то такая область возвращается ядру при закрытии всех использующих эту именнованную область процессов.

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

Mario

Исправил баг и сделал несколько маленьких поправок. Теперь функция честно возвращает eax=0 edx=E_NOMEM. В примере ошибка. Прежде чем работать с памятью надо настроить кучу приложения 68.11.

Serge

После твоих правок в эмуляторе qemu и на моей железяке размер heap постоянен и равен около 16Мб.

Serge
Да с 68.11 в примере я лопухнулся.
Однако даже используя 68.11 раньше я не мог больше двух областей открыть сразу. Пример я писал уже позже просто забыл вставить 68.11.

Большое спасибо теперь все работает.
Открыл 5 копий zSea в связке с 5 копий OpenDialog (именованная область используется для передачи данных между программ). Все 5 копий открыли выбранные файлы. Дальше не стал проверять.

Maxis wrote:Serge

После твоих правок в эмуляторе qemu и на моей железяке размер heap постоянен и равен около 16Мб.

Я ошибся: в последней ночной сборке такое уже наблюдается SVN1194.

В документации написано:

======================================================================
============= Функция 9 - информация о потоке выполнения. ============
======================================================================
* +10 = +0xA: 11 байт: имя процесса
(имя соответствующего исполняемого файла в формате 8+3)

В реальности же расширения там нет (проверял отладчиком). Может стоит исправить документацию или исправить ядро?

Нашел баг в калькуляторе, в бинарном режиме вводятся только 29 разрядов вместо 32
0001 1111 1111 1111 1111 1111 1111 1111

Это скорее не баг, а костыль, потому как 32 единицы в десятичной системе равны 4 294 967 295 и значения, которые не могут быть обработаны, нужно как-то отсеивать, поэтому где-то стоит ограничение на ввод определенного числа разрядов. Возможно, сделано это кривовато на скорую руку, типа пока и так сойдет

косилка в новом дистрибутиве отказывает вверх поворачивать

Spoiler:

MTDBG под эмулятором (KlbrInWin) сообщил: "ERROR: cannot read process memory!!!". Ранее не замечалось.

Ноутбук fujitsu-siemens, сетевая карта Realtek 8139/810x
DHCP Client не захотел получить адрес и колибри в плане сети вела себя странно.
(адреса раздавал DI-624S)

Если не секрет, как понимать в конфигураторе стека "статус сетевой карты"?

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

В свежей ночной сборке есть BUG. Не работает кнопка минимизаци, в основном на FASM'е. Правда если очень долго работать в системе, кнопка минимизации перестаёт работать под всеми программамими, и иногда появляется глюк ввиде ореола от кнопки. Проверял на реальной системе.

Я смотрю система с каждым днём работает всё хуже и хуже, раньше такого небыло. Я так понимаю это новая ветка развития ОСи? - down и ещё раз down.

Rock_maniak_forever
Ответ напрашивается сам собой - отсутствие полнокровного тестирования при активной разработке как раз приводит к таким вещам.