How to debug plugins?

Developers
1

I’ve used the Plog class to write log messages, but what are the other options for plugin debugging? Can we use a debugger?

Particularly when jami does not launch anymore, probably because of plugins conflict or a plugin error. How to find the cause of the error? What can be done to restore a running jami?

2

Hello,

There are two ways you can debug plugins: in jami itself (using logs) or using a runnable plugin build (where you will be able to debug with breakpoints and all). We recently added this second test for AutoAnswer, AudioFilter, WaterMark and GreenScreen.

If you installed a faulty plugin and because of it now you cannot launch jami. you can manually remove it in two steps:
1 - In ~/.config/jami/dring.yml replace

  installedPlugins:
    - <installed_plugin>
    - <installed_plugin>
  loadedPlugins:
    - <loaded_plugin>
    - <loaded_plugin>

with

  installedPlugins:
    []
  loadedPlugins:
    []

2 - remove directory ~/.local/share/jami/plugins

3

Hello @agsantos,

Can you be a bit more explicit?

I’ve seen that AutoAnswer can be built into a standalone executable to run some tests but how do you define __DEBUG__ in the build process?

I did not found such tests for the other plugins. But I found the TestSuite plugin whose usage is not obvious. How does it help testing plugins?

Thanks for pointers and more hints.

4

Hi,

the TestSuite is a non user directed plugin. It is meant to be used on daemon unit tests.

For AutoAnswer, AudioFilter, WaterMark and GreenScreen, you can build their standalone versions with ./build.sh -d . In their main.cpp file you can find the main function that will trigger the plugin process.
You don’t need to manually set __DEBUG__ as the build script should handle it.

If you are using windows, all you need to do is change the plugin package.json file to set TESTPROCESS=True.

5

Hi,

  1. How to regenerate the build.sh script?
    When I first generated my plugin source templates with the plugin SDK, the debug -d option was not supported. It is still not included in the build.sh template on GitLab. Is it a feature in the tube that is not published yet and should I wait a bit to get it?
    Meanwhile, I’m going to patch my build.sh with what is available in the other plugins…
6

Hello,

The suggestion is for you to patch you build.sh with what is available in the other plugins rather than wait for a template version.

7

Adding error messages seen while developing plugins and their cause. It’ll help other plugin developers, particularly if this forum content is indexed by search engines.

  1. Jami crashes and writes
terminate called after throwing an instance of 'Json::LogicError'
  what():  Type is not convertible to string

Caused by invalid translation messages file. Check that the JSON files in data/locale contain only key-value lines.

8
  1. Preferences don’t display and there are no hints in Jami logs about what’s happening. Check JSON syntax in the preferences.json or accountpreferences.json files. A missing comma or ] won’t make the plugin crash, like in the case of a JSON syntax error in the locale JSON files.
    In case the JSON syntax is valid according to a JSON validator, you have to check that you used the correct keys and try variants to spot where the bug is. This is particularly frustrating! And writing a valid preferences file from scratch is an impossible mission…
9

Hello, for creating preferences you can use the plugins SDK available within the plugin repository.

It is a python interactive script that provides some documentation on the plugins.
The SDK is not completely up to date for the possible handlers but the preferences file structure did not change since the SDK was created.