<div dir="ltr"><div>Hi</div><div><br></div><div>Jennifer has been working on a network driver and had some odd failures in libbsd. I suggested turning on rtems debug and that caused a number of libbsd tests to fail. She pointed me in the right direction and I found that the following patch resulted in the stack address being freed including an "align up" adjustment in some cases. This looks to be from something Sebastian committed early this month.<br></div><div><br></div><div><a href="https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1">https://git.rtems.org/rtems/commit/cpukit/score/src/threadinitialize.c?id=524839568d8df72bb3d62d64cb1b927bc8dbbbf1</a></div><div><br></div><div>I am not sure how that wasn't noticed since about 40 tests were failing on psim due to that.</div><div><br></div><div>I have attached a straightforward patch to address this issue.</div><div><br></div><div>Unfortunately, even with this patch and using the RTEMS hash just before this patch program01 and syscalls01 in libbsd fail. I debugged into syscalls01 enough to find that there are 7 blocks at the beginning of one of the tests and 5 after. There is another leak and I tried using the has before Sebastian's change above but it is still leaking. <br></div><div><br></div><div>On top of that, psxconfig01 and spconfig01 are failing on psim which appears to be independent. I am not sure what these are but it is something about minimum stack size not matching. Since I was looking for stack memory issues, I started to investigate these but decided they were not allocation/free issues.</div><div><br></div><div>Help really appreciated in addressing these leaks.</div><div><br></div><div>Thanks.</div><div><br></div><div>--joel<br></div><div><br></div></div>