| ATS debugging [message #1800730] |
Mon, 07 January 2019 08:33  |
Eclipse User |
|
|
|
A Happy New Year to all.
My ATS which has around 10 PTCs crashes with 'Segmentation fault occurred'
Can someone advice on the topic of debugging?
- Is it possible to step over the TTCN code with a kind of TTCN debugger?
- How can I set a gdb breakpoint to , e.g. a codec in a shared library or to an external function? Note that it would be easy in case of single execution but not in the case of parallel compilation. In this case the test system is started with ttc3_start <ATS>
Thanks for any hint,
Olaf@ETSI-STF160
|
|
|
| Re: ATS debugging [message #1800735 is a reply to message #1800730] |
Mon, 07 January 2019 09:37  |
| Eclipse User |
|
|
|
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 #1800782 is a reply to message #1800779] |
Tue, 08 January 2019 03:51 |
| Eclipse User |
|
|
|
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.05970 seconds
Home