Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » ATS debugging(Tips on how to efficiently debug an ATS)
ATS debugging [message #1800730] Mon, 07 January 2019 13:33 Go to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 122
Registered: November 2018
Senior Member
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 14:37 Go to previous messageGo to next message
Botond Baranyi is currently offline Botond BaranyiFriend
Messages: 53
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 #1800755 is a reply to message #1800735] Mon, 07 January 2019 19:58 Go to previous messageGo to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 122
Registered: November 2018
Senior Member
Thanks, Botond, for your hints.

I will experiment with the different options, but in any case it is a complex process.

I expect the bugs to be in my code, i.e. codecs and external functions. So I would like to somehow set a breakpoint "b codec.cc:10456", then run the test and hopefully gdb will stop at that position where I can inspect variables. But this is not so easy, as you explained in a parallel PTC environment.

Thanks,
Olaf
Re: ATS debugging [message #1800779 is a reply to message #1800755] Tue, 08 January 2019 07:54 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
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 Go to previous message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 122
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
Previous Topic:TTCN-3 3GPP protocol training provider recommendations
Next Topic:USB TestPort for TITAN
Goto Forum:
  


Current Time: Tue Mar 19 06:05:27 GMT 2024

Powered by FUDForum. Page generated in 0.03611 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top