On 30.01.23 23:33, Karel Gardas wrote:
I'm debugging crash inside the select call from libbsd library. The code
comes from few days old RTEMS and few days old libbsd trees. My naive
configuration for the RTEMS is below.
The crash backtrace is:
_CPU_Fatal_halt (source=source@entry=9, error=<optimized out>,
error@entry=604203640) at ../../../cpukit/score/cpu/arm/cpu.c:203
203 while ( true ) {
(gdb) where
#0 _CPU_Fatal_halt (source=source@entry=9, error=<optimized out>,
error@entry=604203640)
at ../../../cpukit/score/cpu/arm/cpu.c:203
#1 0x080fb9b4 in _Terminate
(the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,
the_error=604203640) at ../../../cpukit/score/src/interr.c:58
#2 0x08104e56 in rtems_fatal (fatal_code=<optimized out>,
fatal_source=RTEMS_FATAL_SOURCE_EXCEPTION) at
../../../cpukit/include/rtems/fatal.h:160
#3 _ARM_Exception_default (frame=<optimized out>)
at ../../../cpukit/score/cpu/arm/arm-exception-default.c:37
#4 <signal handler called>
#5 _bsd_uma_zalloc_arg (zone=0x9, udata=udata@entry=0x0,
flags=flags@entry=2)
at ../../freebsd/sys/vm/uma_core.c:2624
#6 0x0807c180 in uma_zalloc (flags=2, zone=<optimized out>)
at ../../freebsd/sys/vm/uma.h:356
#7 0x080b51b8 in rtems_bsd_thread_create (thread=0xd0003048
<_RTEMS_tasks_Objects>,
wait=<optimized out>) at ../../rtemsbsd/rtems/rtems-kernel-thread.c:93
#8 0x080b5250 in rtems_bsd_get_curthread (wait=0)
at ../../rtemsbsd/rtems/rtems-kernel-thread.c:116
#9 0x0807e59a in select (nfds=1, readfds=readfds@entry=0xd000da30,
writefds=writefds@entry=0xd000da38, errorfds=errorfds@entry=0x0,
_bsd_timeout=_bsd_timeout@entry=0x0) at
../../freebsd/sys/kern/sys_generic.c:1170
When I put breakpoint here and there I found strange fact that zone =
0x0 in frame #5 and not 0x9:
Breakpoint 1, _bsd_uma_zalloc_arg (zone=0x0, udata=udata@entry=0x0,
flags=flags@entry=2) at ../../freebsd/sys/vm/uma_core.c:2562
2562 {
(gdb) next
2680 bucket_free(zone, bucket, udata);
(gdb) next
2622 critical_enter();
(gdb) next
196 cpu_self->thread_dispatch_disable_level = disable_level + 1;
(gdb) next
2622 critical_enter();
(gdb) next
2624 cache = &zone->uz_cpu[cpu];
(gdb) next
_ARMV7M_Exception_default () at
../../../cpukit/score/cpu/arm/armv7m-exception-default.c:51
51 __asm__ volatile (
(gdb)
so with zone being NULL the crash is expected here. However I'm still
curious if this is libbsd issue or my issue with naive configuration?
Did you use select() before libbsd is initialized? Do you have more than
64 file descriptors? In this case the fd set type is too small and you
have a stack overflow. Which branch of libbsd do you use? Maybe try out
the other branch as well.
The platform is STM32H757i-eval board, the linking is using flash_sdram
configuration. The board provides 16MB of SDRAM so hopefully this should
be enough even for libbsd... The board configuration is more or less
default except disabling of MPU alignment. If I don't do this, my
testing app (quickjs) would not fit 2MB of CPU flash. When MPU alignment
is disabled, I'm on 1.4MB of flash consumption (before disabling 2.3MB)
From the 16MiB you already waste 4MiB for unused features if you use
the latest 6-freebsd-12 branch of libbsd.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
