freepascal.ru

Код: Выделить всё

          then with Mother^.Display.WindowRect do try
addlog('>>-------------');
addlog(' %0',[300 / 500]);
addlog(' %0', [RectToStr(Mother^.Display.WindowRect)]);
addlog(' %0, %1', [width, height]);
addlog(' %0', [RectToStr(Mother^.Display.ScreenRect)]);
addlog(' %0, %1', [Mother^.Display.ScreenRect.width, Mother^.Display.ScreenRect.height]);
addlog(' %0',[width / Mother^.Display.ScreenRect.Width]);
addlog(floattostr(1.0 * width / 1.0 * Mother^.Display.ScreenRect.Width));
            Config.Str['video','window_width']:= floattostr(1.0 * width / Mother^.Display.ScreenRect.Width);
//            Config.Float['video', 'window_height']:= height / Mother^.Display.ScreenRect.height;
//            Config.Float['video', 'window_left']:= (left - Mother^.Display.ScreenRect.left) / Mother^.Display.ScreenRect.width;
//            Config.Float['video', 'window_top']:= (top - Mother^.Display.ScreenRect.top) / Mother^.Display.ScreenRect.height;
addlog('<<');
          except

даёт

Код: Выделить всё

[frame #2, 19:03:38.174, Fri, 21.04.2017]
>>-------------
0.6
1152x648(556,405)
1152, 648
1920x1080(0,0)
1920, 1080
<----=* ERROR! ---- (look below for details) *=---->
<----=* ERROR! ---- (look below for details) *=---->
There were unprocessed error messages left:
!!..
Program crashed with an uncaught exception.
EAccessViolation: Access violation
  :773 in chentrah-armv7l
:
  framework_basic.pp:637 (tbasicframework.checkwindowsize)  in chentrah-armv7l
Call stack:
  framework_basic.pp:590 (tbasicframework.checkwindowsize)  in chentrah-armv7l

Что это было, Пух?

Это нормально...
Видимо Mother^.Display.ScreenRect.Width указывает хрен знает на что..

Добавлено спустя 3 минуты 3 секунды:
Такое бывает если у вас течет память.

Автором этого сообщения является olegy123, находящийся в вашем чёрном списке.

Кто-нибудь, НЕ являющийся резидентным троллем, знает ответ? Anybody? みんな？
А-у...

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

Автором этого сообщения является olegy123, находящийся в вашем чёрном списке.

Bump.
Прошу прощения за флуд.

Вот без понятия, что там происходит. Но:
1) самое первое "проверочное" деление на самом деле не выполняется, т.к. константное выражение вычисляется компилятором.
2) На ARM ошибки операций с плавающей запятой могут не вызывать исключений. А могут и вызывать, в зависимости от реализации процессора.
3) RTL устроена по принципу "в любой непонятной ситуации говори, что это AV", поэтому нужно брать отладчик и смотреть, что происходит на уровне ассемблера.

"проверочное" деление на самом деле не выполняется

Аз есмь дятел

ошибки операций с плавающей запятой могут не вызывать исключений. А могут и вызывать

Проблема в том что выше я вывожу оба и делитель и делимое, это longint'ы и делитель = 1920.
Т.е. делением на ноль это *не* может быть.

Единственное, что приходит на ум - GLES драйвер видеоядра при инициализации вздрючил флаги исключений fpu (или их армовского аналога).
Я даже пытался курить исходники SafeLoadLibrary(), но там только для интела

RTL устроена по принципу "в любой непонятной ситуации говори, что это AV",

Ага. Интересно, не знал.

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

[тяжкий вздохЪ]

Добавлено спустя 12 минут 43 секунды:
P.S. Не-а. Это генератор кода в компиляторе каким-то образом обосрался.

Код: Выделить всё

var gvl1, gvl2: longint;
...
gvl1:= width;
gvl2:= Mother^.Display.ScreenRect.Width;
addlog(' %0',[gvl1 / gvl2]); //всё пучком
addlog(' %0',[width / Mother^.Display.ScreenRect.Width]); //бомбит

Добавлено спустя 32 минуты 1 секунду:
..интересно, добавил
addlog(' %0 %1',[@width, @Mother^.Display.ScreenRect.Width]);
- получил 76B952D6h 76B952B6h, т.е. адреса НЕ выровнены.

Откуда: эти сраные библиотеки перекинули какой-то флажок бомбить на невыровненных флоатах.

Модифицировал хидер, вставил {$ifdef cpuarm}{$packrecords 4}{$endif}, заменил все packed record на {$ifndef cpuarm}packed{$endif} record - и всё пошло

Код: Выделить всё

>>-------------
0.6
1152x648(556,405)
1152, 648
1920x1080(0,0)
1920, 1080
0.6
76B6E2D8h 76B6E2B8h
0.6
2211840
<<

при

Код: Выделить всё

          then with Mother^.Display.WindowRect do try
addlog('>>-------------');
gvl1:= 300; gvl2:= 500;
addlog(' %0',[gvl1 / gvl2]);
addlog(' %0', [RectToStr(Mother^.Display.WindowRect)]);
addlog(' %0, %1', [width, height]);
addlog(' %0', [RectToStr(Mother^.Display.ScreenRect)]);
addlog(' %0, %1', [Mother^.Display.ScreenRect.width, Mother^.Display.ScreenRect.height]);
gvl1:= width;
gvl2:= Mother^.Display.ScreenRect.Width;
addlog(' %0',[gvl1 / gvl2]);
addlog(' %0 %1',[@width, @Mother^.Display.ScreenRect.Width]);
addlog(' %0',[width / Mother^.Display.ScreenRect.Width]);
addlog(floattostr(1.0 * width / 1.0 * Mother^.Display.ScreenRect.Width));
            Config.Str['video','window_width']:= floattostr(1.0 * width / Mother^.Display.ScreenRect.Width);
//            Config.Float['video', 'window_height']:= height / Mother^.Display.ScreenRect.height;
//            Config.Float['video', 'window_left']:= (left - Mother^.Display.ScreenRect.left) / Mother^.Display.ScreenRect.width;
//            Config.Float['video', 'window_top']:= (top - Mother^.Display.ScreenRect.top) / Mother^.Display.ScreenRect.height;
addlog('<<');
          except

Вот же, мать же его же, же, а?

Хм... так до загрузки GLES операции с плавающей запятой на невыровненных данных не бомбили или просто не выполнялись?
В моем представлении, выравнивание на ARM - это такая аксиома, что мысль о упакованной структуре не то чтобы в голову не пришла, а даже мимо не пролетела.

Packed это оче плохо, если не знаешь, что делаешь! Даже на x86, не выплёвывающем ошибки выравнивания наружу, например, interlocked-операции с невыровненными значениями тихо выполнятся не атомарно.

Но странно, что это произошло при http://www.freepascal.org/docs-html/ref/refse82.html:
>the compiler assumes that access to all fields/elements of packed data structures is unaligned.
В таком случае похоже на баг.

не бомбили или просто не выполнялись?

не бомбили, специальный тест написал.
И выполнялись ОК.
Видать, седьмой арм настолько могучий.

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

А вот ить работали. Пока не...

тихо выполнятся не атомарно.

..но если серьёзно - все эти записи представляют собой интерфейс между маткой и DLL, заполняются один раз на старте и изменяются чуть чаще, чем никогда (в подавляющем большинстве случаев - в основном потоке)

Sergei I. Gorelkin писал(а):) RTL устроена по принципу "в любой непонятной ситуации говори, что это AV", поэтому нужно брать отладчик и смотреть, что происходит на уровне ассемблера.

Access violation - по моему опыту это "выход за предел допустимого". Что может сказать система если вы пишите в область ReadOnly или выходите за рамки своих областей или вообще указываете на несуществующую область.. Эта ошибка очень характерна с работой указателей..
Но если вы пишите в допустимую область, даже в чужие переменные - то ошибок не возникает, в этом проблема указателей..
Только ревизия всего кода может выявить проблему.

Если дело не в packed record и в выравнивании данных, я не буду оспаривать.. то у этого поциента еще в будущем будут чудные открытия в самых неожиданных местах..