Podling Nuttx Report Reminder - July 2020
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 15 July 2020. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, July 01). Please submit your report with sufficient time to allow the Incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Candidate names should not be made public before people are actually elected, so please do not include the names of potential committers or PPMC members in your report. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. * How does the podling rate their own maturity. This should be appended to the Incubator Wiki page at: https://cwiki.apache.org/confluence/display/INCUBATOR/July2020 Note: This is manually populated. You may need to wait a little before this page is created from a template. Note: The format of the report has changed to use markdown. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
On 6/24/2020 12:03 PM, Brennan Ashton wrote: On Wed, Jun 24, 2020, 10:56 AM Gregory Nutt wrote My concern is that if we sweep things under the carpet now and continue with the 9.1 eyes shut as if there is nothing wrong, we will continue to degrade the OS footprint over time. It requires aggressive action to control the binary size! The PR-induced bloat due to the NSH 'date' command configuration was added between 9.0 and 9.1. That was apps/ commit 4adb83c754500cfebe4c24a498eb4139e3ff8866, dated April 7. It is on master but not in the releases/9.0 branch. Apparently it just missed the cut-off for 9.0 but is included in 9.1. The CONFIG_TIME_EXTENDED change is, I believe, pre-9.0 and so does not have as strong an argument in the current context. But I think any size-related fixes that do not introduce other issues or cause loss of functionality are good game for reversion. We need to stop the practice of changing settings by changing their default values. That has ramifications that are too extensive and too unpredictable! And we need to stop removing size reducing configuration options without strong argument. In the case of the CONFIG_TIME_EXTENDED, the argument is that the default selection makes the structure non-compliant with POSIX requirements. That is a reasonable argument. There is no good argument of any kind for the NSH 'date' command change, however. That change should certainly be removed. Ok let's go ahead and plan to do an RC1. What I ask is that people really try to get some testing in. So we can address this prior to cutting releases. That 9.1 branch that this was made off of has been static besides the release notes for almost 10 days. It took calling a vote to find this issue. I do appreciate the testing that people have done! Can we plan to cut RC1 on Friday or do people want to wait longer? After Monday I'll be likely somewhat unavailable for a few days so I may be slower to respond to moving the release process forward. --Brennan I created the PR #307 to restore the behavior to the same as the 9.0 release. This should eliminate the size increase noted by Alan and Brennan.
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
On Wed, Jun 24, 2020, 10:56 AM Gregory Nutt wrote > > My concern is that if we sweep things under the carpet now and continue > with the 9.1 eyes shut as if there is nothing wrong, we will continue to > degrade the OS footprint over time. It requires aggressive action to > control the binary size! > > The PR-induced bloat due to the NSH 'date' command configuration was > added between 9.0 and 9.1. That was apps/ commit > 4adb83c754500cfebe4c24a498eb4139e3ff8866, dated April 7. It is on > master but not in the releases/9.0 branch. Apparently it just missed > the cut-off for 9.0 but is included in 9.1. > > The CONFIG_TIME_EXTENDED change is, I believe, pre-9.0 and so does not > have as strong an argument in the current context. But I think any > size-related fixes that do not introduce other issues or cause loss of > functionality are good game for reversion. > > We need to stop the practice of changing settings by changing their > default values. That has ramifications that are too extensive and too > unpredictable! And we need to stop removing size reducing configuration > options without strong argument. In the case of the > CONFIG_TIME_EXTENDED, the argument is that the default selection makes > the structure non-compliant with POSIX requirements. That is a > reasonable argument. There is no good argument of any kind for the NSH > 'date' command change, however. That change should certainly be removed. > Ok let's go ahead and plan to do an RC1. What I ask is that people really try to get some testing in. So we can address this prior to cutting releases. That 9.1 branch that this was made off of has been static besides the release notes for almost 10 days. It took calling a vote to find this issue. I do appreciate the testing that people have done! Can we plan to cut RC1 on Friday or do people want to wait longer? After Monday I'll be likely somewhat unavailable for a few days so I may be slower to respond to moving the release process forward. --Brennan
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
I am not sure if this was in the last release, but there is a secondary level change to date that the CONFIG_TIME_EXTENDED was removed and made permanently enabled. Things like CONFIG_TIME_EXTENDED were there to scale down for resource constrained configurations. I for one would like to preserve the "small" of NuttX. So some of these "clean up" PR's should have a little more eyes on them. My concern is that if we sweep things under the carpet now and continue with the 9.1 eyes shut as if there is nothing wrong, we will continue to degrade the OS footprint over time. It requires aggressive action to control the binary size! The PR-induced bloat due to the NSH 'date' command configuration was added between 9.0 and 9.1. That was apps/ commit 4adb83c754500cfebe4c24a498eb4139e3ff8866, dated April 7. It is on master but not in the releases/9.0 branch. Apparently it just missed the cut-off for 9.0 but is included in 9.1. The CONFIG_TIME_EXTENDED change is, I believe, pre-9.0 and so does not have as strong an argument in the current context. But I think any size-related fixes that do not introduce other issues or cause loss of functionality are good game for reversion. We need to stop the practice of changing settings by changing their default values. That has ramifications that are too extensive and too unpredictable! And we need to stop removing size reducing configuration options without strong argument. In the case of the CONFIG_TIME_EXTENDED, the argument is that the default selection makes the structure non-compliant with POSIX requirements. That is a reasonable argument. There is no good argument of any kind for the NSH 'date' command change, however. That change should certainly be removed.
RE: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
I am not sure if this was in the last release, but there is a secondary level change to date that the CONFIG_TIME_EXTENDED was removed and made permanently enabled. Things like CONFIG_TIME_EXTENDED were there to scale down for resource constrained configurations. I for one would like to preserve the "small" of NuttX. So some of these "clean up" PR's should have a little more eyes on them. -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Wednesday, June 24, 2020 6:26 AM To: dev@nuttx.apache.org Subject: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release > Started looking and there are some changes in the diff in the > generated config.h as can be seen here > One change is the date command is no longer disabled by default. This > accounts for 2304 bytes, leaving only 800 byte change. > I'm not sure if changing the default was expected, but I dont think > this should block the release. Changing the default is not the problem. The problem is when the default configuration value is changed, the all configurations effected by that change in the default setting should be updated so that they are not effected. That is, so the net result is no change. That was not done and that is an error. In this case, the NSH 'date' command used to default to 'disabled' UNLESS an RTC was supported, then the default is 'enabled'. There error is, that that the 'date' command should have also been explicitly disabled in ALL NSH configurations that do not have the RTC enabled. That has a negative user impact and would think that correcting that is more important than meeting an artificial release deadline. > The TLS changes are harder for me to judge and the netdb change I > think just changes ram usage. I don't believe that the TLS changes added any significant size. It replaces one small, simple implementation with another small, simple implementation. It is hard to envision how this would cause any noticeable size increase. But perhaps. Another thing that I noted in Alin's configuration comparison is that the variadic version of the ioctl() interface is no longer optional. That I expect will add a couple hundred bytes to the size of every configuration. The main cause of the size increase is the default 'date' command setting. Not only does that enabled the NSH data command but draws all of the time computation logic into the build. This will probably break many of the more resource constrained configurations.
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
On 6/24/2020 9:20 AM, Alan Carvalho de Assis wrote: Hi Greg, On 6/24/20, Gregory Nutt wrote: Changing the default is not the problem. The problem is when the default configuration value is changed, the all configurations effected by that change in the default setting should be updated so that they are not effected. That is, so the net result is no change. That was not done and that is an error. In this case, the NSH 'date' command used to default to 'disabled' UNLESS an RTC was supported, then the default is 'enabled'. There error is, that that the 'date' command should have also been explicitly disabled in ALL NSH configurations that do not have the RTC enabled. That has a negative user impact and would think that correcting that is more important than meeting an artificial release deadline. The TLS changes are harder for me to judge and the netdb change I think just changes ram usage. I don't believe that the TLS changes added any significant size. It replaces one small, simple implementation with another small, simple implementation. It is hard to envision how this would cause any noticeable size increase. But perhaps. Another thing that I noted in Alin's configuration comparison is that the variadic version of the ioctl() interface is no longer optional. That I expect will add a couple hundred bytes to the size of every configuration. The main cause of the size increase is the default 'date' command setting. Not only does that enabled the NSH data command but draws all of the time computation logic into the build. This will probably break many of the more resource constrained configurations. Currently it appears to depend on !CONFIG_DEFAULT_SMALL only: config NSH_DISABLE_DATE bool "Disable date" default y if DEFAULT_SMALL default n if !DEFAULT_SMALL Shouldn't it depends on !CONFIG_DEFAULT_SMALL && CONFIG_RTC ? BR, Alan I have looked at this too. I think that the correct change is to revert commit 4adb83c754500cfebe4c24a498eb4139e3ff8866: commit 4adb83c754500cfebe4c24a498eb4139e3ff8866 Author: chao.an Date: Tue Apr 7 16:33:05 2020 +0800 nshlib: remove the dependency of date on RTC Change-Id: I98bd022fdc901ecb4e2e45a0faf779d83c260844 Signed-off-by: chao.an diff --git a/nshlib/Kconfig b/nshlib/Kconfig index abc96d69..a6aa7906 100644 --- a/nshlib/Kconfig +++ b/nshlib/Kconfig @@ -259,8 +259,8 @@ config NSH_DISABLE_CMP config NSH_DISABLE_DATE bool "Disable date" - default n if RTC - default y if !RTC + default y if DEFAULT_SMALL + default n if !DEFAULT_SMALL config NSH_DISABLE_DD bool "Disable dd"
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
Yes, it should be nice to have bloaty integrated on CI system to ring an alarm when something like this happen. If it works as advertised, then this would be a good idea. Some gradual code growth is natural natural due to the nature of the NuttX roadmap -- to be a complete, small POSIX OS for embedded systems. But large step changes in size must be accounted for and avoided whenever possible. In my opinion, a release that includes such a large step is code size is a bad release. Catching them as soon as they are introduced would be a good thing.
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
Hi Greg, On 6/24/20, Gregory Nutt wrote: > > Changing the default is not the problem. The problem is when the > default configuration value is changed, the all configurations effected > by that change in the default setting should be updated so that they are > not effected. That is, so the net result is no change. That was not > done and that is an error. > > In this case, the NSH 'date' command used to default to 'disabled' > UNLESS an RTC was supported, then the default is 'enabled'. There error > is, that that the 'date' command should have also been explicitly > disabled in ALL NSH configurations that do not have the RTC enabled. > > That has a negative user impact and would think that correcting that is > more important than meeting an artificial release deadline. > >> The TLS changes are harder for me to judge and the netdb change I >> think just changes ram usage. > > I don't believe that the TLS changes added any significant size. It > replaces one small, simple implementation with another small, simple > implementation. It is hard to envision how this would cause any > noticeable size increase. But perhaps. > > Another thing that I noted in Alin's configuration comparison is that > the variadic version of the ioctl() interface is no longer optional. > That I expect will add a couple hundred bytes to the size of every > configuration. > > The main cause of the size increase is the default 'date' command > setting. Not only does that enabled the NSH data command but draws all > of the time computation logic into the build. This will probably break > many of the more resource constrained configurations. > Currently it appears to depend on !CONFIG_DEFAULT_SMALL only: config NSH_DISABLE_DATE bool "Disable date" default y if DEFAULT_SMALL default n if !DEFAULT_SMALL Shouldn't it depends on !CONFIG_DEFAULT_SMALL && CONFIG_RTC ? BR, Alan
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
Hi David,
Thank you for this suggestion!
Yes, it should be nice to have bloaty integrated on CI system to ring
an alarm when something like this happen.
BR,
Alan
On 6/24/20, David Sidrane wrote:
> This is a cool tool.
>
> https://github.com/google/bloaty
>
> Here is a set of ways to use it.
> https://github.com/PX4/Firmware/blob/4e7dedede79872401f50c733bd74e5ddf1fa41f1/cmake/bloaty.cmake
> (please ignore the cmake...)
>
> This is the one that can be used to see the deltas, in our case from mater
> to the PR. But it is easy to compare to a release branch.
>
> # bloaty compare with last master build
> add_custom_target(bloaty_compare_master
> COMMAND wget -c -N --no-verbose
> https://s3.amazonaws.com/px4-travis/Firmware/master/${PX4_BOARD_VENDOR}_${PX4_BOARD_MODEL}_${PX4_BOARD_LABEL}.elf
> -
> O master.elf
> COMMAND ${BLOATY_PROGRAM} -d symbols ${BLOATY_OPTS}
> $ --
> master.elf
> DEPENDS px4
> WORKING_DIRECTORY ${PX4_BINARY_DIR}
> VERBATIM
> USES_TERMINAL
> )
>
>
> -Original Message-
> From: Brennan Ashton [mailto:bash...@brennanashton.com]
> Sent: Tuesday, June 23, 2020 10:53 PM
> To: dev@nuttx.apache.org
> Subject: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
>
> Greg and Alan,
> Started looking and there are some changes in the diff in the
> generated config.h as can be seen here
> One change is the date command is no longer disabled by default. This
> accounts for 2304 bytes, leaving only 800 byte change.
> I'm not sure if changing the default was expected, but I dont think
> this should block the release.
> The TLS changes are harder for me to judge and the netdb change I
> think just changes ram usage. I can dig more, if you think it is
> necessary, I agree that we should keep and eye on the size though. I
> had some thoughts on keeping the build artifacts around so we could
> track and test things easier (hard to go back in time with both repos
> changing).
>
> 9.1.0
>text databssdechexfilename
> 71731104 2476 74311 12247./9.1/nuttx
>
> 9.1.0 (with date disabled)
>text databssdechexfilename
> 69427104 2476 72007 11947nuttx
>
>
> --- /home/bashton/nuttx/apache/sizetest/9.0/config.h
> +++ /home/bashton/nuttx/apache/sizetest/9.1/config.h
> @@ -135,7 +135,6 @@
> #define CONFIG_TASK_NAME_SIZE 31
> #define CONFIG_MAX_TASKS 16
> #define CONFIG_SCHED_WAITPID 1
> -#define CONFIG_NPTHREAD_KEYS 4
> #define CONFIG_PTHREAD_MUTEX_ROBUST 1
> #define CONFIG_DEV_CONSOLE 1
> #define CONFIG_SDCLONE_DISABLE 1
> @@ -196,15 +195,14 @@
> #define CONFIG_POSIX_SPAWN_PROXY_STACKSIZE 1024
> #define CONFIG_TASK_SPAWN_DEFAULT_STACKSIZE 2048
> #define CONFIG_LIB_HOSTNAME ""
> -#define CONFIG_ARCH_HAVE_TLS 1
> -#define CONFIG_NETDB_BUFSIZE 128
> +#define CONFIG_TLS_NELEM 4
> +#define CONFIG_NETDB_BUFSIZE 256
> #define CONFIG_NETDB_MAX_IPADDR 1
> -#define CONFIG_LIBC_IOCTL_VARIADIC 1
> #define CONFIG_LIB_SENDFILE_BUFSIZE 512
> #define CONFIG_BUILTIN 1
> #define CONFIG_HAVE_CXX 1
> #define CONFIG_EXAMPLES_HELLO 1
> -#define CONFIG_EXAMPLES_HELLO_PROGNAME hello
> +#define CONFIG_EXAMPLES_HELLO_PROGNAME "hello"
> #define CONFIG_EXAMPLES_HELLO_PRIORITY 100
> #define CONFIG_EXAMPLES_HELLO_STACKSIZE 2048
> #define CONFIG_NSH_LIBRARY 1
> @@ -214,7 +212,6 @@
> #define CONFIG_NSH_MAXARGUMENTS 7
> #define CONFIG_NSH_NESTDEPTH 3
> #define CONFIG_NSH_BUILTIN_APPS 1
> -#define CONFIG_NSH_DISABLE_DATE 1
> #define CONFIG_NSH_DISABLE_LOSMART 1
> #define CONFIG_NSH_DISABLE_PRINTF 1
> #define CONFIG_NSH_DISABLE_TRUNCATE 1
> @@ -227,7 +224,7 @@
> #define CONFIG_SYSTEM_NSH 1
> #define CONFIG_SYSTEM_NSH_PRIORITY 100
> #define CONFIG_SYSTEM_NSH_STACKSIZE 2048
> -#define CONFIG_SYSTEM_NSH_PROGNAME nsh
> +#define CONFIG_SYSTEM_NSH_PROGNAME "nsh"
> #define CONFIG_SYSTEM_NSH_CXXINITIALIZE 1
> #define CONFIG_READLINE_HAVE_EXTMATCH 1
> #define CONFIG_SYSTEM_READLINE 1
>
> On Tue, Jun 23, 2020 at 6:17 PM Gregory Nutt wrote:
>>
>> On 6/23/2020 6:59 PM, Gregory Nutt wrote:
>> >
>> >> I compared it to release 9.0 and noticed it increased about 3 KiB of
>> >> Flash usage, but I didn't check further to see what happened.
>> >>
>> >> NuttX 9.0
>> >>
>> >> $ arm-none-eabi-size nuttx
>> >> text databssdechexfilename
>> >>68624104 2496 71224 11638nuttx
>> >>
>> >>
>> >> NuttShell (NSH) NuttX-9.0.0
>> >> nsh> free
>> >> total used freelargest
>> >> Umem: 192976 7536 185440 125248
>> >> nsh>
>> >>
>> >>
>> >> NuttX 9.1 RC0
>> >>
>> >> $ arm-none-eabi-size nuttx
>> >> text databssdechexfilename
>> >>71732104 2476 74312 12248nuttx
>> >>
>> >>
>> >> NuttShell (NSH) NuttX-9.1.0
>> >> nsh> free
>>
Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
Started looking and there are some changes in the diff in the generated config.h as can be seen here One change is the date command is no longer disabled by default. This accounts for 2304 bytes, leaving only 800 byte change. I'm not sure if changing the default was expected, but I dont think this should block the release. Changing the default is not the problem. The problem is when the default configuration value is changed, the all configurations effected by that change in the default setting should be updated so that they are not effected. That is, so the net result is no change. That was not done and that is an error. In this case, the NSH 'date' command used to default to 'disabled' UNLESS an RTC was supported, then the default is 'enabled'. There error is, that that the 'date' command should have also been explicitly disabled in ALL NSH configurations that do not have the RTC enabled. That has a negative user impact and would think that correcting that is more important than meeting an artificial release deadline. The TLS changes are harder for me to judge and the netdb change I think just changes ram usage. I don't believe that the TLS changes added any significant size. It replaces one small, simple implementation with another small, simple implementation. It is hard to envision how this would cause any noticeable size increase. But perhaps. Another thing that I noted in Alin's configuration comparison is that the variadic version of the ioctl() interface is no longer optional. That I expect will add a couple hundred bytes to the size of every configuration. The main cause of the size increase is the default 'date' command setting. Not only does that enabled the NSH data command but draws all of the time computation logic into the build. This will probably break many of the more resource constrained configurations.
RE: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
This is a cool tool.
https://github.com/google/bloaty
Here is a set of ways to use it.
https://github.com/PX4/Firmware/blob/4e7dedede79872401f50c733bd74e5ddf1fa41f1/cmake/bloaty.cmake
(please ignore the cmake...)
This is the one that can be used to see the deltas, in our case from mater
to the PR. But it is easy to compare to a release branch.
# bloaty compare with last master build
add_custom_target(bloaty_compare_master
COMMAND wget -c -N --no-verbose
https://s3.amazonaws.com/px4-travis/Firmware/master/${PX4_BOARD_VENDOR}_${PX4_BOARD_MODEL}_${PX4_BOARD_LABEL}.elf
-
O master.elf
COMMAND ${BLOATY_PROGRAM} -d symbols ${BLOATY_OPTS}
$ --
master.elf
DEPENDS px4
WORKING_DIRECTORY ${PX4_BINARY_DIR}
VERBATIM
USES_TERMINAL
)
-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Tuesday, June 23, 2020 10:53 PM
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 9.1.0 (incubating) RC0 release
Greg and Alan,
Started looking and there are some changes in the diff in the
generated config.h as can be seen here
One change is the date command is no longer disabled by default. This
accounts for 2304 bytes, leaving only 800 byte change.
I'm not sure if changing the default was expected, but I dont think
this should block the release.
The TLS changes are harder for me to judge and the netdb change I
think just changes ram usage. I can dig more, if you think it is
necessary, I agree that we should keep and eye on the size though. I
had some thoughts on keeping the build artifacts around so we could
track and test things easier (hard to go back in time with both repos
changing).
9.1.0
text databssdechexfilename
71731104 2476 74311 12247./9.1/nuttx
9.1.0 (with date disabled)
text databssdechexfilename
69427104 2476 72007 11947nuttx
--- /home/bashton/nuttx/apache/sizetest/9.0/config.h
+++ /home/bashton/nuttx/apache/sizetest/9.1/config.h
@@ -135,7 +135,6 @@
#define CONFIG_TASK_NAME_SIZE 31
#define CONFIG_MAX_TASKS 16
#define CONFIG_SCHED_WAITPID 1
-#define CONFIG_NPTHREAD_KEYS 4
#define CONFIG_PTHREAD_MUTEX_ROBUST 1
#define CONFIG_DEV_CONSOLE 1
#define CONFIG_SDCLONE_DISABLE 1
@@ -196,15 +195,14 @@
#define CONFIG_POSIX_SPAWN_PROXY_STACKSIZE 1024
#define CONFIG_TASK_SPAWN_DEFAULT_STACKSIZE 2048
#define CONFIG_LIB_HOSTNAME ""
-#define CONFIG_ARCH_HAVE_TLS 1
-#define CONFIG_NETDB_BUFSIZE 128
+#define CONFIG_TLS_NELEM 4
+#define CONFIG_NETDB_BUFSIZE 256
#define CONFIG_NETDB_MAX_IPADDR 1
-#define CONFIG_LIBC_IOCTL_VARIADIC 1
#define CONFIG_LIB_SENDFILE_BUFSIZE 512
#define CONFIG_BUILTIN 1
#define CONFIG_HAVE_CXX 1
#define CONFIG_EXAMPLES_HELLO 1
-#define CONFIG_EXAMPLES_HELLO_PROGNAME hello
+#define CONFIG_EXAMPLES_HELLO_PROGNAME "hello"
#define CONFIG_EXAMPLES_HELLO_PRIORITY 100
#define CONFIG_EXAMPLES_HELLO_STACKSIZE 2048
#define CONFIG_NSH_LIBRARY 1
@@ -214,7 +212,6 @@
#define CONFIG_NSH_MAXARGUMENTS 7
#define CONFIG_NSH_NESTDEPTH 3
#define CONFIG_NSH_BUILTIN_APPS 1
-#define CONFIG_NSH_DISABLE_DATE 1
#define CONFIG_NSH_DISABLE_LOSMART 1
#define CONFIG_NSH_DISABLE_PRINTF 1
#define CONFIG_NSH_DISABLE_TRUNCATE 1
@@ -227,7 +224,7 @@
#define CONFIG_SYSTEM_NSH 1
#define CONFIG_SYSTEM_NSH_PRIORITY 100
#define CONFIG_SYSTEM_NSH_STACKSIZE 2048
-#define CONFIG_SYSTEM_NSH_PROGNAME nsh
+#define CONFIG_SYSTEM_NSH_PROGNAME "nsh"
#define CONFIG_SYSTEM_NSH_CXXINITIALIZE 1
#define CONFIG_READLINE_HAVE_EXTMATCH 1
#define CONFIG_SYSTEM_READLINE 1
On Tue, Jun 23, 2020 at 6:17 PM Gregory Nutt wrote:
>
> On 6/23/2020 6:59 PM, Gregory Nutt wrote:
> >
> >> I compared it to release 9.0 and noticed it increased about 3 KiB of
> >> Flash usage, but I didn't check further to see what happened.
> >>
> >> NuttX 9.0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text databssdechexfilename
> >>68624104 2496 71224 11638nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.0.0
> >> nsh> free
> >> total used freelargest
> >> Umem: 192976 7536 185440 125248
> >> nsh>
> >>
> >>
> >> NuttX 9.1 RC0
> >>
> >> $ arm-none-eabi-size nuttx
> >> text databssdechexfilename
> >>71732104 2476 74312 12248nuttx
> >>
> >>
> >> NuttShell (NSH) NuttX-9.1.0
> >> nsh> free
> >> total used freelargest
> >> Umem: 192992 7536 185456 125264
> >> nsh>
> >
> > This might indicate a significant problem. One possible explanation
> > might be that a new configuration option enables logic by default that
> > it should not. Almost any explanation you can think of suggests a
> > problem.
>
> Can you look into this Alan? I would think that
bug report
Hi, During the test, I've got a system crash (hardfault) when running os_test. After debugging with jtag+gdb, I found that crash occurred at line 283 of mm_realloc() (mm_realloc.c). Hardfault cause was "accessing invalid memory area". This is because realloc logic uses new size (not the original size) when copying data to new target. For example, original size is 32 and realloc 1024, then current logic will try 1024 memcpy and this try crosses the end of valid memory and produce memory faults. (or just grap other processes memory if it is valid memory area). Simple code reordering should fix this issue (line 273 - 283). From /* Now we want to return newnode */ oldnode = newnode; oldsize = newnode->size; /* Now we have to move the user contents 'down' in memory. memcpy * should be safe for this. */ newmem = (FAR void *)((FAR char *)newnode + SIZEOF_MM_ALLOCNODE); memcpy(newmem, oldmem, oldsize - SIZEOF_MM_ALLOCNODE); To /* Now we have to move the user contents 'down' in memory. memcpy * should be safe for this. */ newmem = (FAR void *)((FAR char *)newnode + SIZEOF_MM_ALLOCNODE); memcpy(newmem, oldmem, oldsize - SIZEOF_MM_ALLOCNODE); /* Now we want to return newnode */ oldnode = newnode; oldsize = newnode->size; That means use orignal size (oldsize) when memcpy. Thansk Kwonsk
