Thanks for the information. The issue is being observed within a single threaded camkes component, therefore I’m assuming that thread safety of the muslc functions it not relevant here.
In an attempt to investigate memory corruption I have run the software under valgrind on my host machine, which does not highlight any issues. Obviously the interaction with the actual devices was needed to be simulated to perform this run on the host however I believe that all of the same memory allocation and access routines should have been performed. This suggests that memory corruption may not be the cause. One potentially interesting observation is that if I replace all calls to memalign with the equivalent calls to malloc (noting that the alignment appears to be for performance rather than functional correctness reasons) I no longer have overlapping memory regions allocated and the code functions as expected. Thanks, Stephen > On 16 Mar 2022, at 23:23, Kent Mcleod <kent.mcleo...@gmail.com> wrote: > > ***This mail has been sent by an external source*** > > On Thu, Mar 17, 2022 at 8:26 AM WILLIAMS Stephen via Devel > <devel@sel4.systems> wrote: >> >> Hi, >> >> I’m currently working on a project porting drivers from U-Boot to seL4 and >> have run into an unexpected problem seemingly triggered by use of the >> memalign within the U-Boot drivers. >> >> What I am seeing is that calls to memalign from within my CAmkES component >> can return pointers to regions which overlap with those previously returned >> by malloc. Obviously this leads to the two allocated regions trampling over >> each other and resulting corruption of data. >> >> I’m at a complete loss to explain this behaviour and would be very grateful >> to receive any suggestions or pointers. >> > > Both malloc and memalign in camkes are provided by our fork of > libmuslc (https://github.com/sel4/musllibc/). Internally, memalign > calls malloc and so it seems like your issue can be reduced to > multiple calls to malloc are returning overlapping regions. This could > be for a couple reasons: > - Within the default camkes runtime, muslc functions such as malloc > aren't thread safe and so must be called from critical sections > guarded by a lock to avoid races. Many camkes components use a global > lock when performing operations that mutate state: > https://github.com/seL4/global-components/blob/master/components/TimeServer/src/time_server.c#L152, > or they don't use dynamic memory allocation after initialization (as > initialization is single threaded). This lack of thread safety is a > bit nasty and the runtime should do more to protect developers from > this, but currently I don't think it does. > - You have memory corruption somewhere else that's causing malloc's > bookkeeping structures to be corrupted. > > > >> Thanks for your help, >> Stephen >> This message contains information that may be privileged or confidential and >> is the property of the Capgemini Group. It is intended only for the person >> to whom it is addressed. If you are not the intended recipient, you are not >> authorized to read, print, retain, copy, disseminate, distribute, or use >> this message or any part thereof. If you receive this message in error, >> please notify the sender immediately and delete all copies of this message. >> _______________________________________________ >> Devel mailing list -- devel@sel4.systems >> To unsubscribe send an email to devel-leave@sel4.systems _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
