=================================================================
==2920138==ERROR: AddressSanitizer: invalid-pointer-pair: 0x603000000130 0x000000000000
#0 0x5602d3c6a89d in qsort stdlib/lib_qsort.c:180
#1 0x5602d3c28928 in romfs_cachenode romfs/fs_romfsutil.c:503
#2 0x5602d3c2854d in romfs_cachenode romfs/fs_romfsutil.c:486
#3 0x5602d3c2b056 in romfs_fsconfigure romfs/fs_romfsutil.c:777
#4 0x5602d3c24856 in romfs_bind romfs/fs_romfs.c:1111
#5 0x5602d3bf5179 in nx_mount mount/fs_mount.c:427
#6 0x5602d3bf5796 in mount mount/fs_mount.c:539
#7 0x5602d3bc1154 in nsh_romfsetc apps/nshlib/nsh_romfsetc.c:110
#8 0x5602d3b8f38d in nsh_initialize apps/nshlib/nsh_init.c:127
#9 0x5602d3b8f2b7 in nsh_main apps/system/nsh/nsh_main.c:69
#10 0x5602d3b7a3a6 in nxtask_startup sched/task_startup.c:70
#11 0x5602d3b5de89 in nxtask_start task/task_start.c:134
0x603000000130 is located 0 bytes inside of 32-byte region [0x603000000130,0x603000000150)
allocated by thread T0 here:
#0 0x7fcdac74793c in __interceptor_posix_memalign ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:226
#1 0x5602d3c9024e in host_memalign sim/posix/sim_hostmemory.c:180
#2 0x5602d3c907d2 in host_realloc sim/posix/sim_hostmemory.c:222
#3 0x5602d3b8aaff in mm_realloc sim/sim_heap.c:262
#4 0x5602d3b87a6a in realloc umm_heap/umm_realloc.c:91
#5 0x5602d3c280c4 in romfs_cachenode romfs/fs_romfsutil.c:466
#6 0x5602d3c2854d in romfs_cachenode romfs/fs_romfsutil.c:486
#7 0x5602d3c2b056 in romfs_fsconfigure romfs/fs_romfsutil.c:777
#8 0x5602d3c24856 in romfs_bind romfs/fs_romfs.c:1111
#9 0x5602d3bf5179 in nx_mount mount/fs_mount.c:427
#10 0x5602d3bf5796 in mount mount/fs_mount.c:539
#11 0x5602d3bc1154 in nsh_romfsetc apps/nshlib/nsh_romfsetc.c:110
#12 0x5602d3b8f38d in nsh_initialize apps/nshlib/nsh_init.c:127
#13 0x5602d3b8f2b7 in nsh_main apps/system/nsh/nsh_main.c:69
#14 0x5602d3b7a3a6 in nxtask_startup sched/task_startup.c:70
#15 0x5602d3b5de89 in nxtask_start task/task_start.c:134
Address 0x000000000000 is a wild pointer.
SUMMARY: AddressSanitizer: invalid-pointer-pair stdlib/lib_qsort.c:180 in qsort
==2920138==ABORTING
Aborted (core dumped)
Signed-off-by: chao an <anchao@xiaomi.com>
in SMP, signal processing cannot be nested, we use xcp.sigdeliver to identify whether there is currently a signal being processed, but this state does not match the actual situation
One possible scenario is that signal processing has already been completed, but an interrupt occurs, resulting in xcp.sigdeliver not being correctly set to NULL,
At this point, a new signal arrives, which can only be placed in the queue and cannot be processed immediately
Our solution is that signal processing and signal complete status are set in the same critical section, which can ensure status synchronization
Signed-off-by: hujun5 <hujun5@xiaomi.com>
The third-party library we are porting will send and receive ICMPV6 messages
(router_advert / router_solicit / neighbor_advert / neighbor_solicit etc.)
from the user mode itself, so we added the SOCK_RAW related implementation
for ICMPV6.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
In the interrupt context, we should first save the interrupt context and modify the interrupt register
to execute the signal processing program immediately after exiting the current interrupt
Signed-off-by: hujun5 <hujun5@xiaomi.com>
This bluetooth stack remains in an inconsistent state when
the bluetooth HCI module is removed. This change adds a
bt_netdev_unregister function that can be used to clean up
after a module is removed. Some global variables are also
set to their default values.
Some time nuttx will receive SIGSEGV while executing the function:
| Thread 1 "nuttx" received signal SIGSEGV, Segmentation fault.
| 0xf7bab4a0 in __sanitizer::common_flags_dont_use () from /lib/i386-linux-gnu/libasan.so.6
| The program being debugged was signaled while in a function called from GDB.
| GDB has restored the context to what it was before the call.
| Evaluation of the expression containing the function
| (up_check_tcbstack) will be abandoned.
Signed-off-by: chao an <anchao@xiaomi.com>
since iob offload, ipvx_dev_forward will remove d_iob, if there are multiple
devices, d_iob will be NULL when dev_forward is entered second time. and the
device that receives the packet cannot process the packet after forwarding it
so the iob copy is added.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
- Before IOB offload, srcaddr / src_addr_size / ifindex are written into
IOB by iob_trycopyin, so io_pktlen > 0 is always true, this check is
correct at that time. (It won't fail with zero-length UDP datagram.)
- After IOB offload, srcaddr / src_addr_size / ifindex are written into
offset 0, without increasing io_pktlen. So this check will fail with
zero-length UDP datagram now.
- We need to support zero-length UDP datagram and this check is
unnecessary at this point.
- https://stackoverflow.com/questions/5307031/how-to-detect-receipt-of-a-0-length-udp-datagram
- https://github.com/apache/nuttx/blob/nuttx-12.1.0/net/udp/udp_callback.c#L214
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
1. Get the value of sp from dump regs when an exception occurs,
to avoid getting the value of fp from up_getsp and causing
incomplete stack printing.
2. Determine which stack the value belongs to based on the value
of SP to avoid false reports of stack overflow
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Adds support for the ES8311 codec on the ESP32-S2-Kaluga-1 board. This commit also adds basic configurations for testing and updates the board documentation.
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Follow the change: https://github.com/apache/nuttx/pull/9151,
if MM_CUSTOMIZE_MANAGER is enabled, heap memory manager in host is used,
for example in sim:asan build.
malloc and related allocation APIs will fall back to host_realloc,
do not free memory of zero-length reallocation. So memory allocations
return valid pointer when request zero size in all sim build.
call stack:
malloc() (mm/umm_heap/umm_malloc.c)
mm_malloc() (arch/sim/src/sim/sim_heap.c)
mm_realloc() (arch/sim/src/sim/sim_heap.c)
host_realloc() (arch/sim/src/sim/posix/sim_hostmemory.c)
host_memalign() (arch/sim/src/sim/posix/sim_hostmemory.c)
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
The fast-unwind implementation of leak-sanitizer will obtain the
current stack top/bottom and frame address(Stack Pointer) for
backtrace calculation:
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13/libsanitizer/lsan/lsan.cpp#L39-L42
Since the scheduling mechanism of NuttX sim is coroutine
(setjmp/longjmp), if the Stack Pointer is switched, the fast-unwind
will unable to get the available address, so the memory leaks on the
system/application side that cannot be caught normally. This PR will
disable fast-unwind by default to avoid unwind failure.
Signed-off-by: chao an <anchao@xiaomi.com>
If TCP_FIN is received before the user calls accept, the later accept will
report an error, then the previously received data cannot be read.
operation flow:
tcp_server_listen -> tcp_client_connect -> tcp_client_send ->
tcp_client_close -> tcp_server_accept(fix this error) -> tcp_server_recv
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Set the Default CPU bits. The way to use the unset CPU is to call the
sched_setaffinity function to bind a task to the CPU. bit0 means CPU0.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
adapts to third-party code compilation. in the process of porting ConnMan,
we encounter some situations where the structure is not defined, or the
returned data types do not match the expectations. Refer to the common
implementation of other systems and add relevant definitions.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
