ccnx-lite-relay example crashing in native board

Help archive
1

Hello,

I am new to RIOT and trying to run the ccnx-lite-relay example on native system. The compilation goes fine but when I try to run, it crashes with following error (with stacktrace):

Program received signal SIGSEGV, Segmentation fault. 0x0805924e in search_suitable_block (fli=0xffffc830, sli=0xffffc834) at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/pkg/native/tlsf/src/tlsf.c:346 346 unsigned int sl_map = control->sl_bitmap[fl] & (((unsigned int)~0) << sl); (gdb) bt #0 0x0805924e in search_suitable_block (fli=0xffffc830, sli=0xffffc834) at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/pkg/native/tlsf/src/tlsf.c:346 #1 0x08059a0c in block_locate_free (size=1024) at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/pkg/native/tlsf/src/tlsf.c:555 #2 0x08059ed7 in tlsf_malloc (size=1024) at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/pkg/native/tlsf/src/tlsf.c:715 #3 0x0805a26c in malloc (bytes=1024) at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/pkg/native/tlsf/src/tlsf-malloc.c:9 #4 0xf7e5cd3e in _IO_file_doallocate () from /lib32/libc.so.6 #5 0xf7e6a457 in _IO_doallocbuf () from /lib32/libc.so.6 #6 0xf7e697f9 in _IO_file_overflow () from /lib32/libc.so.6 #7 0xf7e68964 in _IO_file_xsputn () from /lib32/libc.so.6 #8 0xf7e41d17 in vfprintf () from /lib32/libc.so.6 #9 0xf7e48f66 in printf () from /lib32/libc.so.6 #10 0x08049749 in usage_exit () at /home/fadedreamz/riotos/RIOT/cpu/native/startup.c:198 #11 0x08048eb4 in startup (argc=1, argv=0xffffd024) at /home/fadedreamz/riotos/RIOT/cpu/native/startup.c:254 #12 0x0805cdcb in __libc_csu_init ()

gdb shows that 5: control = (control_t *) 0x0

The control is a null pointer, so I guess the crash is due to null pointer dereferencing.

Is there any additional parameter required for ccnx-lite-relay for running it over the native system?

Thanks in advance.

2

Hi,

The issue previously mentioned was due to same signature of two different types of malloc/free function.

The malloc/free used by printf was causing the crash as it was trying to use the malloc/free defined from tlsf library, causing the call to search_suitable_block() before actually allocating memory by the library.

It can be solved by adding following define in the Makefile to specify any prefix for the tlsf specific malloc/free

CFLAGS += -DTLSF_MALLOC_PREFIX=mytlsf_

this will make tlsf malloc to become mytlsf_malloc/mytlsf_free and then the printf will use the correct malloc/free function.

3

Hi Nazmul,

The issue previously mentioned was due to same signature of two different types of malloc/free function. The malloc/free used by printf was causing the crash as it was trying to use the malloc/free defined from tlsf library, causing the call to search_suitable_block() before actually allocating memory by the library.

It can be solved by adding following define in the Makefile to specify any prefix for the tlsf specific malloc/free

CFLAGS += -DTLSF_MALLOC_PREFIX=mytlsf_

this will make tlsf malloc to become mytlsf_malloc/mytlsf_free and then the printf will use the correct malloc/free function.

I'm not sure I understand the problem. First of all, the ccn-lite-relay example works perfectly fine on native when I try it. Second, it is supposed to use tlsf for malloc instead of the host system's malloc implementation. TLSF works fine on native and other 32 bit platforms that I tested.

Have you made sure that you have created at least on tap device?

Cheers, Oleg

4

Hi Oleg,

Sorry for the poor explanation.

I have created four tap devices. But the image was crashing before running the ccn-lite-relay example.

Following stacktrace suggests that it crashed inside the printf function which tries to use the malloc defined in tlsf.

#3 0x0805a26c in malloc (bytes=1024) at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/pkg/native/tlsf/src/tlsf-malloc.c:9 … #8 0xf7e41d17 in vfprintf () from /lib32/libc.so.6 #9 0xf7e48f66 in printf () from /lib32/libc.so.6 #10 0x08049749 in usage_exit () at /home/fadedreamz/riotos/RIOT/cpu/native/startup.c:198 #11 0x08048eb4 in startup (argc=1, argv=0xffffd024)

But tlsf malloc will work only if is initialized previously with tlsf_create_with_pool() (as per my understanding).

Following lines defined in tlsf-malloc.h

#ifndef TLSF_MALLOC_PREFIX

define TLSF_MALLOC_PREFIX

#endif #define __TLSF_MALLOC_NAME(A, B) A ## B #define _TLSF_MALLOC_NAME(A, B) __TLSF_MALLOC_NAME(A, B) #define TLSF_MALLOC_NAME(NAME) _TLSF_MALLOC_NAME(TLSF_MALLOC_PREFIX, NAME) … void *TLSF_MALLOC_NAME(malloc)(size_t bytes);

is expanded into

void * malloc(size_t bytes);

if TLSF_MALLOC_PREFIX is not defined

So, I think linker uses the malloc version defined into tlsf for printf, which was causing the crash (due to control structure being pointed to null).

defining the TLSF_MALLOC_PREFIX forces the linker to use correct malloc.

I used fresh copy of RIOT-OS and build the stock ccn-lite-relay example without any modification in Ubuntu 16.04.

5

Hi Nazmul!

Sorry for the poor explanation.

No need to excuse here. :slight_smile:

I have created four tap devices. But the image was crashing before running the ccn-lite-relay example.

I was just checking, because this can sometimes cause weird error messages.

Following stacktrace suggests that it crashed inside the printf function which tries to use the malloc defined in tlsf.

> #3 0x0805a26c in malloc (bytes=1024) > at /home/fadedreamz/riotos/RIOT/examples/ccn-lite-relay/bin/ > pkg/native/tlsf/src/tlsf-malloc.c:9 > ... > #8 0xf7e41d17 in vfprintf () from /lib32/libc.so.6 > #9 0xf7e48f66 in printf () from /lib32/libc.so.6 > #10 0x08049749 in usage_exit () > at /home/fadedreamz/riotos/RIOT/cpu/native/startup.c:198 > #11 0x08048eb4 in startup (argc=1, argv=0xffffd024) > But tlsf malloc will work only if is initialized previously with tlsf_create_with_pool() (as per my understanding).

Have you executed the elf by any chance directly like this: ./bin/native/ccn-lite-relay.elf or did you use `make term`?

In the first case, you're right, there's an issue that native will call printf() before tlsf got initialized and malloc() will fail. I will open an issue.

Following lines defined in tlsf-malloc.h

> #ifndef TLSF_MALLOC_PREFIX > # define TLSF_MALLOC_PREFIX > #endif > #define __TLSF_MALLOC_NAME(A, B) A ## B > #define _TLSF_MALLOC_NAME(A, B) __TLSF_MALLOC_NAME(A, B) > #define TLSF_MALLOC_NAME(NAME) _TLSF_MALLOC_NAME(TLSF_MALLOC_PREFIX, NAME) > ... > void *TLSF_MALLOC_NAME(malloc)(size_t bytes); > is expanded into

> void * malloc(size_t bytes); > if TLSF_MALLOC_PREFIX is not defined

So, I think linker uses the malloc version defined into tlsf for printf, which was causing the crash (due to control structure being pointed to null).

defining the TLSF_MALLOC_PREFIX forces the linker to use correct malloc.

But if you don't want to use tlsf, you can simple remove it from the Makefile. (But note that it won't work on most real devices then, because `free()` is not implemented on most MCUs currently. (To be accurate: free() is available, but sbrk() with negative values is not handled correctly.))

Cheers, Oleg

6

Hi Oleg,

Have you executed the elf by any chance directly like this: ./bin/native/ccn-lite-relay.elf or did you use make term?

I have directly executed the elf with following command

./bin/native/ccn-lite-relay.elf tap0

But if you don’t want to use tlsf, you can simple remove it from the Makefile. (But note that it won’t work on most real devices then, because free() is not implemented on most MCUs currently. (To be accurate: free() is available, but sbrk() with negative values is not handled correctly.))

My plan is to run the RIOT on MCU, but for now I am running it in native to explore RIOT. I currently have a telosb (msp430) and an arduino-uno. I was not able to run RIOT os in telosb and was able to run RIOT on arduino-uno. But I think arduino-uno is a little less powerful for networking stuff and it is still a WIP, so I am planning to buy arduino-due.

So, as far as your suggestion and my understanding, I will use the RIOT with tlsf when flashing it to MCU.

Thank you again for your valuable suggestions.