Question w.r.t. crash inside select call from libbsd.

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Jan 31 06:30:43 UTC 2023



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 at entry=9, error=<optimized out>, 
> error at entry=604203640) at ../../../cpukit/score/cpu/arm/cpu.c:203
> 203       while ( true ) {
> (gdb) where
> #0  _CPU_Fatal_halt (source=source at entry=9, error=<optimized out>, 
> error at entry=604203640)
>      at ../../../cpukit/score/cpu/arm/cpu.c:203
> #1  0x080fb9b4 in _Terminate 
> (the_source=the_source at 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 at entry=0x0, 
> flags=flags at 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 at entry=0xd000da30,
>      writefds=writefds at entry=0xd000da38, errorfds=errorfds at entry=0x0,
>      _bsd_timeout=_bsd_timeout at 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 at entry=0x0, 
> flags=flags at 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.huber at 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/


More information about the devel mailing list