Сообщения об ошибках не помещенные в Bugzilla
-
Удаляя с помощью kfar каталог с большим количеством вложенных файлов, процессор нереально грузился. Решил посмотреть в cpu. Вот что увидил - загрузка процессора > 100%. Использовалась последняя ночная сборка.
- Attachments
-
-
cpu.png (40.97 KiB)Viewed 20679 times
-
Выявил подробности зверского бага, когда перекрывающие друг-друга окна приложений могут бесконечно перерисовываться отбирая почти все ресурсы ОС.
Проблема в вызове функции 67 в MainLoop (основной цикл) приложения. Если вызывается 1 раз для контроля ширины и высоты окна приложения, то проявляется баг. Если вызвать 2 раза: 1 для высоты и 1 для ширины соответсвенно (или наоборот), то бага нету.
Вот собственно примеры демонстрирующие этот баг: 1.asm без бага, 2.asm с багом.
Проблема в вызове функции 67 в MainLoop (основной цикл) приложения. Если вызывается 1 раз для контроля ширины и высоты окна приложения, то проявляется баг. Если вызвать 2 раза: 1 для высоты и 1 для ширины соответсвенно (или наоборот), то бага нету.
Вот собственно примеры демонстрирующие этот баг: 1.asm без бага, 2.asm с багом.
- Attachments
-
-
f67_bug.7z (654 Bytes)Downloaded 236 times
-
mcall 68,22
Можно создать только две именованные области. При попытке создания третьей области поток вываливается.
Каждая именованная область создавалась в уникальном приложении (адресные пространства не пресекаются, не поток), имена областей отличаются. Если завершать одно из двух приложений, то можно снова запустить второе, но запуск третьего опять приведет к падению. update 22.15 МСК
Ситуация еще хитрее, если области были просто запрошены, то запрос третьей приводит к вываливанию потока и всех дальнейших попыток получить новую именованную область. Однако если выделенную область какой-нибудь поток открыл на чтение-запись (при наличии разрешения на запись), то такая область возвращается ядру при закрытии всех использующих эту именнованную область процессов.
Программа демонстрирующая вылет на запросе третьей именнованной области в архиве. Запускаем последовательно 3 копии программы, на третьей наблюдаем вылет в BOARD и дальше вылеты, даже если закрыть две первые копии.
Можно создать только две именованные области. При попытке создания третьей области поток вываливается.
Каждая именованная область создавалась в уникальном приложении (адресные пространства не пресекаются, не поток), имена областей отличаются. Если завершать одно из двух приложений, то можно снова запустить второе, но запуск третьего опять приведет к падению. update 22.15 МСК
Ситуация еще хитрее, если области были просто запрошены, то запрос третьей приводит к вываливанию потока и всех дальнейших попыток получить новую именованную область. Однако если выделенную область какой-нибудь поток открыл на чтение-запись (при наличии разрешения на запись), то такая область возвращается ядру при закрытии всех использующих эту именнованную область процессов.
Программа демонстрирующая вылет на запросе третьей именнованной области в архиве. Запускаем последовательно 3 копии программы, на третьей наблюдаем вылет в BOARD и дальше вылеты, даже если закрыть две первые копии.
Mario
Исправил баг и сделал несколько маленьких поправок. Теперь функция честно возвращает eax=0 edx=E_NOMEM. В примере ошибка. Прежде чем работать с памятью надо настроить кучу приложения 68.11.
Исправил баг и сделал несколько маленьких поправок. Теперь функция честно возвращает eax=0 edx=E_NOMEM. В примере ошибка. Прежде чем работать с памятью надо настроить кучу приложения 68.11.
Serge
После твоих правок в эмуляторе qemu и на моей железяке размер heap постоянен и равен около 16Мб.
После твоих правок в эмуляторе qemu и на моей железяке размер heap постоянен и равен около 16Мб.
Serge
Да с 68.11 в примере я лопухнулся.
Однако даже используя 68.11 раньше я не мог больше двух областей открыть сразу. Пример я писал уже позже просто забыл вставить 68.11.
Большое спасибо теперь все работает.
Открыл 5 копий zSea в связке с 5 копий OpenDialog (именованная область используется для передачи данных между программ). Все 5 копий открыли выбранные файлы. Дальше не стал проверять.
Да с 68.11 в примере я лопухнулся.
Однако даже используя 68.11 раньше я не мог больше двух областей открыть сразу. Пример я писал уже позже просто забыл вставить 68.11.
Большое спасибо теперь все работает.
Открыл 5 копий zSea в связке с 5 копий OpenDialog (именованная область используется для передачи данных между программ). Все 5 копий открыли выбранные файлы. Дальше не стал проверять.
Я ошибся: в последней ночной сборке такое уже наблюдается SVN1194.Maxis wrote:Serge
После твоих правок в эмуляторе qemu и на моей железяке размер heap постоянен и равен около 16Мб.
В документации написано:
В реальности же расширения там нет (проверял отладчиком). Может стоит исправить документацию или исправить ядро?======================================================================
============= Функция 9 - информация о потоке выполнения. ============
======================================================================
* +10 = +0xA: 11 байт: имя процесса
(имя соответствующего исполняемого файла в формате 8+3)
Нашел баг в калькуляторе, в бинарном режиме вводятся только 29 разрядов вместо 32
0001 1111 1111 1111 1111 1111 1111 1111
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)
Если не секрет, как понимать в конфигураторе стека "статус сетевой карты"?
Да, и еще. Я понимаю, что железо очень специфическое, графика встроенная и память берется из оперативной, но при тестировании на ноутбуке Колибри сильно нагружала проц и тормозила. Кроме того, иногда при загрузке не инициализировались устройства ввода-вывода: один раз мышка, один - мышка вместе с клавиатурой. Причем система не висела, если верить часам =)
DHCP Client не захотел получить адрес и колибри в плане сети вела себя странно.
(адреса раздавал DI-624S)
Если не секрет, как понимать в конфигураторе стека "статус сетевой карты"?
Да, и еще. Я понимаю, что железо очень специфическое, графика встроенная и память берется из оперативной, но при тестировании на ноутбуке Колибри сильно нагружала проц и тормозила. Кроме того, иногда при загрузке не инициализировались устройства ввода-вывода: один раз мышка, один - мышка вместе с клавиатурой. Причем система не висела, если верить часам =)
Поможем Колибри-OS'у!
Не патчем, так хоть краш-тестом!
Не патчем, так хоть краш-тестом!
В свежей ночной сборке есть BUG. Не работает кнопка минимизаци, в основном на FASM'е. Правда если очень долго работать в системе, кнопка минимизации перестаёт работать под всеми программамими, и иногда появляется глюк ввиде ореола от кнопки. Проверял на реальной системе.
Я смотрю система с каждым днём работает всё хуже и хуже, раньше такого небыло. Я так понимаю это новая ветка развития ОСи? - down и ещё раз down.
Я смотрю система с каждым днём работает всё хуже и хуже, раньше такого небыло. Я так понимаю это новая ветка развития ОСи? - down и ещё раз down.
Rock_maniak_forever
Ответ напрашивается сам собой - отсутствие полнокровного тестирования при активной разработке как раз приводит к таким вещам.
Ответ напрашивается сам собой - отсутствие полнокровного тестирования при активной разработке как раз приводит к таким вещам.
Who is online
Users browsing this forum: No registered users and 1 guest