OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 28 Сентябрь, 2021 14:42

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 271 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10, 11, 12 ... 14  След.
Автор Сообщение
СообщениеДобавлено: Среда, 20 Май, 2020 06:57 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Это очень хитрая ошибка, два дня искал. Флюктуации миграции в сторону BlackBox/CPfront.
Связана с подсчётом количества методов, который в Ofront и в BlackBox устроен по-разному.
Под список методов выделялся массив меньшего размера, чем требовалось, что приводило к порче памяти.
Исправил.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 12 Июль, 2020 09:45 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Коллеги, у кого-нибудь здесь есть опыт низкоуровневого программирования под Linux, Windows? Такие дела. Недавно в voc/Ofront+ была найдена и исправлена ошибка в сборщике мусора. И, как оказалось, сборщик мусора вообще был незадействован. После фикса, который просто сводился к убиранию "творчества" Дэйва Брауна, я вернулся к тому же коду, что в оригинальном Ofront. И сборщик заработал, однако после пересборки самого себя транслятор стал в некоторые моменты трапиться. Отладка показала, что это происходит в момент взятия данных из стека. На стеке, как мы знаем, хранятся локальные переменные. И консервативный сборщик шпарит по ним, собирая указатели простым сравнением со списком уже выделенных указателей.

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


Вложения:
MarkStack.png
MarkStack.png [ 372.95 КБ | Просмотров: 2788 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 13 Июль, 2020 15:20 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 984
Откуда: Казань
На самом деле сложно понять, из-за чего именно трапится.
Есть два варианта:
- возможно, что срабатывает какой-то внутренний ASSERT в сборщике мусора;
- или система запрещает обращение по какому-то адресу.
Под стек на windows обычно выделяется что-то типа 10 Мб. Соответственно, обращаться к стеку можно по адресам от начального, то конечного. Соседние страницы памяти могут быть не выделены и при попытке к ним обратиться может возникать исключение.
Теоретически, возможна ситуация, что не ко всем страницам внутри определенного интервала можно обращаться, они могут быть выделены для других целей (антивирус, вирус, драйвер и т.д., может загружаться внутрь адресного пространства и занимать там какую-то область). По-хорошему, нужно учитывать такие моменты, что может быть не сплошной кусок памяти, а с разрывами (для стека это не очень актуально, а для выделения динамической памяти в куче это может быть актуально).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 13 Июль, 2020 16:43 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1346
Я бы сделал так:

1. Знать, где находится стек.

2. Знать, где находится куча.

3. В сборщике мусора не пытаться разыменовывать те "указатели", которые указывают ни на стек, ни на кучу. Тогда и исключений не будет. Исключения, мало того, что требуют обработчика, так ещё и их обработка занимает время.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 13 Июль, 2020 16:52 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1346
Хотя, поглядев на код... :roll:
Например, можно проверить версию о том, что логика сборщика неправильная и он пытается читать за пределами стека... И ещё неплохо бы понять, что именно делает GET


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 13 Июль, 2020 17:44 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Да, действительно. Сборщик пытался читать за пределами стека.

__GET это же SYSTEM.GET. Читает из памяти по указанному адресу в переменную.

Проблема со сборкой мусора исправлена. Надеюсь, теперь уже окончательно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 04 Август, 2020 02:53 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Дмитрий Викторович, я сейчас вот накатил Ваш патч и столкнулся с такой проблемой:

Код:
MODULE OPP;

   TYPE
      Elem = POINTER TO RECORD
         next: Elem;
         pos: INTEGER;
      END;

      CaseTable = ARRAY 1 OF
         RECORD
            low, high: INTEGER
         END;

END OPP.

Раньше сгенерированный для этого модуля код выглядел так:
Код:
#ifndef OPP__h
#define OPP__h

#include "SYSTEM.h"

import void *OPP__init (void);

#endif
А после патча выглядит так:
Код:
#ifndef OPP__h
#define OPP__h

#include "SYSTEM.h"

typedef
   struct OPP__1 OPP_CaseTable[1];

typedef
   struct OPP_Elem__rec *OPP_Elem;

typedef
   struct OPP_Elem__rec {
      INTEGER _prvt0;
      char _prvt1[4];
   } OPP_Elem__rec;

import void *OPP__init (void);

#endif

И такой хедер не хочет включаться, т.к. в нём не определено OPP__1.

Ваша правка в DevCPC.DefineType. Было:
Код:
      IF (OPM.currFile = OPM.BodyFile) ...
Стало:
Код:
      IF (OPM.currFile IN {OPM.BodyFile, OPM.HeaderFile}) ...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 04 Август, 2020 20:22 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Тут наложились мои эксперименты с динамической загрузкой (пока еще не доделанной) и привязкой загружаемых модулей. Даже, если тип неэкспортирован, тэг типа нужен.

На всякий случай прогнал свои 479 тестов с Вашей правкой и без - все совпадает для статически собираемых модулей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 05 Август, 2020 04:08 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Да, CPfront генерирует код с этой правкой несколько другой, нежели Ofront+
В том плане, что для вышеприведённого модуля описание типа OPP__1 в хедере генерится.

Как успехи с динамической загрузкой? Вы ведь через стандартный механизм ОС .so/.dll делаете?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 05 Август, 2020 10:48 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Oleg N. Cher писал(а):
Как успехи с динамической загрузкой? Вы ведь через стандартный механизм ОС .so/.dll делаете?

Реализована для бэкенда LLVM в первой версии. Для CPfront-бэкенда Omf пока в работе. Грузятся объектники в coff и elf формате https://forum.oberoncore.ru/viewtopic.php?f=157&t=6423&start=20#p112043. Выставлена версия 0.95.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Август, 2020 17:54 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Это я видел, я же читаю форум. Не, именно для CPfront интересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Август, 2020 09:07 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 74
Откуда: Equestria
Я делал динамическую загрузку модулей через dlopen. Работает, но допилить cpfront надо. (секция CLOSE не регистрируется в дескрипторе модуля).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Декабрь, 2020 02:38 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Немного забыл про этот форум. Новостей много, но основные:

    1. Наконец-то сделан корректный экспорт константных массивов

    2. Артур Ефимов заявил о переводе Free Oberon на ядро Ofront+

    3. Ofront+ показывает себя стабильным продуктом. В последнее время совсем мало правок. Конечно в планах ещё много всего, но пользовать уже очень можно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Декабрь, 2020 09:05 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Oleg N. Cher писал(а):
Наконец-то сделан корректный экспорт константных массивов

А Вы не думали/пробовали в Ofront+ делать константные структуры произвольного содержания?

Поясню. Если мы посмотрим на С-код, сгенеренный Ofront'ами, то там огромное число таких структур, например
Код:
static ADDRESS Math__exp[] = {
   1,
   0xde082fa8, (ADDRESS)Math_IntPower, 1<<8 | 0x44, 0,
};
static char Math__names[] = {
   0,
   'I','n','t','P','o','w','e','r',0,
};
static ADDRESS Math__ptrs[] = {
   0
};
struct SYSTEM_MODDESC Math__desc = {
   0, 13, 0, /* next, opts, refcnt */
   {2019, 10, 8, 13, 43, 18}, /* compTime */
   {0, 0, 0, 0, 0, 0}, /* loadTime */
   Math__body,
   0,
   1, /* nofimps */
   0, /* nofptrs */
   0, 0, 0, 0, 0, 0, 0, 0, /* csize..varBase */
   Math__names,
   Math__ptrs,
   Math__imp,
   (SYSTEM_DIRECTORY*)Math__exp,
   "Math"
};

И, что важно, эти структуры ложатся при загрузке в секцию данных, а не в секцию кода.
А в Обероне такого нет. И что, получается, мы не сможем такое сделать на Обероне?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Декабрь, 2020 15:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
Дмитрий Дагаев писал(а):
А Вы не думали/пробовали в Ofront+ делать константные структуры произвольного содержания?
Такие запросы от юзеров были. Но решили не усложнять язык.
Если доберётесь сделать, будет интересно посмотреть синтаксис.

Дмитрий Дагаев писал(а):
И, что важно, эти структуры ложатся при загрузке в секцию данных, а не в секцию кода.
А в Обероне такого нет. И что, получается, мы не сможем такое сделать на Обероне?
Ну да, получается, не сможем. Разве что в Ofront'е через уровень Си.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Апрель, 2021 04:17 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Вот такой модуль в ББ компилируется, а в ofront+ - нет:

Код:
MODULE Ex;

PROCEDURE Prc (p1:PROCEDURE(p:PROCEDURE); p2:PROCEDURE);
  BEGIN
    p1(p2)
  END Prc;

END Ex.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Май, 2021 04:48 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 233
Откуда: г. Рига, Латвийская ССР
Дмитрий Дагаев писал(а):
...И, что важно, эти структуры ложатся при загрузке в секцию данных, а не в секцию кода.
А в Обероне такого нет. И что, получается, мы не сможем такое сделать на Обероне?

А что если компилятор, когда видит в начале секции инициализации модуля (главный BEGIN) множество присваиваний вида "переменная := константа", загонял бы это всё (не во время выполнения, а в момент компиляции) в сегмент данных? Какие здесь могут быть проблемы? Такие данные ведь можно потом изменять?

Код:
MODULE A;
VAR m: ARRAY 4 OF BYTE;
BEGIN m[0] := 8; m[0] := 2; m[0] := 5; m[0] := 7
END A.

превращается в (условно):
Код:
.DATA   
m DB 8, 2, 5, 7


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Май, 2021 09:50 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Получается неясная конструкция. А если добавить код, как Вы будете различать?
Код:
VAR m: ARRAY 4 OF BYTE; pm: POINTER TO ARRAY OF BYTE;
BEGIN NEW(pm, 4); m[0] := 8; pm[0] := 9; m[1] := 2+pm[0]; pm[1] := 8; m[2] := 5+pm[1]; m[3] := 7


Речь шла о возможной инициализации в определениях переменных, скажем так
Код:
VAR mArr: ARRAY 4 OF BYTE = {8, 2, 5, 7};


Это пока не предложение, а мысли вслух в контексте поднятых Oleg N. Cher проблем. Чтобы сделать Ofront на Обероне.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 03 Май, 2021 13:19 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1314
Откуда: Киев
kekc_leader писал(а):
А что если компилятор, когда видит в начале секции инициализации модуля (главный BEGIN) множество присваиваний вида "переменная := константа", загонял бы это всё (не во время выполнения, а в момент компиляции) в сегмент данных? Какие здесь могут быть проблемы? Такие данные ведь можно потом изменять?
Хороший подход, но возможные проблемы, помимо дополнительного усложнения компилятора, Вы и сами показали в своём будто бы намеренно ошибочном примере.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Май, 2021 12:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 461
Откуда: Украина, Днепропетровская обл.
GameHunter писал(а):
Вот такой модуль в ББ компилируется, а в ofront+ - нет
Эта проблема тянется из оригинального Ofront. Исправлено.

Дмитрий Дагаев писал(а):
Это пока не предложение, а мысли вслух в контексте поднятых Oleg N. Cher проблем. Чтобы сделать Ofront на Обероне.
Вот эту сентенцию я вообще не понял. Ofront и так на Обероне. Там есть только один маленький сишный SYSTEM.c, реализующий системные возможности, ну как и в CPfront.

Господа, в контексте вашего обсуждения.

Реализовывать превращение присваиваний в константные данные не планирую. В Ofront+ и так есть то, чего нет во многих других реализациях — константные массивы.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 271 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10, 11, 12 ... 14  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2021, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB