Eclipse Community Forums: Eclipse Titan » Experimental Titan build for Raspberry Pi

Re: Experimental Titan build for Raspberry Pi [message #1748575 is a reply to message #1745284]

Thu, 24 November 2016 16:13

Gyorgy Rethy

Messages: 31
Registered: April 2015

Member

Good experience with Titan on Raspberry Pi3, we could compile and execute both the CoAP example from this Forum and the ETSI cooperative ITS conformance test suite (actually, the microSD card's speed matters when compiling big code! Smile

).

But note, Raspbian by default is missing the libssl-dev and libxml2-dev packages, needed for Titan to compile your code:

sudo apt-get update

(just to synch with the raspbian repo before installing them)

sudo apt-get install libssl-dev libxml2-dev expect

(expect is required by ttcn3_start that makes command line test execution easier and automated).

The new Titan version 6.2.0 uses Openssl 1.0.0, which was not included into my Raspbian jessie (2017-09-07-raspbian-stretch.zip), so I needed to add it too:

sudo wget http://ftp.nl.debian.org/debian/pool/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u6_armhf.deb
sudo dpkg -i libssl1.0.0_1.0.1t-1+deb8u6_armhf.deb

and, of course don't forget to add the needed environment settings to the bash initialization script.

nano /home/pi/.bashrc

(just have used the default user name)
Add the lines:

TTCN3_DIR=<path where you have extracted the Titan package>
LD_LIBRARYPATH=/usr/lib
PATH=$PATH:$TTCN3_DIR/bin
export TTCN3_DIR LD_LIBRARYPATH PATH

Basically, that's all, you can start using it... Cool

[Updated on: Mon, 30 October 2017 15:02]

Re: Experimental Titan build for Raspberry Pi [message #1748618 is a reply to message #1748575]

Fri, 25 November 2016 11:00

Johannes Bro

Messages: 56
Registered: June 2015

Member

Nice, thanks a lot !

Re: Experimental Titan build for Raspberry Pi [message #1838965 is a reply to message #1748618]

Wed, 10 March 2021 14:14

Messages: 4
Registered: January 2021

Junior Member

Hello,

i was trying to build Titan 7.1.0 for a Raspberry Pi 4B.
I could build titan and my sources.

But when running a testcase, it works fine until almost the end until this message arrives and the MTC is stopped unexpectedly:

realloc(): invalid next size
 ./../bin/myets: Abort was called
./../bin/myets[0x21ed8c]
/lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0x0)[0xb6836120]
Error: Unexpected end of MTC connection from 127.0.0.1 [127.0.0.1].
MC@nbiotclient: The control connection to MTC is lost. Destroying all PTC connections.
MC@nbiotclient: MTC terminated.
ttcn3_start: error: the MTC terminated unexpectedly
exit

The log-file looks fine and events are logged until i unmap my port. I just used a serial port for this test and that testcase was running successfully on an ubuntu host.
When i comment out the unmapping i get essentially the same error:

free(): invalid pointer
 ./../bin/myets: Abort was called
./../bin/myets[0x21ec3c]
/lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0x0)[0xb68d7120]

The HelloWorld-Example runs without this problem.
I do not know if there are problems in the way i built the things or if the testports have to be adapted.

Does anybody have an idea, what could be the problem here?

The building process was as follows:
I set the compilerflags in Makefile.cfg and in Makefile.personal to:

COMPILERFLAGS := -Wall -fsigned-char

When building titan i got some suspicious warnings (format, format-overflow,..) when building, which i didn't get when building it for ubuntu 18.04. Anyways all was built successfully and also after make install both testcases pass.

             select_union.sus->get_su_byIndex(i)->error("In the %lu. branch: '%s' is not an alternative of union type '%s'", i+1, id->get_ttcnname().c_str(), t_gov->get_typename().c_str());
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~
Statement.cc:3428:61: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
                 select_union.sus->get_su_byIndex(i2)->error("The '%s' is already present in the %lu. branch of select union", id->get_ttcnname().c_str(), i+1);
                                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                              ~~~
Statement.cc: In static member function 'static void Ttcn::Statement::chk_index_redirect(Ttcn::Reference*, Ttcn::ArrayDimensions*, bool, const char*)':
Statement.cc:5426:34: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
               p_index_ref->error("This index redirect would result in a record "
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 "of integer of length %lu, which is not allowed by the length "
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 "restrictions of type `%s'",
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 nof_dims, ref_type->get_typename().c_str());
                 ~~~~~~~~          
  (C++)	 TtcnTemplate.cc
TtcnTemplate.cc: In member function 'char* Ttcn::Template::generate_code_init_seof(char*, const char*)':
TtcnTemplate.cc:4323:33: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
           str = mputprintf(str, "%s.set_size(%lu", name, fixed_part);

I got similar warnings when building my sources.

Re: Experimental Titan build for Raspberry Pi [message #1838999 is a reply to message #1838965]

Thu, 11 March 2021 08:04

Messages: 134
Registered: December 2015

Senior Member

I suspect that some write over the limit.
Can you try to run the test with valgrind?
First add the -g to the CXXFLAGS and the LDFLAGS in the Makefile and completely rebuild the test suite
Instead of ttcn3_start start the test suite manually
Open two terminal
In the 1st one star the main controller
mctr <cfg.file>
It prints out the listening port

On the 2nd terminal start the HC with valgrind
valgrind --trace-children=yes <executable> localhost <listening_port>

In the main controller window, the connection of the HC is indicated. If the execution is not started type
cmtc
smtc
to the main controller window

At the end of the execution the valgrind probably report the place of the write over the limit.

Re: Experimental Titan build for Raspberry Pi [message #1839009 is a reply to message #1838999]

Thu, 11 March 2021 09:51

Messages: 4
Registered: January 2021

Junior Member

Thanks for the fast reply.

Actually i did not specify any LDFLAGS so far, also not when running under ubuntu.
I just used the makefile as it was generated by makefilegen
Which are the Flags i should specify here?

When i rebuilt the suite with the -g flag and started the testsuite manually, valgrind actually indicates an error before it is even connecting to the main controller.
I do not have experience with valgrind, but it seems to be a problem with some arm-specific libraries (/lib/arm-linux-gnueabihf/ld-2.28.so)

I attached the output in the file valgrind.txt
Also i uploaded my Makefile.
Does that give you any insight?

When starting manually, but without valgrind, i see the same error as before.

Attachment: valgrind.txt
(Size: 16.14KB, Downloaded 72 times)
Attachment: Makefile
(Size: 5.81KB, Downloaded 68 times)

Re: Experimental Titan build for Raspberry Pi [message #1839010 is a reply to message #1839009]

Thu, 11 March 2021 09:59

Messages: 134
Registered: December 2015

Senior Member

You can add the -g to the LDFLAGS also

Ignore the valgrind printouts before the connection. Please note the execution is slower than normal. Run the test until the abort.

At the end use the
emtc
exit
command in the main controller

Re: Experimental Titan build for Raspberry Pi [message #1839011 is a reply to message #1839010]

Thu, 11 March 2021 10:32

Messages: 4
Registered: January 2021

Junior Member

The problem is that i do not even get that far - there is never a connection from HC to MC established, when running with valgrind. The output i mentioned before is printed out and then the program is halted.
Even if i wait for a couple of minutes there is no connection established.
On the MC never any HC is connected.

Re: Experimental Titan build for Raspberry Pi [message #1839016 is a reply to message #1839011]

Thu, 11 March 2021 11:27

Messages: 134
Registered: December 2015

Senior Member

The manual execution without the valgrind works?

Re: Experimental Titan build for Raspberry Pi [message #1839017 is a reply to message #1839016]

Thu, 11 March 2021 11:41

Messages: 134
Registered: December 2015

Senior Member

Other approach to catch the buffer overwrite without the valgrind:
Maybe the address sanitizer can catch it. Add the -fsanitize=address to both the CXXFLAGS and the LDFLAGS in the makefile.

See: https://embeddedbits.org/finding-memory-bugs-with-addresssanitizer/
You can try the example in the link to check that the address sanitizer works.

Re: Experimental Titan build for Raspberry Pi [message #1839018 is a reply to message #1839017]

Thu, 11 March 2021 11:58

Messages: 4
Registered: January 2021

Junior Member

Yes the manual execution works and also i tried it now with the HelloWorld-Example and also here it shows the errors and wont connect.

I tried the sanitizer and it shows (for the example of the link you provided and for the testsuite):

==2146==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

Edit:
The previous error was specific to the sanitizer. I had to add -static-libasan to the linker flags.
With the help of the sanitizer i could see that there was a memory leak in a testport, that i adapted. After fixing that it worked all fine. On Ubuntu anyways it worked fine even with that error in the testport. So now i have it running on a Raspberry 4 with Raspbian10 and Titan 7.1.0.
Thank you for your help.

[Updated on: Thu, 18 March 2021 05:39]