Hi,
I’m currently struggling on porting my protocol Analyzer from Logic1 to Logic2.
When starting Logic2 (v2.3.19) i get an error message “Failed to load custom analyzer (/path/to/my/Analyzer.so): Unable to load library: /path/to/my/Analyzer.so”
What I’ve tried:
Starting a clean project from scratch, calling rename_analyzer.py then build_analyzer.py: All worked fine
Updating SDK to latest Alpha git branch
Compiling sources with a CMakeLists and defining -DLOGIC2
I’ve checked API : all seems fine too
Put breakpoint on both Analyzer constructor and workingThread: Error show up before any break
The error message don’t give a lot information, i don’t know if a symbol is missing or something else, a good start could be a better verbosity level from Logic2?
Sorry for the trouble! Are you building on MacOS or Linux?
If you’re on MacOS, you might be missing this step, now required for Logic 2:
That step does not apply to Linux users.
If you’re running on Linux, or if that doesn’t fix it, could you share your source? Preferably via a public git repo. If it’s closed source, then try sending us the output of ldd .
The error “Failed to load custom analyzer” indicates that the load library called failed, usually due to the system failing to resolve some dependency. It could also indicate that your analyzer depends on a function that’s missing from Logic 2. (a few API calls that are marked in the analyzer headers as “// do not use” have been removed from Logic 2)
Hi, thanks for the response.
Sources are currently closed in our gitlab but i plane to make it available on github.
I’m working under linux.
I managed to find origin of problem by disabling code until library loaded.
It was an abstract class i wrote, declaring it’s destructor as a pure virtual method.
I’m not a cpp expert but I don’t understand why it scrumbled symbols like that, moreover even if i don’t call this code (so it’s probably pruned) the error happend.
I’ve checked that none of my code call deprecated API.
I’m still unable to debug the Analyzer with gdb (GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2), did you experienced this issue?
Could you describe how you are debugging?
One of the challenges of debugging custom analyzers with Logic 2 is that the application launches a handful of processes, because the application is based on electron/chromium. I haven’t checked on Linux if there is an easy way to determine which is the main process. (On windows, it’s the only process that has a title registered with the OS). One solution would be to find which processes has loaded your library with lsof. We need to make an easier solution for this, but we won’t be able to work on the analyzer system for a while. (we’re a tiny company, with only 3 software developers).
I was trying the old fashion way launching Logic with gdb command and breaking on unloaded symbol : ("(gdb) break Analyzer::WorkerThread").
I understant, you’re already doing an amazing job and you’re staying connected to the saleae community!
I’ll take some time to work on it next week, i will update this post if i found a way to debug it on Logic2. Otherwise debugging on Logic1 isn’t a big problem!
Hi
Before you launch the debugger you can set the LD_LIBRARY_PATH environment variable that gives your system a path to the custom dynamic library you’re loading as part of your application, if that’s still an issue.
From bash it would look like:
export LD_LIBRARY_PATH=/path/to/my/:$LD_LIBRARY_PATH
If the environment variable LD_LIBRARY_PATH is empty, you can leave off the “:$LD_LIBRARY_PATH” part.
Then launch your debugger from that same shell.
Ok, finally had a chance to test this. You will need to attach gdb to a running process.
This is because the *.AppImage program we distribute is actually an AppImage wrapper around the Logic software. However, the launched process doesn’t load your analyzer either, it launches another instance of itself which eventually loads your analyzer.
How to identify the process you will want to debug:
Open the Logic 2 app and add your analyzer. (It needs to be added for the lib to be loaded. We load and then unload the lib once at startup to get its identification, but the shared library isn’t loaded again until you add it.
Run ps ax | grep Logic
There should be at least 7 matches. Several will have the path /tmp/.mount_Logic-XXXXXX/Logic. Of those items, look for ones that have the argument --type=renderer. I see two of those on my machine. Note their process IDs.
To figure out which one has loaded your library, run lsof -p <process id> | grep <libYourAnalyzer.so>
One of the two process IDs will have a match, the other will not.
Then, run gdb. Then type attach <process id>.
Let me know if that works for you! I haven’t verified that debugging will work, but I did verify that this will determine the PID of the process that loaded libserial_analyzer.so on Ubuntu 20.
It would be nice if our app displayed the correct process ID somewhere, we may add that.
I’m actually able to attach to the process but gdb seems lost with symbols.
I tried deleting/adding Analyzer.
Here is some traces:
Thread 3.1 "Logic" received signal SIGINT, Interrupt.
0x00007ffff79a17b1 in ?? ()
(gdb) info breakpoint
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> ISO7816Analyzer::WorkerThread
That should be easy to fix. How exactly are you compiling your analyzer? It might be missing the -g flag. If you have any trouble with it, please send me whatever scripts & commands you’re using to build your analyzer. If you’re using build_analyzer.py, please be sure that you’re testing the “debug” output, and not the “release” output, which doesn’t have symbols.
“Never rests on your laurels”
I felt it reading your comment!
You are totally wright, i changed from the python script to a cmake, wich dont add debug flags to gcc commands.
calling cmake with -DCMAKE_BUILD_TYPE=Debug solved the problem!
It’s still not very straight forward to debug since ptrace generate errors if not configured:
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
