Hi,florin I would appreciate it if you can resolve it
My project use java web to control vpp, many binary api are used, such as interfaces, ip, our customize api etc. half a year ago, i use one c++ restful framework ( google‘s pistache) to use vpp binary api, there also has deadlock problem , then i don't know to send mail for help (dont know must subscribe mail can send mail to vpp-dev haha) i think maybe i m not proficient with c++ multithreading that cause deadlock, that time i fount if use one thread also api communication will deadlock so i think many times use api will cause vpp deadlock For resolve this problem, we decide to change it to jvpp, maybe jvpp resolve this deadlock (now this problem also exist) i found git log for vpp new version that vpp resolve a deadlock about svm (i dont know if it can resolve this), but now we update vpp need at least one month (maybe too long) So florin expert , can you analyze this problem? thank you very much! Best regards wanghe Florin Coras <fcoras.li...@gmail.com> 于2022年5月28日周六 01:02写道: > Hi wanghe, > > Unfortunately, jvpp is no longer supported so probably there’s no recent > fix for the issue you’re hitting. By the looks of it, an api msg handler is > trying to enqueue something (probably a reply towards the client) and ends > up stuck because the svm queue is full and a condvar broadcast never comes. > > If you really need to fix this, I’d check jvpp code to see if condvar > broadcasts on dequeue are done properly. > > Regards, > Florin > > > On May 27, 2022, at 12:53 AM, NUAA无痕 <nuaawan...@gmail.com> wrote: > > > > Hi, vpp experts > > > > im use vpp 2101 version > > my project use jvpp communicate with vpp by binary api, but now when > long time run(about 14h) it will deadlock, this is info > > > > 0x00007f2687783a35 in pthread_cond_wait@@GLIBC_2.3.2 () from > /usr/lib64/libpthread.so.0 > > (gdb) bt > > #0 0x00007f2687783a35 in pthread_cond_wait@@GLIBC_2.3.2 () from > /usr/lib64/libpthread.so.0 > > #1 0x00007f2688f198e6 in svm_queue_add () from > /usr/local/zfp/lib/libsvm.so.21.01.1 > > #2 0x000055cdda6856f3 in ?? () > > #3 0x00007f268904c909 in vl_msg_api_handler_with_vm_node () from > /usr/local/zfp/lib/libvlibmemory.so.21.01.1 > > #4 0x00007f2689033521 in vl_mem_api_handle_msg_main () from > /usr/local/zfp/lib/libvlibmemory.so.21.01.1 > > #5 0x00007f2689043fce in ?? () from > /usr/local/zfp/lib/libvlibmemory.so.21.01.1 > > #6 0x00007f2688fba5a7 in ?? () from > /usr/local/zfp/lib/libvlib.so.21.01.1 > > #7 0x00007f2688ef8de0 in clib_calljmp () from > /usr/local/zfp/lib/libvppinfra.so.21.01.1 > > #8 0x00007f263d673dd0 in ?? () > > #9 0x00007f2688fbdf67 in ?? () from > /usr/local/zfp/lib/libvlib.so.21.01.1 > > #10 0x0000000000000000 in ?? () > > > > because i use release version so some info is not show, i found that vpp > new version has change a lot about svm. > > > > for some reason,i need some time to update vpp and now must resolve this > problem > > > > so experts can you give patch for this bug for vpp 2101 version > > > > Best regards > > wanghe > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21479): https://lists.fd.io/g/vpp-dev/message/21479 Mute This Topic: https://lists.fd.io/mt/91372330/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-