OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 28 Сентябрь, 2020 04:51

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




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

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


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

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

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


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

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


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

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

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

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

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

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


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

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


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

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

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

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


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

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

Код:
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
Сообщения: 483
Откуда: Москва
Тут наложились мои эксперименты с динамической загрузкой (пока еще не доделанной) и привязкой загружаемых модулей. Даже, если тип неэкспортирован, тэг типа нужен.

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


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

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

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


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 483
Откуда: Москва
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
Сообщения: 407
Откуда: Украина, Днепропетровская обл.
Это я видел, я же читаю форум. Не, именно для CPfront интересно.


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

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


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

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


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

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


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

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