|
Re: ATS debugging [message #1800735 is a reply to message #1800730] |
Mon, 07 January 2019 14:37 |
Botond Baranyi Messages: 55 Registered: February 2016 |
Member |
|
|
Hi Olaf,
1. There is a TTCN-3 debugger integrated into TITAN. To activate it, your TTCN files need to be re-compiled with the compiler option '-n' (this adds extra debugging code to the generated C++ files).
The debugger's commands need to be entered into the Main Controller's interface (mctr_cli). Type 'help' for a list of commands, and 'help <command>' for specific commands (all debugging commands start with 'd'). The debugger doesn't work with the 'ttcn3_start' script. You'll have to pair the Main Controller with the executable manually.
For a detailed description of the debugger see chapter 11 in our Programmers' Technical Reference Guide.
Though I don't think this feature would be useful for analyzing segmentation faults...
2. Debugging a parallel TTCN-3 project with gdb can be rather complicated.
First you'll have to recompile your C++ files with the g++ option '-g'.
You might also need to build a TITAN in debug mode (you won't be able to debug TITAN's code without it). This can be done by adding 'DEBUG := yes' to your Makefile.personal before the build. If you generate your Makefile with TITAN's 'makefilegen' tool, then re-generating the Makefile with a debug-mode TITAN will automatically add '-g' to your C++ compiler flags.
Since you have so many PTCs, I'd suggest using a core dump. If your C++ compiler does not automatically generate a core dump after a segmentation fault, then it needs to be set to do so (sadly, I'm not familiar with generating core dumps...).
If you have the core dump, then simply give it to 'gdb' together with the executable, and you'll be able to debug the code where the segmentation fault occurred.
If you can't/don't want to use core dumps, then you'll have to tell 'gdb' to attach to that PTC's process, where the segmentation fault occurs. This will definitely require a debug-mode TITAN, and you'll have to pair the Main Controller with the Host Controller (your executable) manually again. To find the PTC's process ID, set a breakpoint to the line after the 'fork()' command in function 'TTCN_Runtime::create_ptc' (core/Runtime.cc) in the Host Controller's process (the one you paired with the Main Controller).
You won't need any breakpoints in the PTC's process, since a segmentation fault automatically breaks execution.
Best regards,
Botond Baranyi
|
|
|
|
Re: ATS debugging [message #1800779 is a reply to message #1800755] |
Tue, 08 January 2019 07:54 |
|
Hi Olaf,
sorry to chime in, but usually it's a good idea to test external code separately and thoroughly as it is a lot simpler to debug.
What I usually do is to write some templates, encode-decode them in a loop, and then get some binary samples from an independent source (e.g. wireshark traces) and decode them.
So when it gets used in a more complex environment it already has a degree of credibility and I have a sandbox where I can experiment with any problem should arise.
BR
Elemer
|
|
|
Re: ATS debugging [message #1800782 is a reply to message #1800779] |
Tue, 08 January 2019 08:51 |
Olaf Bergengruen Messages: 127 Registered: November 2018 |
Senior Member |
|
|
Hi Elemer, Botond,
Yes, I agree all external functions and codecs should be tested in a simple single environment, but sporadically you get a situation which you need to dig into core dumps or even debug the big thing.
Here what it worked for me after studying the hints from Botond:
- I wrote an external function to get the pid of the PTC which I want to debug
INTEGER fx__GetPID() {
int pid;
pid = ::getpid();
return INTEGER(pid);
}
and added a log when starting the PTC
- In gdb
- break codec.cc:10756
- attach <pid>
- continue
- Then, I start the SUD (system under test) which initiates the signalling with the ATS
- ... and, it's magic, eventually the ATS halts at codec.cc:10756, and I can step in the code.
Regards and thanks for your support,
Olaf
|
|
|
Powered by
FUDForum. Page generated in 0.05202 seconds