AIMP Forum

AIMP for PC => Дополнения / Addons => Разработка / Development => Topic started by: DarkDrawKill on March 28, 2026, 23:49:29

Title: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on March 28, 2026, 23:49:29
Как дебагать скомпилированную библиотеку на линукс через gdb
хоть оно скомпилированно с метками но когда падает просто пишет ошибку (не факт что библиотека падает с такой ошибкой) и всё
Title: Re: Дебаггинг
Post by: Artem on March 29, 2026, 09:20:34
Не подскажу, GDB не использую
Title: Re: Дебаггинг
Post by: DarkDrawKill on March 29, 2026, 14:41:17
чёто там разобрался

плагин падает в функции RegisterExtension но от чего я не понял (расширение создаётся без ошибок и все методы перегружены)
добавил архив с исходниками и сошкой (дебаг метки прилагаются)
Title: Re: Дебаггинг
Post by: Artem on March 30, 2026, 08:10:18
плагин падает в функции RegisterExtension но от чего я не понял

у frame RefCount = 0, вот он и прибился раньше времени. Вам надо сделать ему ._addRef сразу после создания
Title: Re: Дебаггинг
Post by: DarkDrawKill on March 30, 2026, 08:12:49
у frame RefCount = 0, вот он и прибился раньше времени. Вам надо сделать ему ._addRef сразу после создания
пробывал делать но тоже самое
я его потом убрал (в плагине wgmstream также сделано)
Title: Re: Дебаггинг
Post by: Artem on March 30, 2026, 14:29:29
На сколько я вижу, вместо frame как IUnknown приходит что-то другое. Плеер падает при попытке вызвать _AddRef.
В VgmStream у меня там нет auto, плюс я собирал на VC++, может есть какие-то разночтения между компиляторами.
Title: Re: Дебаггинг
Post by: DarkDrawKill on March 30, 2026, 18:08:21
В VgmStream у меня там нет auto
изначально у меня был как в vgmstream тоесть объект создавался и сразу передавался но изза ошибки я уже сделал отдельную переменную чтобы вызвать AddRef но не исправить ошибку не вышло

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

гзв проблему так не решил но заметил что у IUnknown и IUnknownImpl разные атрибуты у функций (у IUnknown используется cdecl а IUnknownImpl реализует их уже stdcall)
Title: Re: Дебаггинг
Post by: Artem on March 30, 2026, 19:29:51
calling convention для 64битного кода не применяется
Title: Re: Дебаггинг
Post by: DarkDrawKill on March 30, 2026, 20:02:24
calling convention для 64битного кода не применяется
теперь понятно почему компилятор предупреждениями сыпит

решил пока отойти от расширений и хотя бы реализовать чтото простое
Code: [Select]
  IAIMPServiceVersionInfo* versionService = nullptr;
  auto success = core->QueryInterface(IID_IAIMPServiceVersionInfo, reinterpret_cast<void**>(&versionService));
  if (Failed(success))
    return E_FAIL;

  auto version = versionService->GetVersionID();
  versionService->Release();
  return S_OK;
ядро не возвращает сервис с ошибкой E_FAIL даже версию не узнать >:(
Title: Re: Дебаггинг
Post by: Artem on March 30, 2026, 23:06:23
Корень проблемы нашел: неправильное выравнивание в структурах.
Единственное, пока что-то не получается заставить GCC упаковывать структуры должным образом - ни через pragma, ни через атрибуты что-то не хочет.

Маркер правильной упаковки такой:
Code: [Select]
if (sizeof(GUID) != 16)
  return E_FAIL;
Title: Re: Дебаггинг
Post by: DarkDrawKill on March 31, 2026, 00:24:40
Единственное, пока что-то не получается заставить GCC упаковывать структуры должным образом - ни через pragma, ни через атрибуты что-то не хочет.
проблема была не в выравнивании а в типах
Code: [Select]
(gdb) ptype IID_IUnknown
type = const struct GUID {
    DWORD Data1;
    WORD Data2;
    WORD Data3;
    BYTE Data4[8];
}
(gdb) print sizeof(DWORD)
$3 = 8
(gdb) print sizeof(WORD)
$4 = 2
(gdb) print sizeof(BYTE)
$5 = 1
DWORD занимал 8 байт вместо 4 изза typedef unsigned long DWORD; (в линукс x86 long и long long занимают 8 байт почемуто) поэтому структура увеличилась в размере до 20 байт а компилятор выравнял её до 24
я добавил #include <cstdint> и заменил на typedef uing32_t DWORD и ядро мне вернуло сервис :))

гзв или использовать unsigned int
Title: Re: Дебаггинг
Post by: Artem on March 31, 2026, 00:35:39
Да, что-то я не проверил размерность базовых типов, хотя идея такая была...
Боюсь мне надо многое пройти по SDK и перепроверить. long и unsigned long у меня довольно много...
Title: Re: Дебаггинг
Post by: Artem on March 31, 2026, 08:47:37
Вот подправленная версия
Title: Re: Дебаггинг
Post by: DarkDrawKill on March 31, 2026, 13:09:14
да теперь всё точно работает но первая проблема так и не решилась :'(
я и регистры смотрел и втаблицу парсил всё в порядке должно работать но падает с ошибкой (даже перегруз _AddRef добавлял всё бестолку)

upd вопрос будет ли плеер падать если на регистрацию передать нулевой указатель?
Title: Re: Дебаггинг
Post by: Artem on March 31, 2026, 13:35:46
если на регистрацию передать нулевой указатель?

да.

но первая проблема так и не решилась :'(

Вечером поисследую
Title: Re: Дебаггинг
Post by: Artem on March 31, 2026, 14:57:05
Нашёл причину, придётся подождать обновления плеера.
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on March 31, 2026, 15:06:43
Хотя можно и не ждать:
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on March 31, 2026, 19:39:16
из изменений я вижу теперь guid передаётся напрямую а не через ссылку
но плагин всё равно падает
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on March 31, 2026, 21:06:47
из изменений я вижу теперь guid передаётся напрямую а не через ссылку

Да, но не везде.

но плагин всё равно падает

У меня не падает, но я собирал на g++, а не на mingw. Вот команда:

Code: [Select]
g++ -g3 -gdwarf-3 -c -fPIC -I"/usr/include/cairo" -I"../aimp_sdk" -Wno-attributes ./subsonicOptionsDialogFrame.cpp ./subsonicPlugin.cpp ./../aimp_sdk/apiTypes.cpp
g++ -shared -lstdc++ -lgcc ./../aimp_sdk/apiTypes.o ./subsonicPlugin.o ./subsonicOptionsDialogFrame.o -o ./aimp_subsonic.so
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on March 31, 2026, 21:33:57
У меня не падает, но я собирал на g++, а не на mingw. Вот команда:
попробовал как у вас и у меня он всё равно упал
попробую переустановить аимп

гзв проблема была не в аимпе а в дебаггере в нём аимп падает а если просто запустить без дебаггера то всё регистрирует
гзв2 нет проблема ещё тривиальней
плеер не падает а дебаггер просто останавливает программу на ошибке сегментации если продолжить (continue или c) то плагин продолжит работать
проблема в том что вкладка плагина не появляется в разделе плагины
видимо плеер ловит ошибку сегментации но просто с ней ничего не делает возвращая S_OK и плагин удачно инициализируется но вкладка не появляется
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 01, 2026, 00:02:50
скиньте собранный плагин, на котором вываливается ошибка сигментации
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on April 01, 2026, 00:16:09
скиньте собранный плагин, на котором вываливается ошибка сигментации
архив в закрепе
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 01, 2026, 10:11:12
Ошибка здесь:
Code: [Select]
  if (Succeeded(p_plugin->getCore()->QueryInterface(IID_IAIMPServiceUI, reinterpret_cast<void**>(uiService)))) {

Должно быть так:
Code: [Select]
  if (Succeeded(p_plugin->getCore()->QueryInterface(IID_IAIMPServiceUI, reinterpret_cast<void**>(&uiService)))) {
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on April 01, 2026, 10:46:32
Должно быть так:
ой блин видимо случайно стёр в емаксе когда команду прожимал и забыл
спасибо

гзв нормально если при E_FAIL я верну HWND = 0?
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 01, 2026, 10:51:10
а там вариантов других нет...
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on April 13, 2026, 17:26:01
забавно что компилятор предупреждает что идёт преобразование константы в переменную в строках типа
Code: [Select]
static const PChar string = TEXT("...");

предполагаю он думает что константа именно ссылка а строка изменяемая
решается заменой на
Code: [Select]
static const TChar string[] = TEXT("...");
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 14, 2026, 07:21:42
Конечно, можно и переделать на значения.
А разве не так должно быть:
Code: [Select]
static const TChar[] string = TEXT("...");
?
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on April 14, 2026, 08:14:48
А разве не так должно быть:
незнаю у меня компилятор есть мой вариант который я использую для статических строк для InfoGet

гзв погуглил все пишут [] после названия переменной
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 15, 2026, 09:30:54
незнаю у меня компилятор есть мой вариант который я использую для статических строк для InfoGet

гзв погуглил все пишут [] после названия переменной

Да, это я с Java спутал.
В SDK заменил объявление констант на TChar Name[]
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on April 18, 2026, 01:05:11
какой алгоритм используется для генерации хеш кодов для строк?
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 18, 2026, 11:12:15
Bob Jenkin, а что?
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: DarkDrawKill on April 18, 2026, 11:26:42
Bob Jenkin, а что?
придётся гдето ковырять реализацию md5 для utf8 и преобразовывать с utf16 в utf8 для виндовс
Title: Re: Дебаггинг плагина на C++ под Linux
Post by: Artem on April 18, 2026, 11:35:47
придётся гдето ковырять реализацию md5 для utf8 и преобразовывать с utf16 в utf8 для виндовс
Md5 16 байт, а хеш встроенный всего 4. Туда он никак не влезет