LINUX.ORG.RU
решено Форум — Development  

Пытаюсь отловить баг в чужом коде.

 , , ,


1

6

Приветствую. В чём суть:
«Модульный» синт на JUCE https://github.com/awwbees/BespokeSynth/ умеет хостить VST плагины. Но под онтопиком при добавлении плагина останавливается движок аудио, хотя ГУЙ не висит. У автора только Мак, где проблемы нет.

Вся сложность в том, что я в плюсах ноль, а починить хочется. Допустим я запускаю Debug сборку, например в https://github.com/rohanrhu/gdb-frontend или https://www.gdbgui.com/ (можете хотя бы посоветовать, в чём лучше).
Подгружаю плагин, движок вешается. Куда смотреть, чтобы выловить «застрявший» поток?

Можно даже ссылки на howto и тд. В общем, любые конструктивные советы (кроме как забить или купить Мак) приветствуются.

★★★★★

Последнее исправление: kott (всего исправлений: 1)
← Как получить маки сетевух ?
200 OK HTTP/1.0-1.1 →
 ← 1 2 3

Если ты и правда ноль в отладке и плюсах, то придётся использовать просто gdb, так получится хотя бы шелл овер лор.

Начни с info threads. Скинь сюда вывод, а лучше и автору тоже.

pon4ik ★★★★★
()
Ответ на: комментарий от kott

Что бы два раза не ходить - для каждого потока который висит на pthread_mutex_lock и pthread_cond_wait нужно выполнить:


thread <thread id in info threads>
bt full

Если таковых не имеется надо будет предыдущий вывод рассматривать.

Что бы приаттачиться к подвисшему процессу - можно выполнить gdb -p $(pidof programm_name).

pon4ik ★★★★★
()
Ответ на: комментарий от RazrFalcon

Хочешь скриншотики на лоре разглядывать и общаться с автором на уровне: «нажми кнопочку в левом верхнем углу на которой на рисован йух»?

Можешь порекомендовать свой инструмент и продублировать мои инструкции в нём, яж чё - запрещаю?

pon4ik ★★★★★
()

Подгружаю плагин, движок вешается. Куда смотреть, чтобы выловить «застрявший» поток?

Узнать PID процесса этой твоей софтины, с помощью

gdb -p $PID

приаттачиться к нему, дальше как написано выше - вывести список потоков и смотреть, кто из них висит на каких-нибудь примитивах синхронизации.

nvevg
()

И лучше без гуйни, максимум - cgdb.

nvevg
()
Ответ на: комментарий от anonymous

Я в курсе про такую плюшку, но во первых ты уже пропустил full, во вторых для каждого потока который висит на примитиве синхронизации(это вроде тоже можно записать, но будет уже не такой красивый однострочник).

Если автор хочет что бы что-то поделали за него - пусть сам фильтром поработает хотя бы, а не просто модулем IPC.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Не понадобилось плагин загружать, стал при подключении gdb:

Attaching to process 2743
[New LWP 2749]
[New LWP 2750]
[New LWP 2755]

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f4b8ef94fcf in __GI___poll (fds=0x55c49821c460, nfds=2, timeout=timeout@entry=2000) at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
Missing separate debuginfos, use: zypper install krb5-debuginfo-1.18.2-2.1.x86_64 libX11-6-debuginfo-1.6.9-1.4.x86_64 libX11-xcb1-debuginfo-1.6.9-1.4.x86_64 libXau6-debuginfo-1.0.9-1.6.x86_64 libXcursor1-debuginfo-1.2.0-1.4.x86_64 libXext6-debuginfo-1.3.4-1.6.x86_64 libXfixes3-debuginfo-5.0.3-1.10.x86_64 libXrandr-devel-debuginfo-1.5.2-1.6.x86_64 libXrender1-debuginfo-0.9.10-1.11.x86_64 libXss1-debuginfo-1.2.3-1.8.x86_64 libbrotlicommon1-debuginfo-1.0.7-3.4.x86_64 libbrotlidec1-debuginfo-1.0.7-3.4.x86_64 libbz2-1-debuginfo-1.0.8-2.19.x86_64 libcom_err2-debuginfo-1.45.6-1.18.x86_64 libcurl4-debuginfo-7.71.1-1.2.x86_64 libfreetype6-debuginfo-2.10.2-1.2.x86_64 libgcc_s1-debuginfo-10.2.1+git465-1.1.x86_64 libglvnd-debuginfo-1.2.0-4.3.x86_64 libidn2-0-debuginfo-2.3.0-3.1.x86_64 libkeyutils1-debuginfo-1.6-1.18.x86_64 libldap-2_4-2-debuginfo-2.4.50-53.2.x86_64 libnghttp2-14-debuginfo-1.41.0-1.2.x86_64 libopenssl1_1-debuginfo-1.1.1g-2.12.x86_64 libpcre1-debuginfo-8.44-1.18.x86_64 libpng16-16-debuginfo-1.6.37-1.6.x86_64 libpsl5-debuginfo-0.21.1-1.1.x86_64 libpython3_8-1_0-debuginfo-3.8.4-1.2.x86_64 libsasl2-3-debuginfo-2.1.27-3.4.x86_64 libselinux1-debuginfo-3.0-2.2.x86_64 libssh4-debuginfo-0.9.4-1.3.x86_64 libstdc++6-debuginfo-10.2.1+git465-1.1.x86_64 libunistring2-debuginfo-0.9.10-2.7.x86_64 libxcb-dri3-0-debuginfo-1.14-1.2.x86_64 libxcb-glx0-debuginfo-1.14-1.2.x86_64 libxcb-sync1-debuginfo-1.14-1.2.x86_64 libz1-debuginfo-1.2.11-13.18.x86_64
(gdb) 
(gdb) info thread
  Id   Target Id                                       Frame 
* 1    Thread 0x7f4b8f885880 (LWP 2743) "BespokeSynth" 0x00007f4b8ef94fcf in __GI___poll (fds=0x55c49821c460, nfds=2, timeout=timeout@entry=2000) at ../sysdeps/unix/sysv/linux/poll.c:29
  2    Thread 0x7f4b8d2ff700 (LWP 2749) "Pool"         futex_wait_cancelable (private=0, expected=0, futex_word=0x55c4982641d4) at ../sysdeps/nptl/futex-internal.h:183
  3    Thread 0x7f4b8cafe700 (LWP 2750) "JUCE Timer"   futex_abstimed_wait_cancelable (private=0, abstime=0x7f4b8cafdcd0, clockid=-1934631888, expected=0, futex_word=0x55c4982279fc) at ../sysdeps/nptl/futex-internal.h:320
  4    Thread 0x7f4b5b8cf700 (LWP 2755) "JUCE ALSA"    0x00007f4b8ef96797 in ioctl () at ../sysdeps/unix/syscall-template.S:78
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f4b8d2ff700 (LWP 2749))]
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55c4982641d4) at ../sysdeps/nptl/futex-internal.h:183
183       int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
(gdb) bt
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55c4982641d4) at ../sysdeps/nptl/futex-internal.h:183
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55c498264180, cond=0x55c4982641a8) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x55c4982641a8, mutex=0x55c498264180) at pthread_cond_wait.c:638
#3  0x00007f4b8f15ad50 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib64/libstdc++.so.6
#4  0x000055c4966958ab in std::condition_variable::wait<juce::WaitableEvent::wait(int) const::<lambda()> > (__p=..., __lock=..., this=0x55c4982641a8) at /usr/include/c++/10/condition_variable:108
#5  juce::WaitableEvent::wait (this=this@entry=0x55c498264178, timeOutMilliseconds=timeOutMilliseconds@entry=-1) at /usr/share/juce/modules/juce_core/threads/juce_WaitableEvent.cpp:39
#6  0x000055c4968d9fe2 in juce::OpenGLContext::CachedImage::runJob (this=0x55c498263fb0) at /usr/share/juce/modules/juce_opengl/opengl/juce_OpenGLContext.cpp:485
#7  0x000055c4966aa1a6 in juce::ThreadPool::runNextJob (this=0x55c49822adf0, thread=...) at /usr/share/juce/modules/juce_core/threads/juce_ThreadPool.cpp:384
#8  0x000055c4966d788f in juce::ThreadPool::ThreadPoolThread::run (this=0x55c49827aba0) at /usr/share/juce/modules/juce_core/threads/juce_ThreadPool.cpp:36
#9  0x000055c4966c056b in juce::Thread::threadEntryPoint (this=0x55c49827aba0) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:96
#10 0x000055c4966c06c9 in juce::juce_threadEntryPoint (userData=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:118
#11 juce::threadEntryProc (userData=<optimized out>) at /usr/share/juce/modules/juce_core/native/juce_posix_SharedCode.h:834
#12 0x00007f4b8f7d0eaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007f4b8ef9faff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f4b8cafe700 (LWP 2750))]
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7f4b8cafdcd0, clockid=-1934631888, expected=0, futex_word=0x55c4982279fc) at ../sysdeps/nptl/futex-internal.h:320
320       int err = lll_futex_clock_wait_bitset (futex_word, expected,
(gdb) bt
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7f4b8cafdcd0, clockid=-1934631888, expected=0, futex_word=0x55c4982279fc) at ../sysdeps/nptl/futex-internal.h:320
#1  __pthread_cond_wait_common (abstime=0x7f4b8cafdcd0, clockid=-1934631888, mutex=0x55c4982279a8, cond=0x55c4982279d0) at pthread_cond_wait.c:520
#2  __pthread_cond_clockwait (abstime=0x7f4b8cafdcd0, clockid=-1934631888, mutex=0x55c4982279a8, cond=0x55c4982279d0) at pthread_cond_wait.c:677
#3  __pthread_cond_clockwait (cond=cond@entry=0x55c4982279d0, mutex=0x55c4982279a8, clockid=-1934631888, clockid@entry=1, abstime=abstime@entry=0x7f4b8cafdcd0) at pthread_cond_wait.c:665
#4  0x000055c496695818 in std::condition_variable::__wait_until_impl<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > (__lock=..., __lock=..., __atime=..., this=0x55c4982279d0) at /usr/include/c++/10/bits/std_mutex.h:123
#5  std::condition_variable::wait_until<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > (__atime=..., __lock=..., this=0x55c4982279d0) at /usr/include/c++/10/condition_variable:119
#6  std::condition_variable::wait_until<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> >, juce::WaitableEvent::wait(int) const::<lambda()> > (__p=..., __atime=..., __lock=..., this=0x55c4982279d0)
    at /usr/include/c++/10/condition_variable:158
#7  std::condition_variable::wait_for<long int, std::ratio<1, 1000>, juce::WaitableEvent::wait(int) const::<lambda()> > (__rtime=..., __rtime=..., __p=..., __lock=..., this=0x55c4982279d0) at /usr/include/c++/10/condition_variable:185
#8  juce::WaitableEvent::wait (this=0x55c4982279a0, timeOutMilliseconds=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_WaitableEvent.cpp:43
#9  0x000055c4966fd2bd in juce::Timer::TimerThread::run (this=0x55c4982278f0) at /usr/share/juce/modules/juce_events/timers/juce_Timer.cpp:88
#10 0x000055c4966c056b in juce::Thread::threadEntryPoint (this=0x55c4982278f0) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:96
#11 0x000055c4966c06c9 in juce::juce_threadEntryPoint (userData=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:118
#12 juce::threadEntryProc (userData=<optimized out>) at /usr/share/juce/modules/juce_core/native/juce_posix_SharedCode.h:834
#13 0x00007f4b8f7d0eaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#14 0x00007f4b8ef9faff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
kott ★★★★★
() автор топика
Ответ на: комментарий от kott

Если пытаться приаттачиться к просто запущенному процессу, то происходит то что выше.
Если с загрженны плагином и вставшим движком, то:

  Id   Target Id                                        Frame 
* 1    Thread 0x7f577d90bb00 (LWP 14145) "BespokeSynth" 0x00007f577cfa4fcf in __GI___poll (fds=0x2f34e80, nfds=2, timeout=timeout@entry=2000) at ../sysdeps/unix/sysv/linux/poll.c:29
  2    Thread 0x7f5779ae7700 (LWP 14151) "Pool"         futex_wait_cancelable (private=0, expected=0, futex_word=0x2f7c6b0) at ../sysdeps/nptl/futex-internal.h:183
  3    Thread 0x7f57792e6700 (LWP 14152) "JUCE Timer"   futex_abstimed_wait_cancelable (private=0, abstime=0x7f57792e5a50, clockid=2033080752, expected=0, futex_word=0x2f4023c) at ../sysdeps/nptl/futex-internal.h:320
  4    Thread 0x7f57470cf700 (LWP 14236) "BespokeSynth" 0x00007f577cf76fa1 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f57470cea60, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
  5    Thread 0x7f577a87f700 (LWP 14237) "JUCE Timer"   futex_abstimed_wait_cancelable (private=0, abstime=0x7f577a87ea50, clockid=2055727552, expected=0, futex_word=0x2f418e8) at ../sysdeps/nptl/futex-internal.h:320

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

kott ★★★★★
() автор топика
Ответ на: комментарий от kott

Разумеется gdb при аттаче стопает софт. Нужно continue написать, я чет упустил этот момент:)

pon4ik ★★★★★
()
Ответ на: комментарий от kott

Бряки пока рано ставить, показывай bt для потоков 2, 3, 4 и 5. Ох уж эти студия писатели с локфри там где это не нужно.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

А, не эт гдб копнул глубже почему-то чем я ожидал. Пока всё ок надо теперь смотреть стэк в случае именно подвисона.

pon4ik ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

anonymous
()
Ответ на: комментарий от pon4ik

я не догоняю, если оно не упало, а только где-то поток встал, как показать bt, тупо остановить ctrl-c?

Thread 1 "BespokeSynth" received signal SIGINT, Interrupt.
0x00007f878b5dcfcf in __GI___poll (fds=0x2df9e80, nfds=2, timeout=timeout@entry=2000) at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) info thread
  Id   Target Id                                        Frame 
* 1    Thread 0x7f878bf45b00 (LWP 9988) "BespokeSynth"  0x00007f878b5dcfcf in __GI___poll (fds=0x2df9e80, nfds=2, timeout=timeout@entry=2000) at ../sysdeps/unix/sysv/linux/poll.c:29
  2    Thread 0x7f875c497700 (LWP 9994) "Pool"          futex_wait_cancelable (private=0, expected=0, futex_word=0x2e409d4) at ../sysdeps/nptl/futex-internal.h:183
  3    Thread 0x7f875bc96700 (LWP 9995) "JUCE Timer"    futex_abstimed_wait_cancelable (private=0, abstime=0x7f875bc95a50, clockid=1539922352, expected=0, futex_word=0x2e0523c) at ../sysdeps/nptl/futex-internal.h:320
  4    Thread 0x7f875b0df700 (LWP 10308) "BespokeSynth" 0x00007f878b5aefa1 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f875b0dea60, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
  5    Thread 0x7f8788eb7700 (LWP 10309) "JUCE Timer"   futex_abstimed_wait_cancelable (private=0, abstime=0x7f8788eb6a50, clockid=-1997837888, expected=0, futex_word=0x2e068e8) at ../sysdeps/nptl/futex-internal.h:320
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f875c497700 (LWP 9994))]
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x2e409d4) at ../sysdeps/nptl/futex-internal.h:183
183       int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
(gdb) bt
#0  0x00007f878bae77e2 in futex_wait_cancelable (private=0, expected=0, futex_word=0x2e409d4) at ../sysdeps/nptl/futex-internal.h:183
#1  0x00007f878bae77e2 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x2e40980, cond=0x2e409a8) at pthread_cond_wait.c:508
#2  0x00007f878bae77e2 in __pthread_cond_wait (cond=0x2e409a8, mutex=0x2e40980) at pthread_cond_wait.c:638
#3  0x00007f878b8ead50 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () at /usr/lib64/libstdc++.so.6
#4  0x0000000000f4307b in std::condition_variable::wait<juce::WaitableEvent::wait(int) const::<lambda()> > (__p=..., __lock=..., this=0x2e409a8) at /usr/include/c++/10/condition_variable:108
#5  0x0000000000f4307b in juce::WaitableEvent::wait(int) const (this=this@entry=0x2e40978, timeOutMilliseconds=timeOutMilliseconds@entry=-1) at /usr/share/juce/modules/juce_core/threads/juce_WaitableEvent.cpp:39
#6  0x000000000118281a in juce::OpenGLContext::CachedImage::runJob() (this=0x2e407b0) at /usr/share/juce/modules/juce_opengl/opengl/juce_OpenGLContext.cpp:485
#7  0x0000000000f57276 in juce::ThreadPool::runNextJob(juce::ThreadPool::ThreadPoolThread&) (this=0x2e343c0, thread=...) at /usr/share/juce/modules/juce_core/threads/juce_ThreadPool.cpp:384
#8  0x0000000000f8366f in juce::ThreadPool::ThreadPoolThread::run() (this=0x2e56dd0) at /usr/share/juce/modules/juce_core/threads/juce_ThreadPool.cpp:36
#9  0x0000000000f6cd4c in juce::Thread::threadEntryPoint() (this=0x2e56dd0) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:96
#10 0x0000000000f6cea9 in juce::juce_threadEntryPoint(void*) (userData=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:118
#11 0x0000000000f6cea9 in juce::threadEntryProc(void*) (userData=<optimized out>) at /usr/share/juce/modules/juce_core/native/juce_posix_SharedCode.h:834
#12 0x00007f878bae0eaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007f878b5e7aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f875bc96700 (LWP 9995))]
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7f875bc95a50, clockid=1539922352, expected=0, futex_word=0x2e0523c) at ../sysdeps/nptl/futex-internal.h:320
320       int err = lll_futex_clock_wait_bitset (futex_word, expected,
(gdb) bt
#0  0x00007f878bae7e28 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f875bc95a50, clockid=1539922352, expected=0, futex_word=0x2e0523c) at ../sysdeps/nptl/futex-internal.h:320
#1  0x00007f878bae7e28 in __pthread_cond_wait_common (abstime=0x7f875bc95a50, clockid=1539922352, mutex=0x2e051e8, cond=0x2e05210) at pthread_cond_wait.c:520
#2  0x00007f878bae7e28 in __pthread_cond_clockwait (abstime=0x7f875bc95a50, clockid=1539922352, mutex=0x2e051e8, cond=0x2e05210) at pthread_cond_wait.c:677
#3  0x00007f878bae7e28 in __pthread_cond_clockwait (cond=cond@entry=0x2e05210, mutex=0x2e051e8, clockid=1539922352, clockid@entry=1, abstime=abstime@entry=0x7f875bc95a50) at pthread_cond_wait.c:665
#4  0x0000000000f42ff2 in std::condition_variable::__wait_until_impl<std::chrono::duration<long, std::ratio<1l, 1000000000l> > >(std::unique_lock<std::mutex>&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&) (__lock=..., __lock=..., __atime=..., this=0x2e05210) at /usr/include/c++/10/bits/std_mutex.h:123
#5  0x0000000000f42ff2 in std::condition_variable::wait_until<std::chrono::duration<long, std::ratio<1l, 1000000000l> > >(std::unique_lock<std::mutex>&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&)
    (__atime=..., __lock=..., this=0x2e05210) at /usr/include/c++/10/condition_variable:119
#6  0x0000000000f42ff2 in std::condition_variable::wait_until<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> >, juce::WaitableEvent::wait(int) const::<lambda()> > (__p=..., __atime=..., __lock=..., this=0x2e05210)
    at /usr/include/c++/10/condition_variable:158
#7  0x0000000000f42ff2 in std::condition_variable::wait_for<long int, std::ratio<1, 1000>, juce::WaitableEvent::wait(int) const::<lambda()> > (__rtime=..., __rtime=..., __p=..., __lock=..., this=0x2e05210) at /usr/include/c++/10/condition_variable:185
#8  0x0000000000f42ff2 in juce::WaitableEvent::wait(int) const (this=0x2e051e0, timeOutMilliseconds=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_WaitableEvent.cpp:43
#9  0x0000000000fa8812 in juce::Timer::TimerThread::run() (this=0x2e05130) at /usr/share/juce/modules/juce_events/timers/juce_Timer.cpp:88
#10 0x0000000000f6cd4c in juce::Thread::threadEntryPoint() (this=0x2e05130) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:96
#11 0x0000000000f6cea9 in juce::juce_threadEntryPoint(void*) (userData=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:118
#12 0x0000000000f6cea9 in juce::threadEntryProc(void*) (userData=<optimized out>) at /usr/share/juce/modules/juce_core/native/juce_posix_SharedCode.h:834
#13 0x00007f878bae0eaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#14 0x00007f878b5e7aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
kott ★★★★★
() автор топика
Последнее исправление: kott (всего исправлений: 1)
Ответ на: комментарий от kott 
(gdb) thread 4
[Switching to thread 4 (Thread 0x7f875b0df700 (LWP 10308))]
#0  0x00007f878b5aefa1 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f875b0dea60, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
48        r = INTERNAL_SYSCALL_CANCEL (clock_nanosleep_time64, err, clock_id,
(gdb) bt
#0  0x00007f878b5aefa1 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f875b0dea60, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
#1  0x00007f878b5b47c3 in __GI___nanosleep (requested_time=<optimized out>, remaining=<optimized out>) at nanosleep.c:27
#2  0x00007f86ff94533e in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#3  0x00007f86ff9b7e38 in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#4  0x00007f86ff8af2d2 in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#5  0x00007f86ff97e74b in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#6  0x00007f86ff97e849 in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#7  0x00007f878bae0eaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007f878b5e7aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 5
[Switching to thread 5 (Thread 0x7f8788eb7700 (LWP 10309))]
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7f8788eb6a50, clockid=-1997837888, expected=0, futex_word=0x2e068e8) at ../sysdeps/nptl/futex-internal.h:320
320       int err = lll_futex_clock_wait_bitset (futex_word, expected,
(gdb) bt
#0  0x00007f878bae7b08 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f8788eb6a50, clockid=-1997837888, expected=0, futex_word=0x2e068e8) at ../sysdeps/nptl/futex-internal.h:320
#1  0x00007f878bae7b08 in __pthread_cond_wait_common (abstime=0x7f8788eb6a50, clockid=-1997837888, mutex=0x2e06898, cond=0x2e068c0) at pthread_cond_wait.c:520
#2  0x00007f878bae7b08 in __pthread_cond_timedwait (cond=0x2e068c0, mutex=0x2e06898, abstime=0x7f8788eb6a50) at pthread_cond_wait.c:656
#3  0x00007f86ff97e5f5 in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#4  0x00007f86ff9ba19f in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#5  0x00007f86ff97e74b in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#6  0x00007f86ff97e849 in  () at /home/kv/VST/Tracktion/#TBus Compressor.so
#7  0x00007f878bae0eaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007f878b5e7aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
kott ★★★★★
() автор топика
Ответ на: комментарий от kott

похоже на то, что движок ждёт что-то от плагина, а плагин не отвечает. плагин проприетарный или его тоже можно пересобрать в дебаге?

ты уверен, что ты под онтопиком используешь ту же версию плагина, что и автор под маком?

anonymous
()
Ответ на: комментарий от anonymous

плагин проприетарный или его тоже можно пересобрать в дебаге?

этот - проприетарный, ситуация воспроизводится с любыми плагинами, но с некоторыми не сразу, а на 2-3.. попытку вставить, с этим - 100% сразу

можно собрать любой плагин с дебагом и посмотреть

ты уверен, что ты под онтопиком используешь ту же версию плагина, что и автор под маком?

да тут и плагины разные, суть в том, что под онтопиком, как уже говорил, это срабатывает на всех что пробовал

kott ★★★★★
() автор топика

можешь ещё запустить под валгриндом: valgrind <как ты обычно запускаешь приложение>, добавь плагин и посмотри пишет ли валгринд что-то в вывод (это будет stderr) когда ты это делаешь.

anonymous
()
Ответ на: комментарий от kott

на 2-3.. попытку вставить

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

если есть какое-то отладочное логирование в движке или плагинах, то их лучше тоже включить.

anonymous
()
Ответ на: комментарий от anonymous

ok, попробую с открытым плагином, скорее всего завтра уже

автор давал наводки https://github.com/awwbees/BespokeSynth/issues/18#issuecomment-647898117

если есть какое-то отладочное логирование в движке или плагинах, то их лучше тоже включить.

не нашел, надо самому вставлять, готов к рекомендациям

kott ★★★★★
() автор топика
Ответ на: комментарий от kott

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

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

вообще если плагины виснут после 2-3 загрузок, то вариантов на самом деле всего около двух: 1) где-то косяк с памятью и валгринд тебе это сразу покажет 2) состояние гонки которое проявляется не всегда - это немного сложнее. третий вариант - косяк где-то в логике самого движка, но если на винде и маке всё работает, то лучше сначала проверить варианты 1 и 2.

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

anonymous
()
Ответ на: комментарий от kott

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

anonymous
()
Ответ на: комментарий от anonymous

кстати ещё у тебя куда-то делся поток который назывался «JUCE Alsa».

бэктрейса нет? я его не постил

kott ★★★★★
() автор топика
Ответ на: комментарий от kott

А где-то сорцы этого патченного juce есть?

Пока выглядит всё так, что таска в тредпуле ждёт какого-то события извне, которого - не происходит. Притом таска на отрисовку, лол:

#4  0x0000000000f4307b in std::condition_variable::wait<juce::WaitableEvent::wait(int) const::<lambda()> > (__p=..., __lock=..., this=0x2e409a8) at /usr/include/c++/10/condition_variable:108
#5  0x0000000000f4307b in juce::WaitableEvent::wait(int) const (this=this@entry=0x2e40978, timeOutMilliseconds=timeOutMilliseconds@entry=-1) at /usr/share/juce/modules/juce_core/threads/juce_WaitableEvent.cpp:39
#6  0x000000000118281a in juce::OpenGLContext::CachedImage::runJob() (this=0x2e407b0) at /usr/share/juce/modules/juce_opengl/opengl/juce_OpenGLContext.cpp:485
#7  0x0000000000f57276 in juce::ThreadPool::runNextJob(juce::ThreadPool::ThreadPoolThread&) (this=0x2e343c0, thread=...) at /usr/share/juce/modules/juce_core/threads/juce_ThreadPool.cpp:384

Но надо бы почитать чего но там такого ждёт может и нет криминала в этом. Походу анон был прав и глянуть бы bt всех потоков не помешало бы учитывая что их всего 5.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Я бы поставил бряку вот сюда:

https://github.com/baovuong/TapBpm/blob/fc1f7bd72c35255f2cbbf94d7281854771674cac/JuceLibraryCode/modules/juce_opengl/opengl/juce_OpenGLContext.cpp#L121

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

anonymous
()
Ответ на: комментарий от anonymous

Может, но событие которое само запускает цикл обработки событий, кроме смеха у меня ещё обычно вызывает лёгкую паранойю.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

это ты очень древнюю версию нашёл
сам JUCE здесь: https://github.com/juce-framework/JUCE/

А где-то сорцы этого патченного juce есть?

если для сборки сабжа, то я могу накидать инструкцию, из-за VST2 там надо пару приседаний сделать и надо подумать, какой вариант предпочтительней
либо можно собрать с JUCE6, который умеет VST3, слегка поправив:

--- Sample.cpp.orig     2020-07-19 12:00:22.671496182 +1000
+++ Sample.cpp  2020-08-07 08:34:33.380120694 +1000
@@ -118,13 +118,13 @@
 //static
 bool Sample::WriteDataToFile(const char *path, float **data, int numSamples, int channels)
 {
-   ScopedPointer<WavAudioFormat> wavFormat = new WavAudioFormat();
+   WavAudioFormat wavFormat;
    File outputFile(ofToDataPath(path).c_str());
    outputFile.create();
-   FileOutputStream* outputTo = outputFile.createOutputStream();
+   std::unique_ptr<FileOutputStream> outputTo = outputFile.createOutputStream();
    assert(outputTo != nullptr);
    bool b1 {nullptr};
-   ScopedPointer<AudioFormatWriter> writer = wavFormat->createWriterFor(outputTo, gSampleRate, channels, 16, b1, 0);
+std::unique_ptr<AudioFormatWriter> writer (wavFormat.createWriterFor (outputTo.get(), gSampleRate, channels, 16, {}, 0));
    writer->writeFromFloatArrays(data, channels, numSamples);

    return true;

Сам проект пока на JUCE-5.4.7

kott ★★★★★
() автор топика
Последнее исправление: kott (всего исправлений: 1)

цитирую автора из issue:
1

VSTPlugin.cpp should handle basically everything related to VST loading, so that is definitely the place to look. since things are locking up for you, mVSTMutex might be an interesting thing to take a look at.

2

rather than being a specific issue with the transport, I would presume that it’s just the audio thread locking up. the transport is driven by the audio thread, so if the audio thread is frozen, the transport will stop moving.

you could try putting a breakpoint in VSTPlugin::Process() and seeing if it gets caught up on anything in there. the Process() method runs in the audio thread. additionally, the «root» of bespoke’s audio thread work is ModularSynth::audioOut(), so you could trace through there.

the easiest way to see what’s going on might be to break in a debugger when you’re in this frozen state, and see what the audio thread is up to. my presumption would be that it’s stuck acquiring a mutex somewhere.

kott ★★★★★
() автор топика
Ответ на: комментарий от kott

Так что да, надо глянуть в сторону аудио.

kott ★★★★★
() автор топика
Ответ на: комментарий от kott

Собирать я пока не планирую и выхи думаю провести оффлайн. Судя по всему ты не такой неумеха как начал прикидываться, нужно просто найти в этих потоках тот который совсем не двигается и посмотреть в сорцах juce какой примитив синхронизации не дёргается, потом строить предположения почему. Например пока моя рабочая гипотеза из того что удалось увидеть это:

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

pon4ik ★★★★★
()

Попробовал собрать у себя и запустить, проблема воспроизводится, VST Dexed нормально работает (несколько раз добавлял/удалял), Surge иногда ломает аудио. При этом, когда ломает, летят разные ассерты:

JUCE Assertion failure in juce_VSTPluginFormat.cpp:1665
JUCE Assertion failure in juce_VSTPluginFormat.cpp:1673
JUCE Assertion failure in juce_Thread.cpp:100

может поможет. Система Arch, JUCE из репозиториев

kostik1
()
Ответ на: комментарий от pon4ik

ну фиг знает, вот пока что могу вычленить:

Reading symbols from ./BespokeSynth...
(gdb) b VSTPlugin::Process
Breakpoint 1 at 0xda2860: file ../../Source/VSTPlugin.cpp, line 329.
(gdb) run
Starting program: /media/src/src/audio/BespokeSynth/Builds/LinuxMakefile/build/BespokeSynth 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 5291]
[Detaching after fork from child process 5292]
[New Thread 0x7ffff664b700 (LWP 5295)]
0.001: pixel ratio: 1 screen width: 2560 screen height: 1080
[New Thread 0x7ffff5e01700 (LWP 5296)]
[Thread 0x7ffff5e01700 (LWP 5296) exited]
[New Thread 0x7ffff5e01700 (LWP 5297)]
[New Thread 0x7ffff50a0700 (LWP 5298)]
[Thread 0x7ffff664b700 (LWP 5295) exited]
[New Thread 0x7ffff4379700 (LWP 5299)]
[New Thread 0x7ffff42f8700 (LWP 5300)]

Thread 7 "Pool" received signal SIG32, Real-time event 32.
[Switching to Thread 0x7ffff42f8700 (LWP 5300)]
__libc_read (nbytes=4, buf=0x7ffff42f7c10, fd=8) at ../sysdeps/unix/sysv/linux/read.c:26
26        return SYSCALL_CANCEL (read, fd, buf, nbytes);
Missing separate debuginfos, use: zypper install krb5-debuginfo-1.18.2-2.1.x86_64 libX11-6-debuginfo-1.6.9-2.1.x86_64 libX11-xcb1-debuginfo-1.6.9-2.1.x86_64 libXau6-debuginfo-1.0.9-1.6.x86_64 libXcursor1-debuginfo-1.2.0-1.4.x86_64 libXext6-debuginfo-1.3.4-1.6.x86_64 libXfixes3-debuginfo-5.0.3-1.10.x86_64 libXinerama1-debuginfo-1.1.4-1.7.x86_64 libXrandr-devel-debuginfo-1.5.2-1.6.x86_64 libXrender1-debuginfo-0.9.10-1.11.x86_64 libXss1-debuginfo-1.2.3-1.8.x86_64 libbrotlicommon1-debuginfo-1.0.7-3.4.x86_64 libbrotlidec1-debuginfo-1.0.7-3.4.x86_64 libbz2-1-debuginfo-1.0.8-2.19.x86_64 libcom_err2-debuginfo-1.45.6-1.18.x86_64 libcurl4-debuginfo-7.71.1-1.2.x86_64 libfreetype6-debuginfo-2.10.2-1.2.x86_64 libgcc_s1-debuginfo-10.2.1+git465-1.1.x86_64 libglvnd-debuginfo-1.2.0-4.3.x86_64 libidn2-0-debuginfo-2.3.0-3.1.x86_64 libkeyutils1-debuginfo-1.6-1.18.x86_64 libldap-2_4-2-debuginfo-2.4.50-53.2.x86_64 libnghttp2-14-debuginfo-1.41.0-1.2.x86_64 libopenssl1_1-debuginfo-1.1.1g-2.12.x86_64 libpcre1-debuginfo-8.44-1.18.x86_64 libpng16-16-debuginfo-1.6.37-1.6.x86_64 libpsl5-debuginfo-0.21.1-1.1.x86_64 libpython2_7-1_0-debuginfo-2.7.18-2.2.x86_64 libsasl2-3-debuginfo-2.1.27-3.4.x86_64 libselinux1-debuginfo-3.0-2.2.x86_64 libssh4-debuginfo-0.9.4-1.3.x86_64 libstdc++6-debuginfo-10.2.1+git465-1.1.x86_64 libunistring2-debuginfo-0.9.10-2.7.x86_64 libxcb-dri3-0-debuginfo-1.14-1.2.x86_64 libxcb-glx0-debuginfo-1.14-1.2.x86_64 libxcb-sync1-debuginfo-1.14-1.2.x86_64 libz1-debuginfo-1.2.11-13.18.x86_64
(gdb) next
sigcancel_handler (sig=32, si=0x7ffff42f76f0, ctx=0x7ffff42f75c0) at nptl-init.c:148
148       if (sig != SIGCANCEL
(gdb) continue
Continuing.
[Thread 0x7ffff42f8700 (LWP 5300) exited]
[Thread 0x7ffff4379700 (LWP 5299) exited]
[New Thread 0x7ffff664b700 (LWP 5457)]
0.001: output: Gina3G, Gina3G; Front output / input   input: Gina3G, Gina3G; Front output / input
0.574333: Loading layout: /home/kv/.config/BespokeSynth/data/layouts/blank.json
6.17433: loading VST: /home/kv/.config/BespokeSynth/data/VST/PAPU.so
[Switching to Thread 0x7ffff664b700 (LWP 5457)]

Thread 8 "JUCE ALSA" hit Breakpoint 1, VSTPlugin::Process (this=0x7ffff00b8490, time=6174.3333333334767) at ../../Source/VSTPlugin.cpp:329
warning: Source file is more recent than executable.
329     //void VSTPlugin::Process()
(gdb) info thread
  Id   Target Id                                       Frame 
  1    Thread 0x7ffff6935040 (LWP 5264) "BespokeSynth" rename (old=0x18eaa40 "/home/kv/.config/BespokeSynth/data/internal/.used_vsts_temp7ab88a79.json", new=0x7fffc4833fc0 "/home/kv/.config/BespokeSynth/data/internal/used_vsts.json") at ../sysdeps/unix/sysv/linux/rename.c:29
  4    Thread 0x7ffff5e01700 (LWP 5297) "Pool"         futex_wait_cancelable (private=0, expected=0, futex_word=0x18da9a0) at ../sysdeps/nptl/futex-internal.h:183
  5    Thread 0x7ffff50a0700 (LWP 5298) "JUCE Timer"   futex_abstimed_wait_cancelable (private=0, abstime=0x7ffff509fcd0, clockid=-183894992, expected=0, futex_word=0x18a0a5c) at ../sysdeps/nptl/futex-internal.h:320
* 8    Thread 0x7ffff664b700 (LWP 5457) "JUCE ALSA"    VSTPlugin::Process (this=0x7ffff00b8490, time=6174.3333333334767) at ../../Source/VSTPlugin.cpp:329
(gdb) thread 8
[Switching to thread 8 (Thread 0x7ffff664b700 (LWP 5457))]
#0  VSTPlugin::Process (this=0x7ffff00b8490, time=6174.3333333334767) at ../../Source/VSTPlugin.cpp:329
329     //void VSTPlugin::Process()
(gdb) bt
#0  VSTPlugin::Process (this=0x7ffff00b8490, time=6174.3333333334767) at ../../Source/VSTPlugin.cpp:329
#1  0x0000000000dfa762 in ModularSynth::AudioOut (this=0x18bafe0, output=0x7fffc485ee20, bufferSize=128, nChannels=6) at /usr/include/c++/10/bits/stl_vector.h:1043
#2  0x0000000000e78b2a in juce::AudioDeviceManager::audioDeviceIOCallbackInt (this=0x18baca0, inputChannelData=0x7fffc48b2b00, numInputChannels=2, outputChannelData=0x7fffc485ee20, numOutputChannels=6, numSamples=128) at /usr/share/juce/modules/juce_core/memory/juce_HeapBlock.h:219
#3  0x0000000000e6f07c in juce::(anonymous namespace)::ALSAThread::run (this=0x7fffc48b2350) at /usr/share/juce/modules/juce_core/memory/juce_HeapBlock.h:182
#4  0x0000000000f7bf8c in juce::Thread::threadEntryPoint (this=0x7fffc48b2350) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:96
#5  0x0000000000f7c0e9 in juce::juce_threadEntryPoint (userData=<optimized out>) at /usr/share/juce/modules/juce_core/threads/juce_Thread.cpp:118
#6  juce::threadEntryProc (userData=<optimized out>) at /usr/share/juce/modules/juce_core/native/juce_posix_SharedCode.h:834
#7  0x00007ffff799deaa in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00007ffff74c4aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) continue
Continuing.
6.17433: JSON saved to /home/kv/.config/BespokeSynth/data/internal/used_vsts.json
Attempting to load VST: /home/kv/.config/BespokeSynth/data/VST/PAPU.so
[Thread 0x7ffff664b700 (LWP 5457) exited]
JUCE v5.4.7
Creating VST instance: PAPU
[New Thread 0x7ffff664b700 (LWP 6048)]
[New Thread 0x7fffc2371700 (LWP 6049)]
Initialising VST: PAPU (1.0.4.0)
6.17433: vst inputs: 1  vst outputs: 2
kott ★★★★★
() автор топика
Ответ на: комментарий от kott

Так, ну раз оно обрабатывает сигналы, значит цикл крутится. На что в принципе и живой gui намекает (хотя ничто не мешает крутиться GUI если GUI это таска со своим лупом).

У тебя где-то разбежались сорцы с бинарниками:

warning: Source file is more recent than executable.

Вряд ли это критично, но лучше избегать такого.

Пока новых идей нет. Я бы всё же поставил бряки на pause/resume что бы убедиться что нет пауз без возобновления.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Вряд ли это критично, но лучше избегать такого.

это я игрался

Я бы всё же поставил бряки на pause/resume что бы убедиться что нет пауз без возобновления.

не совсем понял, куда именно

kott ★★★★★
() автор топика
Последнее исправление: kott (всего исправлений: 1)
Ответ на: комментарий от kott

я собрал один плагин с debug, он валит вообще в сегфолт, причем релизный билд работал нормально 4 раза (не останавливая движок), при следующем запуске - с остановкой =/

наводит на мысли, что VST-хост под онтопиком в JUCE написан коряво и плохо протестирован, косвенное доказательство - один единственный коммерческий продукт с данной функцией - Tracktion, у него часть сорцов открыта, но это пока не сильно обнадёживает

kott ★★★★★
() автор топика
Ответ на: комментарий от kott

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

anonymous
()
Ответ на: комментарий от kott

ChannelBuffer.cpp:59

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

простейшее исправление - найти где переменная объявлена и проинициализировать. это скорее всего не устранит проблему, но сдвинет её в более «реальную» плоскость, когда валгринд будет говорить уже не про неинициализированную переменную, а про ту ошибку которая привела к использованию неинициализированной переменной.

ChannelBuffer.cpp:61

аналогично. 99.999% это одна и та же проблема.

Invalid read of size 8

и последующий сегфолт - последствия предыдущей проблемы.

anonymous
()
Ответ на: комментарий от kott

чтобы не совокупляться с текстовым интерфейсом гдб, можешь поставить себе вот это: https://code.visualstudio.com/download, тут есть фронтенд к гдб в котором можно поставить брейкпоинт, пошагать дебагер, посмотреть значение переменных и т.д. надо только настроить параметры запуска - прописать какой бинарник запускать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3
← Как получить маки сетевух ?
Development
200 OK HTTP/1.0-1.1 →