RE: enter/leave_critical_section() calls in the user space library

[Xiang Xiao]

Yes, we need revise all enter/leave_critical_section, and do the different 
thing case by case:
1.Remove the unnecessary enter/leave_critical_section like syslog case
2.Replace with the more fine-grained lock e.g.:
   a.pthread_mutex/pthread_spin_lock/pthread_rw_mutex for user space
   b.semaphore/spin_lock for kernel space
   c.standard atomic operation(yes, we may need port to the old toolchain)
Since more and more project start to use the multiple core SoC(at least Sony 
and Xiaomi), we need fix this problem in a system way: not only address the 
compile/link issue, but also the performance issue. BTW, 
sched_lock/sched_unlock also need to revise again.
A simple search show up:
enter/leave_critical_section2132 caller in 858 files
sched_lock/unlock 251 caller in 173 files
Yes, it isn't a simple work, but we need to make a change here if we want to 
make NuttX become the best SMP RTOS.

Thanks
Xiang

-Original Message-
From: spudaneco  
Sent: Tuesday, May 12, 2020 12:52 PM
To: dev@nuttx.apache.org
Cc: Nakamura, Yuuichi (Sony) 
Subject: RE: enter/leave_critical_section() calls in the user space library

I don't understand why you need to do that.But for the SMP case there is a 
better, lighter weight critical section called spinlock_irqsave.  It is 
intended to protect very short code sequences with a spin lock.  Very 
efficient.enter_critical_section is a big, fat pig in SMP and the lighter 
spinlock should be used instead.The only thing is that the protected code 
segment must not suspend itself while holding the spinlock.GregSent from 
Samsung tablet.
 Original message From: "Nakamura, Yuuichi (Sony)" 
 Date: 5/11/20  10:34 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Cc: "Nakamura, Yuuichi (Sony)" 
 Subject: RE: enter/leave_critical_section() calls 
in the user space library Thanks for accepting my PR.Now it's ok for protected 
build with uniprocessor case, but not sufficient in SMP case.The following 
files included in the user mode library contain enter/leave_critical_section() 
only when CONFIG_SMP=y.libs/libc/misc/lib_filesem.cmm/mm_heap/mm_sem.cThese may 
have to be moved into the kernel space.Thanks,Yuuichi Nakamura> -Original 
Message-> From: Xiang Xiao > Sent: Monday, May 
11, 2020 3:20 PM> To: dev@nuttx.apache.org> Subject: RE: 
enter/leave_critical_section() calls in the user space library> > But we need 
to consider syslog call from interrupt context too. So I think the> simple 
modification is:> 1.Drop the critical section> 2.Keep the global variable> In 
FLAT/PROTECTED build, all user space applications have to share the same> 
variable.> > -Original Message-> From: Gregory Nutt 
> Sent: Monday, May 11, 2020 12:35 PM> To: 
dev@nuttx.apache.org> Subject: Re: enter/leave_critical_section() calls in the 
user space library> > > >  From this link:> > 
https://linux.die.net/man/3/setlogmask> > logmask has per task scope not per 
thread scope. So we still suffer the> concurrent issue if we change to 
group-specific logmask.> > The same text appears in the more authoritative 
Opengroup.org web page:> 
https://pubs.opengroup.org/onlinepubs/7908799/xsh/closelog.html> > We meet that 
requirement in the KERNEL mode, but not in the FLAT or> PROTECTED modes.> > So 
the logmask must be in the group structure and setlogmask must become a> system 
call at least in the FLAT and PROTECTED build.  In the KERNEL build,> a plain 
global variable as it is now is just fine.  There will be one instance of the> 
global variable in each process address space.> > pthread APIs are not 
appropriate for use across processes (groups), so we> must avoid pthread 
mutexes.  This will not work in the KERNEL build mode> because each mutex lies 
in a different address space.   A usable mutex would> have to use something 
like sem_open() which creates a semaphore can be> used across process 
boundaries.> > Note that setlogmask is classified as NOT thread safe: 
Preliminary: |> MT-Unsafe race:LogMask | AS-Unsafe | AC-Safe | See POSIX Safety 
Concepts>  
cepts.html#POSIX-Safety-Concepts>.> See 
https://www.gnu.org/software/libc/manual/html_node/setlogmask.html> > So we 
should have no concern about thread safety.  No re-entrancy protection> is 
required.  We can just remove the critical section. We do not need to use a> 
semaphore or mutex.> > Greg> 

Build failed in Jenkins: NuttX-Nightly-Build #150

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 306.29 KB...]

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mount

Configuration/Tool: sim/module

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/module

Configuration/Tool: sim/minibasic

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/minibasic

Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
--2020-05-12 05:37:27--  
https://github.com/ARMmbed/littlefs/archive/v2.2.1.tar.gz
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1 [following]
--2020-05-12 05:37:28--  
https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: 'littlefs/v2.2.1.tar.gz'

v2.2.1.tar.gz   [<=> ]   0  --.-KB/s   
v2.2.1.tar.gz   [ <=>] 111.57K  --.-KB/sin 0.02s   

2020-05-12 05:37:29 (6.81 MB/s) - 'littlefs/v2.2.1.tar.gz' saved [114250]

  Normalize sim/tcpblaster

Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/touchscreen

Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/bas

Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mtdpart

Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/spiffs

Configuration/Tool: sim/ustream

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/ustream

Configuration/Tool: sim/userfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/userfs

Configuration/Tool: sim/rpproxy

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
--2020-05-12 05:40:53--  
https://github.com/OpenAMP/libmetal/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0 
[following]
--2020-05-12 05:40:53--  

RE: enter/leave_critical_section() calls in the user space library

[spudaneco]

I don't understand why you need to do that.But for the SMP case there is a 
better, lighter weight critical section called spinlock_irqsave.  It is 
intended to protect very short code sequences with a spin lock.  Very 
efficient.enter_critical_section is a big, fat pig in SMP and the lighter 
spinlock should be used instead.The only thing is that the protected code 
segment must not suspend itself while holding the spinlock.GregSent from 
Samsung tablet.
 Original message From: "Nakamura, Yuuichi (Sony)" 
 Date: 5/11/20  10:34 PM  (GMT-06:00) To: 
dev@nuttx.apache.org Cc: "Nakamura, Yuuichi (Sony)" 
 Subject: RE: enter/leave_critical_section() calls 
in the user space library Thanks for accepting my PR.Now it's ok for protected 
build with uniprocessor case, but not sufficient in SMP case.The following 
files included in the user mode library contain enter/leave_critical_section() 
only when CONFIG_SMP=y.libs/libc/misc/lib_filesem.cmm/mm_heap/mm_sem.cThese may 
have to be moved into the kernel space.Thanks,Yuuichi Nakamura> -Original 
Message-> From: Xiang Xiao > Sent: Monday, May 
11, 2020 3:20 PM> To: dev@nuttx.apache.org> Subject: RE: 
enter/leave_critical_section() calls in the user space library> > But we need 
to consider syslog call from interrupt context too. So I think the> simple 
modification is:> 1.Drop the critical section> 2.Keep the global variable> In 
FLAT/PROTECTED build, all user space applications have to share the same> 
variable.> > -Original Message-> From: Gregory Nutt 
> Sent: Monday, May 11, 2020 12:35 PM> To: 
dev@nuttx.apache.org> Subject: Re: enter/leave_critical_section() calls in the 
user space library> > > >  From this link:> > 
https://linux.die.net/man/3/setlogmask> > logmask has per task scope not per 
thread scope. So we still suffer the> concurrent issue if we change to 
group-specific logmask.> > The same text appears in the more authoritative 
Opengroup.org web page:> 
https://pubs.opengroup.org/onlinepubs/7908799/xsh/closelog.html> > We meet that 
requirement in the KERNEL mode, but not in the FLAT or> PROTECTED modes.> > So 
the logmask must be in the group structure and setlogmask must become a> system 
call at least in the FLAT and PROTECTED build.  In the KERNEL build,> a plain 
global variable as it is now is just fine.  There will be one instance of the> 
global variable in each process address space.> > pthread APIs are not 
appropriate for use across processes (groups), so we> must avoid pthread 
mutexes.  This will not work in the KERNEL build mode> because each mutex lies 
in a different address space.   A usable mutex would> have to use something 
like sem_open() which creates a semaphore can be> used across process 
boundaries.> > Note that setlogmask is classified as NOT thread safe: 
Preliminary: |> MT-Unsafe race:LogMask | AS-Unsafe | AC-Safe | See POSIX Safety 
Concepts>  
cepts.html#POSIX-Safety-Concepts>.> See 
https://www.gnu.org/software/libc/manual/html_node/setlogmask.html> > So we 
should have no concern about thread safety.  No re-entrancy protection> is 
required.  We can just remove the critical section. We do not need to use a> 
semaphore or mutex.> > Greg> 

RE: enter/leave_critical_section() calls in the user space library

[Nakamura, Yuuichi (Sony)]

Thanks for accepting my PR.
Now it's ok for protected build with uniprocessor case, but not sufficient in 
SMP case.
The following files included in the user mode library contain 
enter/leave_critical_section() only when CONFIG_SMP=y.

libs/libc/misc/lib_filesem.c
mm/mm_heap/mm_sem.c

These may have to be moved into the kernel space.

Thanks,
Yuuichi Nakamura

> -Original Message-
> From: Xiang Xiao 
> Sent: Monday, May 11, 2020 3:20 PM
> To: dev@nuttx.apache.org
> Subject: RE: enter/leave_critical_section() calls in the user space library
> 
> But we need to consider syslog call from interrupt context too. So I think the
> simple modification is:
> 1.Drop the critical section
> 2.Keep the global variable
> In FLAT/PROTECTED build, all user space applications have to share the same
> variable.
> 
> -Original Message-
> From: Gregory Nutt 
> Sent: Monday, May 11, 2020 12:35 PM
> To: dev@nuttx.apache.org
> Subject: Re: enter/leave_critical_section() calls in the user space library
> 
> 
> >  From this link:
> > https://linux.die.net/man/3/setlogmask
> > logmask has per task scope not per thread scope. So we still suffer the
> concurrent issue if we change to group-specific logmask.
> 
> The same text appears in the more authoritative Opengroup.org web page:
> https://pubs.opengroup.org/onlinepubs/7908799/xsh/closelog.html
> 
> We meet that requirement in the KERNEL mode, but not in the FLAT or
> PROTECTED modes.
> 
> So the logmask must be in the group structure and setlogmask must become a
> system call at least in the FLAT and PROTECTED build.  In the KERNEL build,
> a plain global variable as it is now is just fine.  There will be one 
> instance of the
> global variable in each process address space.
> 
> pthread APIs are not appropriate for use across processes (groups), so we
> must avoid pthread mutexes.  This will not work in the KERNEL build mode
> because each mutex lies in a different address space.   A usable mutex would
> have to use something like sem_open() which creates a semaphore can be
> used across process boundaries.
> 
> Note that setlogmask is classified as NOT thread safe: Preliminary: |
> MT-Unsafe race:LogMask | AS-Unsafe | AC-Safe | See POSIX Safety Concepts
>  cepts.html#POSIX-Safety-Concepts>.
> See https://www.gnu.org/software/libc/manual/html_node/setlogmask.html
> 
> So we should have no concern about thread safety.  No re-entrancy protection
> is required.  We can just remove the critical section. We do not need to use a
> semaphore or mutex.
> 
> Greg
> 

Sv: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Jerpelea, Alin]

Welcome onboard!

Best Regards

Alin

Från: Xiang Xiao 
Skickat: den 12 maj 2020 05:57
Till: gene...@incubator.apache.org ; 
dev@nuttx.apache.org 
Kopia: '俊平堵' 
Ämne: RE: [NOMINATION] Self nominate to be a mentor of Apache NuttX

Welcome onboard!
The first contribution could be improve README with your experience, so all 
mentor can successfully build uttX in the next release:) .

-Original Message-
From: Duo Zhang 
Sent: Tuesday, May 12, 2020 9:11 AM
To: dev@nuttx.apache.org
Cc: gene...@incubator.apache.org; 俊平堵 
Subject: [NOMINATION] Self nominate to be a mentor of Apache NuttX

Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a 
mentor of Apache Nuttx, since I'm the only person among 3 binding votes who 
have successfully built NuttX in the 9.0.0 vote thread. Just joking :)

Last year when Greg and David came to China, we talked about joining an open 
source community and finally Greg chose the ASF. You can see that I helped 
explaining in the discussion thread and also voted in the vote thread. And now 
I'm already an IPMC member, I would like to help more on the project. I'm not 
an embedded engineer so maybe I can not contribute code but I think I could 
help with the release processing, workflow, and also the documentation, etc.

Thanks. Regards.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Xiang Xiao]

Welcome onboard!
The first contribution could be improve README with your experience, so all 
mentor can successfully build uttX in the next release:) .

-Original Message-
From: Duo Zhang  
Sent: Tuesday, May 12, 2020 9:11 AM
To: dev@nuttx.apache.org
Cc: gene...@incubator.apache.org; 俊平堵 
Subject: [NOMINATION] Self nominate to be a mentor of Apache NuttX

Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a 
mentor of Apache Nuttx, since I'm the only person among 3 binding votes who 
have successfully built NuttX in the 9.0.0 vote thread. Just joking :)

Last year when Greg and David came to China, we talked about joining an open 
source community and finally Greg chose the ASF. You can see that I helped 
explaining in the discussion thread and also voted in the vote thread. And now 
I'm already an IPMC member, I would like to help more on the project. I'm not 
an embedded engineer so maybe I can not contribute code but I think I could 
help with the release processing, workflow, and also the documentation, etc.

Thanks. Regards.

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[俊平堵]

Welcome onboard, Duo!

Thanks,

Junping

Duo Zhang  于2020年5月12日周二 上午9:11写道：

> Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
> mentor of Apache Nuttx, since I'm the only person among 3 binding votes who
> have successfully built NuttX in the 9.0.0 vote thread. Just joking :)
>
> Last year when Greg and David came to China, we talked about joining an
> open source community and finally Greg chose the ASF. You can see that I
> helped explaining in the discussion thread and also voted in the vote
> thread. And now I'm already an IPMC member, I would like to help more on
> the project. I'm not an embedded engineer so maybe I can not contribute
> code but I think I could help with the release processing, workflow, and
> also the documentation, etc.
>
> Thanks. Regards.
>

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Justin Mclean]

HI,

> Welcome! Are there any formalities that we need to do (vote etc)?

Only if you want them. I would say a lazy consensus applies i.e. if there no 
objections then just make it happen.

Thanks,
Justin

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Nathan Hartman]

On 5/11/20, Duo Zhang  wrote:
> Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
> mentor of Apache Nuttx, since I'm the only person among 3 binding votes who
> have successfully built NuttX in the 9.0.0 vote thread. Just joking :)
>
> Last year when Greg and David came to China, we talked about joining an
> open source community and finally Greg chose the ASF. You can see that I
> helped explaining in the discussion thread and also voted in the vote
> thread. And now I'm already an IPMC member, I would like to help more on
> the project. I'm not an embedded engineer so maybe I can not contribute
> code but I think I could help with the release processing, workflow, and
> also the documentation, etc.

Welcome! Are there any formalities that we need to do (vote etc)? Just
in case we do, I am fully in support!

Also, just today I sent a (admittedly long) email (NuttX: More than
just code) where I explained that we need a lot of help in many areas.
Of course, code is important, but we need people with other skills
too.

Thanks for getting involved.

Cheers,
Nathan

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Alan Carvalho de Assis]

Welcome Duo!

It will nice to have you as mentor!

BR,

Alan

On 5/11/20, Duo Zhang  wrote:
> Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
> mentor of Apache Nuttx, since I'm the only person among 3 binding votes who
> have successfully built NuttX in the 9.0.0 vote thread. Just joking :)
>
> Last year when Greg and David came to China, we talked about joining an
> open source community and finally Greg chose the ASF. You can see that I
> helped explaining in the discussion thread and also voted in the vote
> thread. And now I'm already an IPMC member, I would like to help more on
> the project. I'm not an embedded engineer so maybe I can not contribute
> code but I think I could help with the release processing, workflow, and
> also the documentation, etc.
>
> Thanks. Regards.
>

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Abdelatif Guettouche]

It would be great to have on the team!

On Tue, May 12, 2020 at 2:25 AM Gregory Nutt  wrote:
>
> +1
>
> In case you are calling a self-VOTE too  :).  I would love to have you
> one board!  We could use the help.
>
> Greg
>
> On 5/11/2020 7:10 PM, Duo Zhang wrote:
> > Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
> > mentor of Apache Nuttx, since I'm the only person among 3 binding votes who
> > have successfully built NuttX in the 9.0.0 vote thread. Just joking :)
> >
> > Last year when Greg and David came to China, we talked about joining an
> > open source community and finally Greg chose the ASF. You can see that I
> > helped explaining in the discussion thread and also voted in the vote
> > thread. And now I'm already an IPMC member, I would like to help more on
> > the project. I'm not an embedded engineer so maybe I can not contribute
> > code but I think I could help with the release processing, workflow, and
> > also the documentation, etc.
> >
> > Thanks. Regards.
> >

Re: [NOMINATION] Self nominate to be a mentor of Apache NuttX

[Gregory Nutt]

+1

In case you are calling a self-VOTE too  :).  I would love to have you 
one board!  We could use the help.


Greg

On 5/11/2020 7:10 PM, Duo Zhang wrote:

Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
mentor of Apache Nuttx, since I'm the only person among 3 binding votes who
have successfully built NuttX in the 9.0.0 vote thread. Just joking :)

Last year when Greg and David came to China, we talked about joining an
open source community and finally Greg chose the ASF. You can see that I
helped explaining in the discussion thread and also voted in the vote
thread. And now I'm already an IPMC member, I would like to help more on
the project. I'm not an embedded engineer so maybe I can not contribute
code but I think I could help with the release processing, workflow, and
also the documentation, etc.

Thanks. Regards.

[NOMINATION] Self nominate to be a mentor of Apache NuttX

[Duo Zhang]

Hi, NuttX community, I'm Duo Zhang, I would like to self nominate to be a
mentor of Apache Nuttx, since I'm the only person among 3 binding votes who
have successfully built NuttX in the 9.0.0 vote thread. Just joking :)

Last year when Greg and David came to China, we talked about joining an
open source community and finally Greg chose the ASF. You can see that I
helped explaining in the discussion thread and also voted in the vote
thread. And now I'm already an IPMC member, I would like to help more on
the project. I'm not an embedded engineer so maybe I can not contribute
code but I think I could help with the release processing, workflow, and
also the documentation, etc.

Thanks. Regards.

Re: [ANNOUNCE] Apache NuttX 9.0.0-incubating released

[Abdelatif Guettouche]

Well done everyone, it was a marathon!
We've learned a lot about the process and I'm sure the next releases
will be smoother.

On Mon, May 11, 2020 at 8:10 PM Nathan Hartman  wrote:
>
> On Mon, May 11, 2020 at 3:01 PM Brennan Ashton 
> wrote:
>
> > The Apache NuttX (incubating) project team is proud to announce
> > Apache NuttX 9.0.0-incubating has been released.
> > This is the 1st Apache release as an Apache Incubator project.
> >
> > https://nuttx.apache.org/download/
> > https://nuttx.apache.org/releases/9.0.0/
>
>
>
> I'd like to congratulate our team on reaching this important milestone!
> We've overcome all kinds of challenges to get here. Thanks to everyone for
> your great work. Looking forward to many more successful releases!
>
> Cheers,
> Nathan
>
> 

Re: heap malloc when executing binary/elf file

[Florian Wehmeyer]

OK Greg, 
could be that I was using too much.. using 64KB of ramdisk also.. I
disabled some of the comfortable features like cmd line history etc,
and was already able to alloc quite a bit more than before..
Will further improve the sram usage..
Also, I missed the commit 
mm/mm_heap: fix mm_heap not support BUILD_FLAT



  GUIDINGLI


  authored and   patacongo

  committed
  on Apr 10



which well might impact my stuff here, will pull and let you know, 
@Nathan I will also make tests if malloc continues returning non NULL
pointers even if out of memory..

Seems on a good way!!

Many thanks,
Florian



--
Florian Wehmeyer
TFW Tech-Solutions
On Seg, 2020-05-11 at 15:09 -0600, Gregory Nutt wrote:
> >
> >
> > >
> > > No custom board, it's the  tm4c1294-launchpad.
> > > Seems no general problem with heap allocation, so I guess it's
> > > not in
> > > the linker script, it's rather directly linked to the usage of
> > > the elf-
> > > binary loader, and there are only two configs in the nuttx repo
> > > which
> > > use the CONFIG_ELF stuff.
> > That part has 256Kb of SRAM.  That is more that many, but it could
> > be 
> > that you are using too much SRAM and just cannot run ELF reliably. 
> > It 
> > does want a lot of SRAM.
> Most of the other boards that use CONFIG_ELF=y in a configuration
> have a 
> much larger internal ram (exceptions in red):
>
> $ find . -name defconfig | xargs grep -l CONFIG_ELF=y | xargs grep
> RAM_SIZE
> ./arm/cxd56xx/spresense/configs/elf/defconfig:CONFIG_RAM_SIZE=1572864
> ./arm/cxd56xx/spresense/configs/module/defconfig:CONFIG_RAM_SIZE=1572
> 864
> ./arm/cxd56xx/spresense/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE
> =1572864
> ./arm/cxd56xx/spresense/configs/rndis/defconfig:CONFIG_RAM_SIZE=15728
> 64
> ./arm/cxd56xx/spresense/configs/wifi/defconfig:CONFIG_RAM_SIZE=157286
> 4
> ./arm/lc823450/lc823450-
> xgevk/configs/elf/defconfig:CONFIG_RAM_SIZE=1044480
> ./arm/lc823450/lc823450-
> xgevk/configs/krndis/defconfig:CONFIG_RAM_SIZE=1044480
> ./arm/lc823450/lc823450-
> xgevk/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=1044480
> ./arm/lc823450/lc823450-
> xgevk/configs/rndis/defconfig:CONFIG_RAM_SIZE=1044480
> ./arm/lc823450/lc823450-
> xgevk/configs/usb/defconfig:CONFIG_RAM_SIZE=1044480
> ./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_RAM_SIZE=65536
> ./arm/sama5/sama5d4-
> ek/configs/elf/defconfig:CONFIG_RAM_SIZE=268435456
> ./arm/sama5/sama5d4-
> ek/configs/knsh/defconfig:CONFIG_RAM_SIZE=268435456
> ./arm/stm32/olimex-stm32-
> p407/configs/kelf/defconfig:CONFIG_RAM_SIZE=114688
> ./arm/stm32/stm32f4discovery/configs/elf/defconfig:CONFIG_RAM_SIZE=11
> 4688
> ./arm/stm32/stm32f4discovery/configs/posix_spawn/defconfig:CONFIG_RAM
> _SIZE=114688
> ./arm/stm32/stm32f4discovery/configs/rndis/defconfig:CONFIG_RAM_SIZE=
> 114688
> ./arm/tms570/tms570ls31x-usb-
> kit/configs/nsh/defconfig:CONFIG_RAM_SIZE=262143
> ./risc-v/k210/maix-bit/configs/elf/defconfig:CONFIG_RAM_SIZE=2097152
> ./risc-v/k210/maix-
> bit/configs/module/defconfig:CONFIG_RAM_SIZE=2097152
> ./risc-v/k210/maix-
> bit/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=2097152
>
> And one of these exceptions has a large external DRAM:
>
> $ find . -name defconfig | xargs grep -l CONFIG_ELF=y | xargs grep
> EXTDRAM
> ./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_LPC17_40_EXTDR
> AM=y
> ./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_LPC17_40_EXTDR
> AMSIZE=33554432
>
>

[CVE-2020-1939] Apache NuttX optional/example ftpd program NULL pointer bug

[Brennan Ashton]

CVE-2020-1939: Apache NuttX optional/example ftpd program NULL pointer
bug

Severity: Important

Vendor:
Apache NuttX (Incubating)

Versions Affected:
6.15 to 8.2 (all pre-date NuttX joining the Apache.org Incubator)

Description:
The Apache NuttX (Incubating) project provides an optional separate
"apps" repository which contains various optional components and
example programs. One of these, ftpd, had a NULL pointer dereference
bug. The NuttX RTOS itself is not affected. Users of the optional apps
repository are affected only if they have enabled ftpd.

Mitigation:
Users of affected versions should upgrade to 9.0.0 or apply the
following patch:
https://patch-diff.githubusercontent.com/raw/apache/incubator-nuttx-apps/pull/10.patch

Credit:
This issue was discovered by Jakub Botwicz of Samsung R&D Poland.

References:
https://bitbucket.org/nuttx/apps-old/issues/15/null-dereference-in-ftp-size-command
https://github.com/apache/incubator-nuttx-apps/pull/10

Regards,
Brennan Ashton

Re: heap malloc when executing binary/elf file

[Nathan Hartman]

On Mon, May 11, 2020 at 5:01 PM Gregory Nutt  wrote:
> That part has 256Kb of SRAM.  That is more that many, but it could be
> that you are using too much SRAM and just cannot run ELF reliably.  It
> does want a lot of SRAM.

If there isn't enough memory, I wonder why malloc doesn't return NULL?
Haven't had the chance to look into the code yet. Maybe there's a bug
-- or perhaps there's something misconfigured that fools malloc into
thinking there's more memory than there really is.

Nathan

Re: heap malloc when executing binary/elf file

[Gregory Nutt]

No custom board, it's the  tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.


That part has 256Kb of SRAM.  That is more that many, but it could be 
that you are using too much SRAM and just cannot run ELF reliably.  It 
does want a lot of SRAM.


Most of the other boards that use CONFIG_ELF=y in a configuration have a 
much larger internal ram (exceptions in red):


$ find . -name defconfig | xargs grep -l CONFIG_ELF=y | xargs grep RAM_SIZE
./arm/cxd56xx/spresense/configs/elf/defconfig:CONFIG_RAM_SIZE=1572864
./arm/cxd56xx/spresense/configs/module/defconfig:CONFIG_RAM_SIZE=1572864
./arm/cxd56xx/spresense/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=1572864
./arm/cxd56xx/spresense/configs/rndis/defconfig:CONFIG_RAM_SIZE=1572864
./arm/cxd56xx/spresense/configs/wifi/defconfig:CONFIG_RAM_SIZE=1572864
./arm/lc823450/lc823450-xgevk/configs/elf/defconfig:CONFIG_RAM_SIZE=1044480
./arm/lc823450/lc823450-xgevk/configs/krndis/defconfig:CONFIG_RAM_SIZE=1044480
./arm/lc823450/lc823450-xgevk/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=1044480
./arm/lc823450/lc823450-xgevk/configs/rndis/defconfig:CONFIG_RAM_SIZE=1044480
./arm/lc823450/lc823450-xgevk/configs/usb/defconfig:CONFIG_RAM_SIZE=1044480
./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_RAM_SIZE=65536
./arm/sama5/sama5d4-ek/configs/elf/defconfig:CONFIG_RAM_SIZE=268435456
./arm/sama5/sama5d4-ek/configs/knsh/defconfig:CONFIG_RAM_SIZE=268435456
./arm/stm32/olimex-stm32-p407/configs/kelf/defconfig:CONFIG_RAM_SIZE=114688
./arm/stm32/stm32f4discovery/configs/elf/defconfig:CONFIG_RAM_SIZE=114688
./arm/stm32/stm32f4discovery/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=114688
./arm/stm32/stm32f4discovery/configs/rndis/defconfig:CONFIG_RAM_SIZE=114688
./arm/tms570/tms570ls31x-usb-kit/configs/nsh/defconfig:CONFIG_RAM_SIZE=262143
./risc-v/k210/maix-bit/configs/elf/defconfig:CONFIG_RAM_SIZE=2097152
./risc-v/k210/maix-bit/configs/module/defconfig:CONFIG_RAM_SIZE=2097152
./risc-v/k210/maix-bit/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=2097152

And one of these exceptions has a large external DRAM:

$ find . -name defconfig | xargs grep -l CONFIG_ELF=y | xargs grep EXTDRAM
./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_LPC17_40_EXTDRAM=y
./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_LPC17_40_EXTDRAMSIZE=33554432

Re: heap malloc when executing binary/elf file

[Gregory Nutt]

No custom board, it's the  tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.


That part has 256Kb of SRAM.  That is more that many, but it could be 
that you are using too much SRAM and just cannot run ELF reliably.  It 
does want a lot of SRAM.

Re: heap malloc when executing binary/elf file

[Florian Wehmeyer]

Thanks Nathan, 
I'll check on that..
No custom board, it's the  tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.. 
But, I will double-check the elf linker script, maybe something wrong
with that!
BR,

--
Florian Wehmeyer
TFW Tech-Solutions
On Seg, 2020-05-11 at 16:24 -0400, Nathan Hartman wrote:
> On Mon, May 11, 2020 at 2:05 PM Florian Wehmeyer 
> wrote:
> >
> > OK I already saw that simply increasing the heap is no solution,
> > because it's already maximum size:
> > mm_initialize: Heap: start=0x20008924
> > size=227036
> > mm_addregion: Region 1: base=0x20008924 size=227024
> Tricky problem.
>
> Is this for a custom board or an existing configuration? If an
> existing configuration, which one?
>
> If it's for a custom board, then the place I would recommend to check
> is the linker script, Kconfig options, and compiler options. Perhaps
> try to find an existing configuration in the NuttX tree that is as
> close as possible to yours, and compare the various files (linker
> files, defconfig, etc) and see whether any differences that you find
> will affect heap allocations.
>
> Hopefully someone else here can chime in with some more specific
> items to check.
>
> Nathan

Re: heap malloc when executing binary/elf file

[Nathan Hartman]

On Mon, May 11, 2020 at 2:05 PM Florian Wehmeyer  wrote:
> OK I already saw that simply increasing the heap is no solution,
> because it's already maximum size:
> mm_initialize: Heap: start=0x20008924
> size=227036
> mm_addregion: Region 1: base=0x20008924 size=227024

Tricky problem.

Is this for a custom board or an existing configuration? If an
existing configuration, which one?

If it's for a custom board, then the place I would recommend to check
is the linker script, Kconfig options, and compiler options. Perhaps
try to find an existing configuration in the NuttX tree that is as
close as possible to yours, and compare the various files (linker
files, defconfig, etc) and see whether any differences that you find
will affect heap allocations.

Hopefully someone else here can chime in with some more specific items to check.

Nathan

NuttX website: Adding a News & Announcements section

[Nathan Hartman]

I propose that the homepage of nuttx.apache.org should have a new
section called News and Announcements, that over time would contain a
list of the three or four most recent project-related news items.

Currently we have one news-worthy item: The release of 9.0.

I am opening a pull request on the incubator-nuttx-website repo...

This adds the "News and Announcements" section and includes our first news item.

It's PR #24:
https://github.com/apache/incubator-nuttx-website/pull/24

Cheers,
Nathan

Re: [ANNOUNCE] Apache NuttX 9.0.0-incubating released

[Nathan Hartman]

On Mon, May 11, 2020 at 3:01 PM Brennan Ashton 
wrote:

> The Apache NuttX (incubating) project team is proud to announce
> Apache NuttX 9.0.0-incubating has been released.
> This is the 1st Apache release as an Apache Incubator project.
>
> https://nuttx.apache.org/download/
> https://nuttx.apache.org/releases/9.0.0/



I'd like to congratulate our team on reaching this important milestone!
We've overcome all kinds of challenges to get here. Thanks to everyone for
your great work. Looking forward to many more successful releases!

Cheers,
Nathan

[ANNOUNCE] Apache NuttX 9.0.0-incubating released

[Brennan Ashton]

The Apache NuttX (incubating) project team is proud to announce
Apache NuttX 9.0.0-incubating has been released.
This is the 1st Apache release as an Apache Incubator project.

NuttX is a real-time operating system (RTOS) with an emphasis on standards
compliance and small footprint. Scalable from 8-bit to 64-bit
microcontroller environments, the primary governing standards in NuttX are
Posix and ANSI standards. Additional standard APIs from Unix and other
common RTOS’s (such as VxWorks) are adopted for functionality not available
under these standards, or for functionality that is not appropriate for
deeply-embedded environments (such as fork()).

The release artifacts and ChangeLog can be found at:
https://nuttx.apache.org/download/
https://nuttx.apache.org/releases/9.0.0/


Find more about our project at:
 - Project Site:  https://nuttx.apache.org/
 - Github mirror: https://github.com/apache/incubator-nuttx
 - Mailing list(s): dev@nuttx.apache.org

Thanks,
Brennan Ashton
on behalf of Apache NuttX PPMC

=
*Disclaimer*
Apache NuttX (incubating) is an effort undergoing incubation at
The Apache Software Foundation (ASF), sponsored by the name of Apache
Incubator PMC. Incubation is required of all newly accepted projects
until a further review indicates that the infrastructure, communications,
and decision making process have stabilized in a manner consistent
with other successful ASF projects. While incubation status is not
necessarily a reflection of the completeness or stability of the code,
it does indicate that the project has yet to be fully endorsed by the ASF.

Re: heap malloc when executing binary/elf file

[Florian Wehmeyer]

OK I already saw that simply increasing the heap is no solution,
because it's already maximum size: 
mm_initialize: Heap: start=0x20008924
size=227036   
mm_addregion: Region 1: base=0x20008924 size=227024

-- 
Florian Wehmeyer
TFW Tech-Solutions
On Seg, 2020-05-11 at 14:31 -0300, Florian Wehmeyer wrote:
> looking more into the memory allocation debug, there is a lot more
> dynamic allocation (obviously)  when loading the elf program than
> when loading the same program as built-in..
> So, seems the problem is due to a high heap fragmentation, what
> explains that a call to dmesg can also make the system crash..
> So, maybe my question should be, is increasing the heap a solution
> for
> that? If yes, how do I increase it?
> BR,
> Florian
> prints of debug output with my comments:
> calling the Elf program (Neo_Ledtest):
>   PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK
> COMMAND   
> 0   0 FIFO Kthread N-- Ready   00
> Idle
> Task 
> 1 224 FIFO Kthread --- Waiting  Signal 002028
> hpwork
> 2 100 FIFO Task--- Running 002028
> init  
> 3  80 RR   pthread --- Waiting  Semaphore  001564
> netinit 0x0   
> 4 100 FIFO Task--- Waiting  Semaphore  002004
> Telnet daemon0
> 6 100 FIFO Task--- Waiting  Semaphore  006116
> Neo_Ledtest   
> nsh> cat
> /proc/6/stack
>   
> StackBase:  0x0x200214b0 
>   
>  
> StackSize:  6116 
> StackEnd = 0x200214b0 - 6116d = 0x2001FCCC
> nsh> dmesg//called right after calling the elf program,
> after flushing the
> syslog..  
> mm_free: Freeing
> 0x2001d010 
> mm_malloc: Allocated 0x2000cbd0, size
> 64
> mm_malloc: Allocated 0x20009710, size
> 32
> mm_malloc: Allocated 0x2000cc10, size
> 48
> mm_malloc: Allocated 0x2001d010, size
> 48
> mm_malloc: Allocated 0x2001d040, size
> 528   
> mm_malloc: Allocated 0x2001d250, size
> 448   
> mm_malloc: Allocated 0x2001d410, size
> 6624  
> mm_malloc: Allocated 0x2001edf0, size
> 528   
> mm_malloc: Allocated 0x2001f000, size
> 2064  
> mm_malloc: Allocated 0x2001f810, size
> 48
> mm_malloc: Allocated 0x2001f840, size
> 48
> mm_malloc: Allocated 0x2001f870, size
> 48
> mm_malloc: Allocated 0x2001f8a0, size
> 48
> mm_malloc: Allocated 0x2001f8d0, size
> 48
> mm_malloc: Allocated 0x2001f900, size
> 48
> mm_malloc: Allocated 0x2001f930, size
> 48
> mm_malloc: Allocated 0x2001f960, size
> 48
> mm_malloc: Allocated 0x2001f990, size
> 48
> mm_malloc: Allocated 0x2001f9c0, size
> 48
> mm_malloc: Allocated 0x2001f9f0, size
> 48
> mm_malloc: Allocated 0x2001fa20, size
> 48
> mm_malloc: Allocated 0x2001fa50, size
> 48
> mm_malloc: Allocated 0x2001fa80, size
> 48
> mm_malloc: Allocated 0x2001fab0, size
> 48
> mm_malloc: Allocated 0x2001fae0, size
> 48
> mm_malloc: Allocated 0x2001fb10, size
> 48
> mm_malloc: Allocated 0x2001fb40, size
> 48
> mm_malloc: Allocated 0x2001fb70, size
> 48
> mm_malloc: Allocated 0x2001fba0, size
> 48
> mm_malloc: Allocated 0x2001fbd0, size
> 48
> mm_malloc: Allocated 0x2001fc00, size
> 48
> mm_malloc: Allocated 0x2001fc30, size
> 48
> mm_malloc: Allocated 0x2001fc60, size
> 48
> mm_malloc: Allocated 0x2001fc90, size
> 48
> mm_malloc: Allocated 0x2001fcc0, size
> 48
> mm_malloc: Allocated 0x2001fcf0, size
> 48   

Re: Adding support for STM32G474RET6

[Nathan Hartman]

Progress report on this port: I'm getting closer... Not quite
compiling yet, still some errors with a few undefined register
definitions here and there. But I'm definitely getting closer...

As before, my work is in my fork under stm32g474 branch [1], if anyone
wants a sneak preview. :-)

[1] https://github.com/hartmannathan/incubator-nuttx/tree/stm32g474

Nathan

Re: heap malloc when executing binary/elf file

[Florian Wehmeyer]

looking more into the memory allocation debug, there is a lot more
dynamic allocation (obviously)  when loading the elf program than
when loading the same program as built-in..
So, seems the problem is due to a high heap fragmentation, what
explains that a call to dmesg can also make the system crash..
So, maybe my question should be, is increasing the heap a solution for
that? If yes, how do I increase it?
BR,
Florian
prints of debug output with my comments:
calling the Elf program (Neo_Ledtest):
  PID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK
COMMAND   
0   0 FIFO Kthread N-- Ready   00 Idle
Task 
1 224 FIFO Kthread --- Waiting  Signal 002028
hpwork
2 100 FIFO Task--- Running 002028
init  
3  80 RR   pthread --- Waiting  Semaphore  001564
netinit 0x0   
4 100 FIFO Task--- Waiting  Semaphore  002004
Telnet daemon0
6 100 FIFO Task--- Waiting  Semaphore  006116
Neo_Ledtest   
nsh> cat
/proc/6/stack  
StackBase:  0x0x200214b0   
 
StackSize:  6116 
StackEnd = 0x200214b0 - 6116d = 0x2001FCCC
nsh> dmesg//called right after calling the elf program,
after flushing the
syslog..  
mm_free: Freeing
0x2001d010 
mm_malloc: Allocated 0x2000cbd0, size
64
mm_malloc: Allocated 0x20009710, size
32
mm_malloc: Allocated 0x2000cc10, size
48
mm_malloc: Allocated 0x2001d010, size
48
mm_malloc: Allocated 0x2001d040, size
528   
mm_malloc: Allocated 0x2001d250, size
448   
mm_malloc: Allocated 0x2001d410, size
6624  
mm_malloc: Allocated 0x2001edf0, size
528   
mm_malloc: Allocated 0x2001f000, size
2064  
mm_malloc: Allocated 0x2001f810, size
48
mm_malloc: Allocated 0x2001f840, size
48
mm_malloc: Allocated 0x2001f870, size
48
mm_malloc: Allocated 0x2001f8a0, size
48
mm_malloc: Allocated 0x2001f8d0, size
48
mm_malloc: Allocated 0x2001f900, size
48
mm_malloc: Allocated 0x2001f930, size
48
mm_malloc: Allocated 0x2001f960, size
48
mm_malloc: Allocated 0x2001f990, size
48
mm_malloc: Allocated 0x2001f9c0, size
48
mm_malloc: Allocated 0x2001f9f0, size
48
mm_malloc: Allocated 0x2001fa20, size
48
mm_malloc: Allocated 0x2001fa50, size
48
mm_malloc: Allocated 0x2001fa80, size
48
mm_malloc: Allocated 0x2001fab0, size
48
mm_malloc: Allocated 0x2001fae0, size
48
mm_malloc: Allocated 0x2001fb10, size
48
mm_malloc: Allocated 0x2001fb40, size
48
mm_malloc: Allocated 0x2001fb70, size
48
mm_malloc: Allocated 0x2001fba0, size
48
mm_malloc: Allocated 0x2001fbd0, size
48
mm_malloc: Allocated 0x2001fc00, size
48
mm_malloc: Allocated 0x2001fc30, size
48
mm_malloc: Allocated 0x2001fc60, size
48
mm_malloc: Allocated 0x2001fc90, size
48
mm_malloc: Allocated 0x2001fcc0, size
48
mm_malloc: Allocated 0x2001fcf0, size
48
mm_malloc: Allocated 0x2001fd20, size
48
mm_malloc: Allocated 0x2001fd50, size
48
mm_malloc: Allocated 0x2001fd80, size
48
mm_malloc: Allocated 0x2001fdb0, size
48
mm_malloc: Allocated 0x2001fde0, size
48
mm_malloc: Allocated 0x2001fe10, size
48
mm_malloc: Allocated 0x2001fe40, size
48

NuttX: More than just code

[Nathan Hartman]

Greg and I were discussing offlist the role of the project management
committee and ways that interested people can become part of it.

Right now, we have technical people in the PPMC, which is valuable
because the PPMC needs to deal with technical matters. But!

We are lacking in people (who may or may not be technical) who have
management / marketing / entrepreneurial / administrative skills, who
are interested in the "M" (Management) of PPMC.

But since this project is a meritocracy where people are invited to
that role based on contributions, how could someone who isn't
necessarily making source code patches, but who wants to help manage
the project, ever become part of the PPMC?

The answer is that "contributing" to the project doesn't mean source
code only. Obviously, source code (and documentation) patches qualify
as important "contributions" to the project. But so do these things:

* Discussions, right here on dev@, whether they're technical, or about
  the future direction of this project. Where do you see NuttX going
  in the next few years? What "next big thing" do you believe will
  happen and how can we meet that as a project?

* Marketing, PR, NuttX evangelism, outreach, etc., are very important
  because a growing user and developer base are the key things that
  will ensure the longevity and future of this project. This includes
  building bridges between Apache NuttX and other projects of the ASF.

* Graphic design, whether it's marketing type materials like logos, a
  mascot, fan art, or whether it's technical illustrations.

* Translations of our documentation and website to other languages.

* Videos. Whether they're instructional videos (showing how to do
  things with NuttX), showcase videos (showing cool stuff in the real
  world that runs on NuttX), or even discussions about the business
  case for NuttX.

* What about Music? Huh?! NuttX Music? Well, I'm not being entirely
  sarcastic here. The OpenBSD project releases a song with every new
  OS version. Heck, why not?

My point is that although quality source code is very important,
Apache NuttX is in need of a great many other skill sets, including
both "hard" and "soft" skills.

I hope that this message isn't going to /dev/null. I hope we'll hear
from other community members, both users and developers alike, whether
it's praise, criticism, or anything you'd like to share. If you've
been wanting to get involved, hit reply and tell us your thoughts!

Cheers,
Nathan

heap malloc when executing binary/elf file

[Florian Wehmeyer]

Hi all, 

again a question related to the execution of external / elf programs: 

When I use malloc within the running elf program, allocating more than
1K bytes, malloc seems to work (doesn't return NULL), but when I use
that memory (memset) I get a assertion/Kernel panic..

Funnily this does not happen if I use the same program as built-in
program (the one which is already in ROM flash).. Here I can allocate
and use 8K or more without any problem..

So, it seems the binary loader itself consumes a lot of memory,
decreasing the available heap.. I was not able to solve that problem
even increasing all available and possibly related stacksizes in
.config
After loading the elf file, even running dmesg can cause that
assertion.. (using RAMLOG with 8K buffer and memory debug output) .
free shows about 130K of free RAM..

in the  memory debug output I can see that the periodical allocation at
about 10K of distance of the next stack-end (means stackbase minus
stacksize, knowing stack decreases), which is my app..
so, I thought allocate 2K on the heap should not be a problem.


Any ideas about any configuration that's important here? 


Many thanks & BR,


--
Florian WehmeyerTFW Tech-Solutions

Build failed in Jenkins: NuttX-Nightly-Build #149

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 315.89 KB...]

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mount

Configuration/Tool: sim/module

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/module

Configuration/Tool: sim/minibasic

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/minibasic

Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
--2020-05-11 12:38:34--  
https://github.com/ARMmbed/littlefs/archive/v2.2.1.tar.gz
Resolving github.com (github.com)... 192.30.255.113
Connecting to github.com (github.com)|192.30.255.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1 [following]
--2020-05-11 12:38:34--  
https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1
Resolving codeload.github.com (codeload.github.com)... 192.30.255.121
Connecting to codeload.github.com (codeload.github.com)|192.30.255.121|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: 'littlefs/v2.2.1.tar.gz'

v2.2.1.tar.gz   [<=> ]   0  --.-KB/s   
v2.2.1.tar.gz   [ <=>] 111.57K  --.-KB/sin 0.02s   

2020-05-11 12:38:34 (6.15 MB/s) - 'littlefs/v2.2.1.tar.gz' saved [114250]

  Normalize sim/tcpblaster

Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/touchscreen

Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/bas

Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mtdpart

Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/spiffs

Configuration/Tool: sim/ustream

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/ustream

Configuration/Tool: sim/userfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/userfs

Configuration/Tool: sim/rpproxy

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
--2020-05-11 12:42:03--  
https://github.com/OpenAMP/libmetal/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.113
Connecting to github.com (github.com)|192.30.255.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0 
[following]
--2020-05-11 12:42:04--  

Build failed in Jenkins: NuttX-Nightly-Build #144

[Apache Jenkins Server]

See 

Changes:


--
Started by user btashton
Rebuilds build #142
Running as SYSTEM
[EnvInject] - Loading node environment variables.
[EnvInject] - Preparing an environment for the build.
[EnvInject] - Keeping Jenkins system variables.
[EnvInject] - Keeping Jenkins build variables.
[EnvInject] - Executing and processing the following script content: 
# This is a read-only credential and not explicitly a secret.  There does not 
seem to be a way to do this with the Jenkins docker plugin...
# This docker env plugin also manages to mess up pulling from docker hub...
# see JENKINS-54021
rm ~/.docker/config.json
docker pull alpine:3.6

set +x
docker login https://docker.pkg.github.com -u btashton -p $GITHUB_RO_TOKEN
set -x

[jenkins-slave] $ /bin/bash -xe /tmp/jenkins427882338103979957.sh
+ rm /home/jenkins/.docker/config.json
+ docker pull alpine:3.6
3.6: Pulling from library/alpine
Digest: sha256:66790a2b79e1ea3e1dabac43990c54aca5d1ddf268d9a5a0285e4167c8b24475
Status: Image is up to date for alpine:3.6
docker.io/library/alpine:3.6
+ set +x
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in 
/home/jenkins/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
[EnvInject] - Script executed successfully.
[EnvInject] - Injecting contributions.
Building remotely on H27 (ubuntu) in workspace 

Pull Docker image 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest from 
repository ...
$ docker pull 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
latest: Pulling from apache/incubator-nuttx-testing/nuttx-ci-linux
Digest: sha256:2d978e178b9837ebec6ba3effb9359540c20d2a08429d969de09eb486a32a06f
Status: Image is up to date for 
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
$ docker run --rm --entrypoint /bin/true alpine:3.6
$ docker run --tty --rm --entrypoint /sbin/ip alpine:3.6 route
FATAL: Interrupted
java.lang.RuntimeException: Interrupted
at 
com.cloudbees.jenkins.plugins.docker_build_env.DockerBuildWrapper.startBuildContainer(DockerBuildWrapper.java:218)
at 
com.cloudbees.jenkins.plugins.docker_build_env.DockerBuildWrapper.setUp(DockerBuildWrapper.java:185)
at hudson.model.Build$BuildExecution.doRun(Build.java:157)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)