Re: RTEMS 5.1 pc686 BSP malloc_info problem?
Hello Alan, On 09/10/2020 22:35, Alan Cudmore wrote: After doing a lot of tracing through my application, it looks like malloc_info works fine before we start our cFS application, but it blocks after the cFS is initialized. This suggests some sort of memory corruption. I started by instrumenting our code to call malloc info during various stages of application initialization, and finally narrowed it down to the code where we create a RAM Disk and format it with RFS. (skipping a bunch of other malloc based troubleshooting.. ) After I followed the issue into the RFS init, I was able to narrow down the place where malloc_info stopped working to here: https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637 During the RFS format process. In this section of the code, the size variable is 0, meaning it will exit the for loop and then return from the function, but it increments the "search_map" variable and writes to memory through the pointer one more time before exiting the loop and function. It's at this point where malloc_info starts blocking. It seems to me that this if block should be skipped when size == 0. I tried that and the malloc_info issue seems to be fixed. Is this an RFS bug writing into other memory, or is this last write needed before the function updates? If this looks like a bug, should I write a ticket and provide a patch? you can check heap overwrites like this automatically if you enable RTEMS_DEBUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Need help debugging sp16.exe
Hello Richi, I suggested to enable your new scheduler implementation as the default to check if it is in line with the standard schedulers. I would first get some high level data. Select a BSP with good test results on a simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the tests and record the test data. Then enable the SMP EDF scheduler as the default, run the tests, record the data. Then enable your scheduler as the default, run the tests, record the data. Then get all tests which fail only with your scheduler. Do a high level analysis of all failing tests. Try to figure out a new scenario for the test smpstrongapa01. Do all the development with RTEMS_DEBUG enabled! Add _Assert() stuff to your scheduler. Check pre- and post-conditions of all operations. Check invariants. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
aarch64/a53_ilp32_qemu: implicit declaration of function 'truncl'
Hello Kinsey, the new aarch64/a53_ilp32_qemu produces a lot of warnings like this: ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning: implicit declaration of function 'truncl' [-Wimplicit-function-declaration] ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning: incompatible implicit declaration of built-in function 'truncl' Is this a known issue? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: aarch64/a53_ilp32_qemu: implicit declaration of function 'truncl'
On 10/10/2020 15:11, Sebastian Huber wrote: Hello Kinsey, the new aarch64/a53_ilp32_qemu produces a lot of warnings like this: ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning: implicit declaration of function 'truncl' [-Wimplicit-function-declaration] ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning: incompatible implicit declaration of built-in function 'truncl' Is this a known issue? There is also this warning: cpukit/libmisc/stackchk/check.c:455:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] This is probably an error. Could you please fix the warnings specific to the new BSPs. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Need help debugging sp16.exe
Hi Mr. Huber, Thanks for checking in. I suggested to enable your new scheduler implementation as the default > to check if it is in line with the standard schedulers. I would first > get some high level data. Select a BSP with good test results on a > simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the > tests and record the test data. Then enable the SMP EDF scheduler as the > default, run the tests, record the data. Then enable your scheduler as > the default, run the tests, record the data. Then get all tests which > fail only with your scheduler. Yes, this is something I've already done based on your previous suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version) as the default scheduler for both sp and SMP and ran the test (on both sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and SMP and ran the test and compared it with the master's strong apa result. The following (extra) tests failed: sp02.exe sp16.exe sp30.exe sp31.exe sp37.exe sp42.exe spfatal29.exe tm24.exe Do a high level analysis of all failing tests. Try to figure out a new scenario for the test smpstrongapa01. Okay, I would look into this. This is a great suggestion, thanks! Do all the development with RTEMS_DEBUG enabled! > Add _Assert() stuff to your scheduler. Check pre- and post-conditions of > all operations. Check invariants. How do I check postconditions? Using _Assert() or by manually debugging each function call? On Sat, Oct 10, 2020 at 6:09 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Richi, > > I suggested to enable your new scheduler implementation as the default > to check if it is in line with the standard schedulers. I would first > get some high level data. Select a BSP with good test results on a > simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the > tests and record the test data. Then enable the SMP EDF scheduler as the > default, run the tests, record the data. Then enable your scheduler as > the default, run the tests, record the data. Then get all tests which > fail only with your scheduler. Do a high level analysis of all failing > tests. Try to figure out a new scenario for the test smpstrongapa01. > > Do all the development with RTEMS_DEBUG enabled! > > Add _Assert() stuff to your scheduler. Check pre- and post-conditions of > all operations. Check invariants. > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: aarch64/a53_ilp32_qemu: implicit declaration of function 'truncl'
On Sat, Oct 10, 2020 at 8:13 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 10/10/2020 15:11, Sebastian Huber wrote: > > > Hello Kinsey, > > > > the new aarch64/a53_ilp32_qemu produces a lot of warnings like this: > > > > ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning: > > implicit declaration of function 'truncl' > > [-Wimplicit-function-declaration] > > ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning: > > incompatible implicit declaration of built-in function 'truncl' > > > > Is this a known issue? > It is likely that this is because some/many architectures do not have long double support in newlib. Or have a true long double type. This will require a newlib discussion. > > There is also this warning: > > cpukit/libmisc/stackchk/check.c:455:5: warning: cast to pointer from > integer of different size [-Wint-to-pointer-cast] > > This is probably an error. Could you please fix the warnings specific to > the new BSPs. > This looks like code being sloppy that isn't the fault of this BSP. It is just one where sizeof(int) != sizeof(void *). Kinsey.. likely solution is to replace the cast/type with intptr_t or uintptr_t. --joel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Need help debugging sp16.exe
On Sat, Oct 10, 2020, 10:47 AM Richi Dubey wrote: > Hi Mr. Huber, > > Thanks for checking in. > > I suggested to enable your new scheduler implementation as the default >> to check if it is in line with the standard schedulers. I would first >> get some high level data. Select a BSP with good test results on a >> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the >> tests and record the test data. Then enable the SMP EDF scheduler as the >> default, run the tests, record the data. Then enable your scheduler as >> the default, run the tests, record the data. Then get all tests which >> fail only with your scheduler. > > Yes, this is something I've already done based on your previous > suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version) > as the default scheduler for both sp and SMP and ran the test (on both > sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set > SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and > SMP and ran the test and compared it with the master's strong apa result. > The following (extra) tests failed: > > sp02.exe > sp16.exe > sp30.exe > sp31.exe > sp37.exe > sp42.exe > spfatal29.exe > tm24.exe > > Do a high level analysis of all failing > > tests. Try to figure out a new scenario for the test smpstrongapa01. > > Okay, I would look into this. This is a great suggestion, thanks! > > > Do all the development with RTEMS_DEBUG enabled! >> Add _Assert() stuff to your scheduler. Check pre- and post-conditions of >> all operations. Check invariants. > > How do I check postconditions? Using _Assert() or by manually debugging > each function call? > There are existing checks scattered throughout the source. Do any need to be in your scheduler? Random thoughts: + Looks like the bsp has fast idle on but that should not impact anything. + Run this with the another scheduler and see if you can identify when that scheduler makes the decision you are missing. There has to be one of the scheduler hooks that is making a different decision. Run the test side by side with two different schedulers. Alternate forward motion in the two and compare the behaviour. + Adding trading might help but is probably more trouble to set up than just comparing good and bad schedulers in parallel. + Look at what every failing test is doing. May be a common issue and one is easier to debug --joel > > > > On Sat, Oct 10, 2020 at 6:09 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello Richi, >> >> I suggested to enable your new scheduler implementation as the default >> to check if it is in line with the standard schedulers. I would first >> get some high level data. Select a BSP with good test results on a >> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the >> tests and record the test data. Then enable the SMP EDF scheduler as the >> default, run the tests, record the data. Then enable your scheduler as >> the default, run the tests, record the data. Then get all tests which >> fail only with your scheduler. Do a high level analysis of all failing >> tests. Try to figure out a new scenario for the test smpstrongapa01. >> >> Do all the development with RTEMS_DEBUG enabled! >> >> Add _Assert() stuff to your scheduler. Check pre- and post-conditions of >> all operations. Check invariants. >> >> ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libblock: Fix string truncation warning
On Sat, Oct 10, 2020, 8:16 AM Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:bc7ac71f8aaaff0c73469246c526741ec5b181ed
> Changeset:
> http://git.rtems.org/rtems/commit/?id=bc7ac71f8aaaff0c73469246c526741ec5b181ed
>
> Author:Frank Kühndel
> Date: Mon Oct 5 16:37:23 2020 +0200
>
> libblock: Fix string truncation warning
>
> This patch does not only fix the compiler warning below. memcpy() is the
> better function at this place as the terminating NUL character is never
> copied here. Instead more characters will be appended to the
> 'logical_disk_name' later on.
>
> ../../../cpukit/libblock/src/bdpart-register.c:41:5:
> warning: 'strncpy' output truncated before terminating nul copying
> as many bytes from a string as its length [-Wstringop-truncation]
>
> ---
>
> cpukit/libblock/src/bdpart-register.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libblock/src/bdpart-register.c
> b/cpukit/libblock/src/bdpart-register.c
> index 9956e61..8a1de61 100644
> --- a/cpukit/libblock/src/bdpart-register.c
> +++ b/cpukit/libblock/src/bdpart-register.c
> @@ -38,7 +38,7 @@ static char *create_logical_disk_name( const char
> *disk_name, char **marker)
>char *logical_disk_name = malloc( disk_name_size +
> RTEMS_BDPART_NUMBER_SIZE);
>
>if (logical_disk_name != NULL) {
> -strncpy( logical_disk_name, disk_name, disk_name_size);
> +memcpy( logical_disk_name, disk_name, disk_name_size);
>
Could we have a comment in the code explaining why this is safe?
Please do that for everywhere memcpy is being inserted. Next time someone
looks at this code, it will not be obvious.
*marker = logical_disk_name + disk_name_size;
>}
>
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
