Записки программиста

понедельник, 31 июля 2023 г.

How to cleanup wsl's disk

На офисном компе винда сказала, что место кончилось (475 ГБ).
Оказалось, всё съел WSL.

Очищается следующей последовательностью действий в терминале:

wsl --shutdown
diskpart
# open window Diskpart
select vdisk file="C:\WSL-Distros\…\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Source: https://github.com/microsoft/WSL/issues/4699#issuecomment-627133168

среда, 10 мая 2023 г.

How to build and install the kernel

Sources:

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel#apt-get
https://www.maketecheasier.com/build-custom-kernel-ubuntu/
https://stackoverflow.com/a/75622441

The algorithm:

Make source directory (I have named it 'lab') and go there: `mkdir ~/lab; cd ~/lab`
Download linux sources of your distributes: `apt-get source linux-image-unsigned-$(uname -r)`
Download linux sources from git repository: `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git`
Go to the Linus' source directory: `cd ~/lab/linux`
Copy your distribution's config: `cp /boot/config-$(uname -r) .config`
Apply the config: `make olddefconfig`
Copy a directory of your distribution's source in order to sign your build: `cp -avr ~/lab/linux-hwe-5.15-5.15.0/debian ~/lab/linux/debian`
Build the kernel: `make clean && make -j8`
Build deb-package: `make deb-pkg LOCALVERSION=-custom`
Install deb-packages: `sudo dpkg -i ~/lab/linux-*.deb`
Reboot your system with a new kernel =)

вторник, 22 февраля 2022 г.

zettelup

Для облегчения работы с цеттелем с учётом моего тулчейна

(git & Obsidian) написал скрипт `zettleup`, который использую

на телефоне, Linux-е на Винде.

Скрипт на телефоне (Android через Termux)

```

#!/bin/bash

curdir=$(pwd)

cd /storage/E6E0-1F04/zettel # an external SD card

git add . # add any new notes recursively

git commit -am "up" # message doesn't matter for Zettel

git pull

git push

cd ${curdir}

```

В Linux-е скрипт такой-же, меняется только путь к папке репозитория.

Скрипт для винды (zettelup.bat).

```

current_dir="%CD%"

cd "%USERPROFILE%\workspace\zettel"

git add .

git commit -am "up"

git pull

git push

cd "%current_dir%"

```

Скрипт кладём в директорю, которая находится в списке в переменной среды `PATH` (в винде добавлял в PATH новую директорию, т.к. системные трогать не хотел).

Перед "работой" с цеттелем и после неё запускаю `zettelup` (в винде через `Win+R` и прям в строке запуска пишу `zettelup`, на телефоне запускаю Termux и запускаю скрипт в нём, на Linux-е через `Alt+F2`). Даже если ничего нового не писал нигде, это уже как привычка и занимает пару секунд.

Примечание: именнно `zettelup` указанными способами набираю редко. Обычно просто стрелкой вверх выбираю как одну из 3-х последних набранных комманд. Так что получается вполне удобно.

вторник, 27 июля 2021 г.

Reverse Engineering шпаргалка.

Сразу скажу, тут я нуб! Это шпаргалка для меня (как я решил задачу). Ну может кому ещё будет полезна. Данные черпал из Reverse Engineering for Beginners (berkeley.edu)

Вводная:

По работе нужно было исправить логику 3rdparty библиотек, которые предоставил заказчик с хидерами и сборками как static lib в дебажном и релизном варианте. Так как были дебажные версии то решил, что RE будет не сложным. Так и получилось.

Шпаргалка:

1. Получаем asm листнинг библиотеки через утилиту dumpbin, которая идёт в составе Visual Studio.

2. В asm листинге ищем функцию, которую надо "расшифровать" простым поиском по тексту.

3. Для анманглинга имён функций используем утилиту undname из состава Visual Studio.

4. Читаем и пишем свой вариант функции (допустим на С++).

5. Пишем тест на расшифрованную логику.

6. Прогоняем через тест свою функцию и функцию из препарируемой библиотеке.

Детали.

Дело было в винде и я использовал Notepad++. Сделал вертикальный разрез. Справа был чистый asm-листинг - слева был "рабочий" файл, в котором я писал комментарии при расшифровке.

На картинке мои комментарии зелёным.
В процессе расшифровки в комментариях переменные обычно называл так, что бы по asm листингу было проще отследить. Например на скриншоте по адресу [ebp-24h] находится адрес std::vector< uint8_t >. В комментариях я так и назвал переменную - ebp_24. Все переменные ebp-X - это локальные переменные функции. ebp-0h - это адрес нашей функции, в которой мы "находимся". Если функция возвращает значение, то выше 0 в стеке лежит (в случае x86) адрес возвращаемой переменной. Дальше ( ebp+X ) лежат входные параметры функции. Указатели (в этом случае) занимают 8 байт, простые значения (uint8_t, uint32_t) - 4 байта или больше (double, int64_t - 8 байт). Про остальные не скажу, но это легко вычисляется при анализе.

Затем написал функцию и к ней написал тест.

На скриншоте слева код теста, а справа код, который я "родил" в процессе расшифровки. Тест пассится, но с кодом надо ещё разобраться (непонятные магические цифры - надо поглядеть предметную область и понять зачем, может в исходном коде ошибка). AfdxPack::GetIpPack - это препарируемая функция, а AfdxPack2::GetIpPack - это то, что я "родил". Как всегда, тест сильно снижает вероятность ошибки при дешифровке.

среда, 26 мая 2021 г.

GitSvn - ошибка fatal: bad object

При обновлении данных из SVN репозитория заказчика через `git svn fetch` получил следующую ошибку:

W: -empty_dir: branch/MC21FMSINT-583/OHBS/OHBSioGUI/MainForm.resx
Checking svn:mergeinfo changes since r2852: 13 sources, 3 changed
fatal: bad object a3e4f2cbe92958764e31197c3391fe7eccc33f88
rev-list -1 46d79549314a6c8bfd87ce1d50ab15db8992c326
a3e4f2cbe92958764e31197c3391fe7eccc33f88 --not b93da3edf57134b3bd9722ec875219d9ac67c166: command returned error: 128

В поисках решения наткнулся на заметку: Alieniloquent: "git svn fetch dies with \"fatal: bad object\""

Шпаргалка для решения:

Заходим в директорию .git
Запускаем поиск упоминаний о проблемном коммите (в моём случае a3e4f2cbe92958764e31197c3391fe7eccc33f88)
Удаляем бинарные файлы, которые относятся к мержу и черри-пику.
Ещё раз запускаем `git svn fetch`

В моём случае выглядело так (через GitBash в Windows):

rgade@DESKTOP-TFEG50M MINGW64 ~/workspace/myproject/.git (GIT_DIR!)
$ find . -exec grep -Hin a3e4f2cbe92958764e31197c3391fe7eccc33f88 {} \; | grep "Binary file"
Binary file ./svn/.caches/check_cherry_pick2.db matches
Binary file ./svn/.caches/lookup_svn_merge.db matches

rgade@DESKTOP-TFEG50M MINGW64 ~/workspace/myproject/.git (GIT_DIR!)
$ rm ./svn/.caches/check_cherry_pick2.db

rgade@DESKTOP-TFEG50M MINGW64 ~/workspace/myproject/.git (GIT_DIR!)
$ rm ./svn/.caches/lookup_svn_merge.db

воскресенье, 23 мая 2021 г.

Работа с SVN репозиторием через git-svn

Речь не о переносе проекта с SVN на GIT, а про работу с SVN репозиторием через git-svn.

Ситуация: у заказчика SVN репозиторий. Помимо прочего он ещё и в приватном VPN (Checkpoint VPN, по факту не получилось подключиться к нему из Линукса через `snx`, пришлось подключаться из Windows).
Что бы дальше так не мучиться, решил работать через `git-svn`. Наступил на пару граблей. Ниже шпаргалка как работать в таких случаях.

Зачем?

1) При работе с git-svn не нужен постоянный коннект к репозиторию заказчика.
2) Простота создания веток для проверок различных вариантов решения проблемы.

Важно

Вне зависимости от того, в какой git-ветке мы находимся, при вызове git svn dcommit изменения будут заливаться в SVN ветку, на которую мы "настроены" во внешнем SVN репозитории. Я, по ошибке, залил не отревьювленные коммиты в транк, хотя был в другой ветке. Потому и решил эту шпаргалку написать.

Посмотреть, на какую ветку в SVN репозитории сейчас настроены

git svn dcommit -n или git svn dcommit --dry-run. Без реального пуша коммита покажет в какую ветку в SVN репозитории будет заливать данные при вызове git svn dcommit.

Альтернативный вариант.

git svn info

Смотреть поле URL. Например:

$ git svn info
Path: .
URL: http://customer/svn/projectX/trunk
Repository Root: http://customer/svn/projectX
Repository UUID: 10230cbc-1c0b-47a3-9371-a2b47a5679dc
Revision: 843
Node Kind: directory
Schedule: normal
Last Changed Author: Rinat.Gadelshin
Last Changed Rev: 843
Last Changed Date: 2021-05-23 19:32:30 +0300 (Sun, 23 May 2021)

Мы находимся в транке.

Создать новую ветку в SVN репозитории

git svn branch <new_branch_name>

Примечание: после создания новой ветки в SVN репозитории мы не переключились на неё, а остались в настроены на предыдущую SVN ветку. В данном случае на trunk.

Пример создания SVN ветки OHBS-29-3 и переключения Git репозитория на неё. С демонстрацией того, что автоматом не перенастраивается после создания:

$ git svn branch OHBS-29-3
Copying http://customer/svn/projectX/trunk at r843 to http://customer/svn/projectX/branch/OHBS-29-3...
Found possible branch point: http://customer/svn/projectX/trunk => http://customer/svn/projectX/branch/OHBS-29-3, 843
Found branch parent: (refs/remotes/OHBS-29-3) 762910dc607920a9b59d0b5809102e03c19bc7cd
Following parent with do_switch
Successfully followed parent
r845 = c55b0f28e08d0a6db8c06230e0f620e40832a175 (refs/remotes/OHBS-29-3)
$ git svn info
Path: .
URL: http://customer/svn/projectX/trunk
Repository Root: http://customer/svn/projectX
Repository UUID: 10230cbc-1c0b-47a3-9371-a2b47a5679dc
Revision: 843
Node Kind: directory
Schedule: normal
Last Changed Author: Rinat.Gadelshin
Last Changed Rev: 843
Last Changed Date: 2021-05-23 19:32:30 +0300 (Sun, 23 May 2021)
$ git reset OHBS-29-3
HEAD is now at c55b0f28e Create branch OHBS-29-3
$ git svn info
Path: .
URL: http://customer/svn/projectX/branch/OHBS-29-3
Repository Root: http://customer/svn/projectX
Repository UUID: 10230cbc-1c0b-47a3-9371-a2b47a5679dc
Revision: 845
Node Kind: directory
Schedule: normal
Last Changed Author: Rinat.Gadelshin
Last Changed Rev: 843
Last Changed Date: 2021-05-23 19:32:30 +0300 (Sun, 23 May 2021)

Переключиться на другую ветку в SVN репозитории

git reset <branchname>

<branchname> это то, что идёт после remotes/ в выводе `git branch -a`.

Примечание: trunk отображается как remotes/origin/trunk.

Пример переключения на ветку tftp_refactoring и обратно на trunk:

$ git reset tftp_refactoring
$ git reset origin/trunk

Удалить ветку в SVN репозитории

Удалить ветку в SVN репозитории средствами git-svn нельзя (на момент версии 2.31.1). Удалять ветку необходимо средствами Subversion.

Либо через svn rm <full_path_to_branch_folder_on_the_repo
Либо через TortoiseSVN (в винде).

После того, как ветка удалена в SVN репозитории, git svn всё равно её отображает.

Для того, что бы удалить её из Git репозитория, необходимо:

1. git update-ref -d remotes/<branchname>
2. git gc --prune=now

Например, что бы удалить упоминания о ветке OHBS-29 надо выполнить:

git update-ref -d remotes/OHBS-29 && git gc --prune=now

пятница, 24 января 2020 г.

Проблемы с OOM Killer-ом

Шпаргалка

Следующие действия надо выполнять из под пользователя root.

Что бы примелось "сейчас" без перезагрузки:

echo 2 > /proc/sys/vm/overcommit_memory

echo 80 > /proc/sys/vm/overcommit_ratio

Что бы сохранилось после перезагрузки нужно в файл /etc/sysctl.conf дописать (если их там нет) следующие строчки

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

`Суть проблемы`

По умолчанию в Linux ядро всегда "удовлетворяет" запрос на выделение памяти, даже если этой памяти нет. Суть стратегии в том, что программы не всегда используют всю запрашиваемую память, или используют её не сразу, и к тому моменту когда она будет нужна программе, она скорее всего будет доступна. Можно корректировать это поведение через vm.overcommit_memory. Значение 2 для этого аргумента говорит, что если нет "доступной виртуальной" памяти, то вызов malloc() (запрос на выделение памяти в приложении) должен возвращать NULL (честно говорит программе, что памяти которую ей надо в доступе нет.

Второй параметр vm.overcommit_ration определяет, какой процент физической памяти (RAM) + плюс добавленный к ней swap рассматривать, для определения доступного для выделения пространства. Т.е. мы указали, что можно выделять память в 80% процентах RAM + swap. Т.е. на машине с 4GB RAM и 1GB swap для приложений доступно 4.2 ГБ (3.2GB от RAM и 1GB от swap). Если в пределах этого размера нет непрерывного (!!!) свободного пространства, то будет вернут NULL.

Источники:

https://www.kernel.org/doc/Documentation/sysctl/vm.txt
https://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6
http://bl0rg.krunch.be/oom-frag.html
https://utcc.utoronto.ca/~cks/space/blog/linux/DecodingPageAllocFailures

понедельник, 31 июля 2023 г.