Обновился-таки, значит, на hardened gentoo (гибрид с zen-ядром), - Запись на стене пользователя Евгений Козлов в Вконтакте. Комментарии и лайки к записи.

Евгений Козлов dzheika

Обновился-таки, значит, на hardened gentoo (гибрид с zen-ядром), и уж не знаю, из-за этого ли, али ещё из-за чего, но пропали некоторые файлы из /sys, связанные с acpi и информации о батарее [хотя подозреваю, что все же из-за перехода на 3.8.x с 3.7.x, т.к. из-за GrSecurity руту, скорее всего, были бы доступны эти файлы, а их, увы, нет]. И отвалился, значит, xfce4-sensors-plugin с SEGV. Как мне казалось, а SEGV вызывало обращение по адресу 0x20, проблема таилась в магической защите переполнения стека (SSP), которая реализуется через помещение рандомного числа в gs:20 (да-да, я помню, что 20, а что это в десятичной — как-то и не уловил), которое потом помещается в стек для проверки. Ок, пересобрал без SSP, затем полностью ванильным gcc, но результат такой же... Странно, подумал я. Пришлось лезть в код... А там такое понахуеверчено...

В общем-то примерно такое (код показать куда лучше, чем словами объяснять)

* ptr = NULL;

if (file_opened("/sys/.../file-1")) { ptr = alloc(); ... }
if (file_opened("/sys/.../file-2")) { ptr->xxx = ...; ...}
if (file_opened("/sys/.../file-3")) { ptr->yyy = ...; ...}

Ну и когда все три файла присутствуют, то всё ок)
В моём случае был только file-3, а +0x20 — это просто смещение поля yyy в структуре, на которую ссылался *ptr)

Дальше — веселее...

Бесконечный цикл типа for (i=0; i<x; /* none */) { if (cond(i)) { i++; } } — понятное дело, выполняется до первого cond(i)=>false.

It was updated, it means, on the hardened gentoo (a hybrid with a zen-core), and I don’t know if it’s because of that, or because of that, but some files from / sys related to acpi and battery information were missing [although I suspect that all the same because of the transition to 3.8.x from 3.7.x, because because of the GrSecurity root, these files would most likely be available, but alas, they are not]. And it fell off, which means xfce4-sensors-plugin with SEGV. As it seemed to me, and SEGV caused an address at 0x20, the problem lurked in the magical protection of stack overflow (SSP), which is implemented by placing a random number in gs: 20 (yes, I remember that 20, and that it is in decimal - somehow did not catch), which is then placed on the stack for verification. Ok, I rebuilt without SSP, then completely vanilla gcc, but the result is the same ... Strange, I thought. I had to go into the code ... And there it’s ponahuvercheno ...

In general, something like this (the code to show is much better than words to explain)

* ptr = NULL;

if (file_opened ("/ sys /.../ file-1")) {ptr = alloc (); ...}
if (file_opened ("/ sys /.../ file-2")) {ptr-> xxx = ...; ...}
if (file_opened ("/ sys /.../ file-3")) {ptr-> yyy = ...; ...}

Well, when all three files are present, then everything is OK)
In my case, there was only file-3, and + 0x20 is just a displacement of the yyy field in the structure referenced by * ptr)

Further - more fun ...

An infinite loop of the type for (i = 0; i <x; / * none * /) {if (cond (i)) {i ++; }} - understandably, it runs until the first cond (i) => false.

У записи 1 лайков,
0 репостов.

Эту запись оставил(а) на своей стене Евгений Козлов