Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Add Cygwin to CI #39

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

WIP: Add Cygwin to CI #39

wants to merge 2 commits into from

Conversation

btashton
Copy link
Contributor

This is currently very much a WIP. Some of what is in the ci workflow file is working around issues where cibuild.sh does not support the Windows runners yet and will need to be moved over.

This also syncs the workflow file with the rest of the project.

@xiaoxiang781216
Copy link
Contributor

@btashton can you split the Fetch-Source to another patch? so we can sync build.yaml with other project first, and then focus on Windows CI specific change.

@btashton
Copy link
Contributor Author

@btashton can you split the Fetch-Source to another patch? so we can sync build.yaml with other project first, and then focus on Windows CI specific change.

Yeah I needed to test a modification for this repo, now that it is tested I can do that, but it will need to wait until tomorrow, it's late here.

@btashton
Copy link
Contributor Author

I'm going to close this for now. We can always refer to it again later.

@btashton btashton closed this Aug 28, 2020
@btashton
Copy link
Contributor Author

btashton commented Aug 30, 2020

All right since we had another failure with Windows I will bring this back, but I think we should scope it to just run the sim build for now.
apache/nuttx#1672

@btashton btashton reopened this Aug 30, 2020
@patacongo
Copy link
Contributor

All right since we had another failure with Windows I will bring this back, but I think we should scope it to just run the sim build for now.
apache/incubator-nuttx#1672

Using sim will not catch breakage like that of PR #1450. That error is cause due to running and Windows native toolchain (in this case the the ARM embedded toolchain) to compile code under Cygwin.

I have been using sim with Cygwin and never experienced any problems.

@btashton
Copy link
Contributor Author

Ok. I thought you had said something about not being about to use the native ARM Embedded toolchain with Cygwin, maybe I am missing something. Either way I'll make this is a priority since it is a big hole.

If I get this cleaned up next week (right now it has unrelated code changes) can you give me a little guidance on the toolchain.

@patacongo
Copy link
Contributor

patacongo commented Aug 30, 2020

Ok. I thought you had said something about not being about to use the native ARM Embedded toolchain with Cygwin, maybe I am missing something. Either way I'll make this is a priority since it is a big hole.

Semantic problem. I am not being clear. The Windows native ARM cross-compiler toolchain -- like the ARM embedded toolchain. Versus a toolchain (like buildroot) that is compiled under Cygwin. And not the Windows native x86_64 toolchain. No problem with the last two. The word native was not clear in this context.

@patacongo
Copy link
Contributor

I think you could replicate the problem with the sim platform if you used a Windows native GCC tool chain like MinGW. The pre-built Cygwin gcc is built under Cygwin and everything will use POSIX paths. That environment is indistiguishable for the most part from Linux. But MinGW (I think) will not understand POSIX paths and will general Windows paths. I have never experimented with that so I am pushing things.

@patacongo
Copy link
Contributor

Here is the crux of the problem under Cygwin:

$ arm-none-eabi-gcc --print-file-name=libgcc.a
c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a
$ gcc --print-file-name=libgcc.a
/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/libgcc.a

The latter is handled with no problem, the former fails when the make $(dir ...) command attempts to extract the path to libgcc.a. It needs a POSIX style path. 'cypath -u' can fix that.

@btashton btashton force-pushed the windows-ci branch 9 times, most recently from bb42d72 to 2bf71c6 Compare September 23, 2020 05:45
@btashton
Copy link
Contributor Author

btashton commented Sep 23, 2020

@patacongo @v01d Getting this closer to being in a reasonable place, but it looks like there is an issue with make distclean

These folders are getting left behind:

arch/arm/include/board
arch/arm/include/chip

Here is a snip of the log:

2020-09-23T05:53:52.4368113Z + run_builds
2020-09-23T05:53:52.4368497Z + local ncpus
2020-09-23T05:53:52.4368876Z + case $os in
2020-09-23T05:53:52.4435993Z ++ grep -c '^processor' /proc/cpuinfo
2020-09-23T05:53:52.4529398Z + ncpus=2
2020-09-23T05:53:52.4529975Z + options+='-j 2'
2020-09-23T05:53:52.4537238Z + for build in $builds
2020-09-23T05:53:52.4538682Z + /cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/nuttx/tools/testbuild.sh -x -j 2 -e '-Wno-cpp -Werror' testlist/arm-12.dat
2020-09-23T05:53:52.6624240Z ====================================================================================
2020-09-23T05:53:52.6933227Z Configuration/Tool: b-l072z-lrwan1/adc,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
2020-09-23T05:53:52.8755745Z ------------------------------------------------------------------------------------
2020-09-23T05:53:52.8756749Z   Cleaning...
2020-09-23T05:53:52.8763608Z   Configuring...
2020-09-23T05:54:05.8825442Z   Disabling CONFIG_TOOLCHAIN_WINDOWS
2020-09-23T05:54:05.9027901Z   Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
2020-09-23T05:54:12.0438219Z   Building NuttX...
2020-09-23T05:57:29.1106768Z   Normalize b-l072z-lrwan1/adc
2020-09-23T05:57:50.9600085Z ====================================================================================
2020-09-23T05:57:50.9914331Z Configuration/Tool: b-l072z-lrwan1/nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
2020-09-23T05:57:51.1640490Z ------------------------------------------------------------------------------------
2020-09-23T05:57:51.1641713Z   Cleaning...
2020-09-23T05:58:18.9865401Z On branch master
2020-09-23T05:58:18.9867462Z Your branch is up to date with 'origin/master'.
2020-09-23T05:58:18.9870101Z 
2020-09-23T05:58:18.9872698Z Ignored files:
2020-09-23T05:58:18.9885491Z   (use "git add -f <file>..." to include in what will be committed)
2020-09-23T05:58:18.9900250Z 	arch/arm/include/board
2020-09-23T05:58:18.9909236Z 	arch/arm/include/chip
2020-09-23T05:58:18.9914370Z 
2020-09-23T05:58:18.9915972Z nothing to commit, working tree clean
2020-09-23T05:58:19.2661926Z ##[error]Process completed with exit code 1.

@protobits
Copy link
Contributor

Great work, it will saves time in the future avoiding build breaks.

I'm not really familiar with cygwin to understand the breakage. But I suspect it has something to do with the script that handle symlinks. @patacongo any ideas?

@patacongo
Copy link
Contributor

Great work, it will saves time in the future avoiding build breaks.

I'm not really familiar with cygwin to understand the breakage. But I suspect it has something to do with the script that handle symlinks. @patacongo any ideas?

I never noticed, but yes it is a real problem. I have several old board and and chip directories. We need to open an issue. These two lines in arch/arm/src/Makefile (and other arch Makefiles) are not working under cygwin:

         $(Q) $(DIRUNLINK) $(ARCH_SRC)/board
         $(Q) $(DIRUNLINK) $(ARCH_SRC)/chip

Cygwin supports is own style of symbolic links and these are used EXCEPT for the case where a Windows native toolchain is used such as the popular (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm).

Those are Window native tools and cannot follow non-standard Cygwin symbolic links so in this case, the tools/dirlinks.sh script does a full directory copy and the corresponding unlink script does a directory removal.

Without knowing more, it looks like the DIRUNLINK is failing to remove the Cygwin symbolic link or the copied directory.

@patacongo patacongo closed this Sep 23, 2020
@patacongo
Copy link
Contributor

patacongo commented Sep 23, 2020

The dir unlink script seems to be working fine, however (at least using a relative path):

$ find . -name chip
./arch/arm/include/chip
./arch/arm/src/chip
./arch/z80/include/chip
./include/arch/chip

$ tools/unlink.sh ./arch/z80/include/chip

$ find . -name chip
./arch/arm/include/chip
./arch/arm/src/chip
./include/arch/chip

@patacongo
Copy link
Contributor

Oops.. didn't mean to close.

@patacongo patacongo reopened this Sep 23, 2020
@patacongo
Copy link
Contributor

See Issue apache/nuttx#1880

@patacongo
Copy link
Contributor

patacongo commented Sep 23, 2020

@v01d @btashton I have analyzed this. It is due to changes make in the build system that were never verified on Cygwin. I have documented the problem in apache/nuttx#1880

I don't have any good solution other than reverting some changes recently made to the Makefile.

@btashton
Copy link
Contributor Author

@patacongo I have to step away for the day (new job so back to evenings, mornings and weekends) but I appreciate you digging into it and I'll do what I can to make sure we have the protections in place via CI going forward. MinGW will also need to be added at some point. I suspect that will actually be easier since the runners are already configured with the core packages.

@patacongo
Copy link
Contributor

@patacongo I have to step away for the day (new job so back to evenings, mornings and weekends) but I appreciate you digging into it and I'll do what I can to make sure we have the protections in place via CI going forward. MinGW will also need to be added at some point. I suspect that will actually be easier since the runners are already configured with the core packages.

The good news is that your CI changes work! The correctly caught an error introduced into the build system.

@btashton btashton force-pushed the windows-ci branch 2 times, most recently from 1ac2d95 to 051ef3f Compare September 27, 2020 18:08
@btashton
Copy link
Contributor Author

I just tweaked the workflow to so we can get a full run with all of the errors. I looks like there are still a couple issues with the build we need to address, but @liuguo09 patch did fix the folder issue.

@btashton
Copy link
Contributor Author

@patacongo @xiaoxiang78121 The build is taking a long time, but I am seeing a handful of different classes of errors. What do you think about enabling the cygwin CI, but making it not fail the workflow. That way we can more easily validate the fixes, but also not fail unrelated PRs?

https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error

@btashton
Copy link
Contributor Author

Looks cpp related

====================================================================================
Configuration/Tool: nucleo-144/f722-nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
------------------------------------------------------------------------------------
  Cleaning...
  Configuring...
  Disabling CONFIG_TOOLCHAIN_WINDOWS
  Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
.config:1432:warning: override: ARMV7M_TOOLCHAIN_GNU_EABIL changes choice state
  Building NuttX...
libxx_cxa_atexit.cxx:40:10: fatal error: nuttx/config.h: No such file or directory
   40 | #include <nuttx/config.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:84: libxx_cxa_atexit.o] Error 1
libxx_eabi_atexit.cxx:40:10: fatal error: nuttx/config.h: No such file or directory
   40 | #include <nuttx/config.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

make distclean is then leaving deps around

 ====================================================================================
Configuration/Tool: nucleo-144/f746-evalos,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
------------------------------------------------------------------------------------
  Cleaning...
On branch master
Your branch is up to date with 'origin/master'.

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
	system/nsh/Make.dep
	system/readline/Make.dep

@patacongo
Copy link
Contributor

These all look like toolchain-related issues? Which toolchain are you using? I recommend the ARM embedded toolchain which is a windows native toolchain. All of the problems that I see could be explained if CONFIG_CYGWIN_WINTOOL were not set:

The -I and -isystem arguments would be wrong in this case:

ERROR: arm-none-eabi-gcc failed: 1
       command: arm-none-eabi-gcc -MT ./cle.cygdrive.d.a.incubator-nuttx-testing.incubator-nuttx-testing.apps.system.cle.o  -M '-fno-builtin' '-Wall' '-Wstrict-prototypes' '-Wshadow' '-Wundef' '-g' '-mcpu=cortex-m7' '-mthumb' '-mfloat-abi=soft' '-isystem' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/nuttx/include' '-D__KERNEL__' '-Wno-cpp' '-Werror' '-pipe' '-I' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/graphics/lvgl' '-I' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/graphics/lvgl/lvgl' '-I' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/include' ./cle.c

The following error often happens in that case:

 make[1]: *** [Makefile:63: /cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/platform_depend] Error 2
./cle.c:40:10: fatal error: nuttx/config.h: No such file or directory
   40 | #include <nuttx/config.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

That is because the windows toolchain cannot follow the cygwin paths.

Can you verify that CONFIG_CYGWIN_WINTOOL is selected after running make olddefconfig? It will not be selected in the defconfig file, but should be selected if during make olddefconfig if the correct toolchain is selected. See arch/arm/src/armv7-m/Kconfig

@patacongo
Copy link
Contributor

The following error often happens in that case:

 make[1]: *** [Makefile:63: /cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/platform_depend] Error 2
./cle.c:40:10: fatal error: nuttx/config.h: No such file or directory
   40 | #include <nuttx/config.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

That is because the windows toolchain cannot follow the cygwin paths.

This also can occur if the links are Cygwin symbolic links. In that case, the Windows toolchain cannot follow those symbolic links.

@patacongo
Copy link
Contributor

Aha... This is probably the problem:

   Configuring...
  Disabling CONFIG_TOOLCHAIN_WINDOWS
  Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
 .config:1350:warning: override: ARMV7M_TOOLCHAIN_GNU_EABIL changes choice state
  Building NuttX...

That will need to be CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW for the Windows native toolchin. CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL selects the Linux toolchain (or a custom toolchain built under Cygwin, not a native toolchain).

@patacongo
Copy link
Contributor

Aha... This is probably the problem:

   Configuring...
  Disabling CONFIG_TOOLCHAIN_WINDOWS
  Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
 .config:1350:warning: override: ARMV7M_TOOLCHAIN_GNU_EABIL changes choice state
  Building NuttX...

That will need to be CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW for the Windows native toolchin. CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL selects the Linux toolchain (or a custom toolchain built under Cygwin, not a native toolchain).

And this seems to be because the test list you are using specifies the Linux toolchain:

====================================================================================
Configuration/Tool: b-l072z-lrwan1/nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
------------------------------------------------------------------------------------
  Cleaning...
  Configuring...
  Disabling CONFIG_TOOLCHAIN_WINDOWS
  Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
  Building NuttX...
  Normalize b-l072z-lrwan1/nsh
====================================================================================

Unfortunately, you cannot re-use the Linux test lists for Cygwin. The test lists need CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW if you are using the ARM embedded windows native toolchain.

@patacongo
Copy link
Contributor

Looks cpp related

It is, but only because the Windows cpp can't follow the symbolic links and cannot handle the POSIX-style include paths.

@btashton
Copy link
Contributor Author

Ah you are right. I'll see if I can fix that, we are unfortunately using -c for two different things in cibuild.sh and testbuild.sh so I'll have to sort that as well

@patacongo
Copy link
Contributor

In my original test lists (https://bitbucket.org/nuttx/tools/src/master/buildtest/armlist.template) I specified the toolchain as CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIx. I then changed the x to either W or L using sed.

@btashton
Copy link
Contributor Author

@patacongo
Copy link
Contributor

patacongo commented Sep 27, 2020

This is probably real code breakage. Again, it is a screw-up in include paths:

/usr/include/cygwin/socket.h:27:8: error: redefinition of 'struct sockaddr'
   27 | struct sockaddr {
      |        ^~~~~~~~
In file included from /usr/include/w32api/winsock2.h:57,
                 from sim/up_wpcap.c:48:
/usr/include/w32api/psdk_inc/_ip_types.h:70:8: note: originally defined here
   70 | struct sockaddr {
      |        ^~~~~~~~
In file included from /usr/include/sys/socket.h:13,
                 from /usr/include/cygwin/in.h:21,
                 from /usr/include/netinet/in.h:12,
                 from sim/up_wpcap.c:57:
/usr/include/cygwin/socket.h:39:8: error: redefinition of 'struct sockaddr_storage'
   39 | struct sockaddr_storage {
      |        ^~~~~~~~~~~~~~~~
In file included from sim/up_wpcap.c:48:
/usr/include/w32api/winsock2.h:269:10: note: originally defined here
  269 |   struct sockaddr_storage {
      |          ^~~~~~~~~~~~~

sim_wcap.c hasn't been build in ages. It is mixing Cygwin and Windows socket definitions. As I recall, this is a host file and, hence should be using all Windows definitions.

The likelihood that this still works (even if built correctly) is low.

I will look into this too.

@patacongo
Copy link
Contributor

This is probably real code breakage. Again, it is a screw-up in include paths:

/usr/include/cygwin/socket.h:27:8: error: redefinition of 'struct sockaddr'
   27 | struct sockaddr {
      |        ^~~~~~~~
In file included from /usr/include/w32api/winsock2.h:57,
                 from sim/up_wpcap.c:48:
/usr/include/w32api/psdk_inc/_ip_types.h:70:8: note: originally defined here
   70 | struct sockaddr {
      |        ^~~~~~~~
In file included from /usr/include/sys/socket.h:13,
                 from /usr/include/cygwin/in.h:21,
                 from /usr/include/netinet/in.h:12,
                 from sim/up_wpcap.c:57:
/usr/include/cygwin/socket.h:39:8: error: redefinition of 'struct sockaddr_storage'
   39 | struct sockaddr_storage {
      |        ^~~~~~~~~~~~~~~~
In file included from sim/up_wpcap.c:48:
/usr/include/w32api/winsock2.h:269:10: note: originally defined here
  269 |   struct sockaddr_storage {
      |          ^~~~~~~~~~~~~

sim_wcap.c hasn't been build in ages. It is mixing Cygwin and Windows socket definitions. As I recall, this is a host file and, hence should be using all Windows definitions.

The likelihood that this still works (even if built correctly) is low.

I will look into this too.

This was, I am pretty sure, introduced with commit: 8ce0ff5ce44416511be343c842c8d714687182cf with this change:

diff --git a/arch/sim/src/sim/up_wpcap.c b/arch/sim/src/sim/up_wpcap.c
index ef7b4b3a0c..a15421e80c 100644
--- a/arch/sim/src/sim/up_wpcap.c
+++ b/arch/sim/src/sim/up_wpcap.c
@@ -55,6 +55,8 @@

 #include <netinet/in.h>

+#include "up_internal.h"
+
 /****************************************************************************
  * Pre-processor Definitions
  ****************************************************************************/

up_internal.h includes:

 47 #  include <sys/types.h>
 48 #  include <stdbool.h>
 49 #  include <netinet/in.h>

And netinet/in.h includes:

 46 #include <sys/types.h>
 47 #include <sys/socket.h>
 48 #include <stdint.h>

Which is where the collision error is introduced since up_wpcap.c includes winsock2.h already. The solution: Revert that single file change.

@patacongo
Copy link
Contributor

@btashton PR apache/nuttx#1903 solves this build problem.

@btashton
Copy link
Contributor Author

Thanks Greg, I'll check it out shortly. I am getting my local windows environment back up to make this testing a little quicker.

@btashton
Copy link
Contributor Author

@patacongo I ran the Cygwin build locally and when I try to run the executable it crashes. Strace shows this, any idea what is going on? (nettest and nsh had the same result)

--- Process 1892 created
--- Process 1892 loaded C:\Windows\System32\ntdll.dll at 00007ffbca2c0000
--- Process 1892 loaded C:\Windows\System32\kernel32.dll at 00007ffbca070000
--- Process 1892 loaded C:\Windows\System32\KernelBase.dll at 00007ffbc75e0000
--- Process 1892 thread 5812 created
--- Process 1892 loaded C:\Windows\System32\ws2_32.dll at 00007ffbc9ad0000
--- Process 1892 loaded C:\Windows\System32\rpcrt4.dll at 00007ffbc8370000
--- Process 1892 loaded C:\Windows\System32\IPHLPAPI.DLL at 00007ffbc6680000
--- Process 1892 thread 4800 created
--- Process 1892 thread 9592 created
--- Process 1892 loaded C:\tools\cygwin\bin\cygwin1.dll at 0000000180040000
--- Process 1892 loaded C:\tools\cygwin\bin\cygz.dll at 00000003fbf80000
    5       5 [main] nuttx (1892) **********************************************
  369     374 [main] nuttx (1892) Program name: C:\tools\cygwin\home\btashton\sources\nuttx\nuttx.exe (windows pid 1892)
  241     615 [main] nuttx (1892) OS version:   Windows NT-10.0
  277     892 [main] nuttx (1892) **********************************************
--- Process 1892 loaded C:\Windows\System32\advapi32.dll at 00007ffbc90e0000
--- Process 1892 loaded C:\Windows\System32\msvcrt.dll at 00007ffbc99d0000
--- Process 1892 loaded C:\Windows\System32\sechost.dll at 00007ffbc9f30000
--- Process 1892 loaded C:\Windows\System32\cryptbase.dll at 00007ffbc6ba0000
--- Process 1892 loaded C:\Windows\System32\bcryptprimitives.dll at 00007ffbc73c0000
27939   28831 [main] nuttx (1892) sigprocmask: 0 = sigprocmask (0, 0x0, 0x180320DD0)
 1040   29871 [main] nuttx (1892) open_shared: name shared.5, n 5, shared 0x180030000 (wanted 0x180030000), h 0x10C, *m 6
  243   30114 [main] nuttx (1892) user_heap_info::init: heap base 0x800000000, heap top 0x800000000, heap size 0x20000000 (536870912)
  251   30365 [main] nuttx (1892) open_shared: name S-1-5-21-809113384-3503045568-2100469263-1000.1, n 1, shared 0x180020000 (wanted 0x180020000), h 0x108, *m 6
  238   30603 [main] nuttx (1892) user_info::create: opening user shared for 'S-1-5-21-809113384-3503045568-2100469263-1000' at 0x180020000
  250   30853 [main] nuttx (1892) user_info::create: user shared version AB1FCCE8
  280   31133 [main] nuttx (1892) fhandler_pipe::create: name \\.\pipe\cygwin-c3851c815b7231fc-1892-sigwait, size 11440, mode PIPE_TYPE_MESSAGE
  315   31448 [main] nuttx (1892) fhandler_pipe::create: pipe read handle 0x120
  277   31725 [main] nuttx (1892) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c3851c815b7231fc-1892-sigwait
 1715   33440 [main] nuttx (1892) fhandler_pipe::create: pipe write handle 0x124
 1706   35146 [main] nuttx (1892) dll_crt0_0: finished dll_crt0_0 initialization
--- Process 1892 thread 9836 created
 6195   41341 [main] nuttx (1892) set_signal_mask: setmask 0, newmask FFFFFFFFFFFEFEFF, mask_bits 0
 1370   42711 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFCA30, 0xFFFFCA38)
 1850   44561 [main] nuttx (1892) set_signal_mask: setmask FFFFFFFFFFFEFEFF, newmask 0, mask_bits FFFFFFFFFFFEFEFF
 1851   46412 [sig] nuttx (1892) wait_sig: entering ReadFile loop, my_readsig 0x120, my_sendsig 0x124
 2396   48808 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFCA28, 0x0)
 6271   55079 [main] nuttx (1892) set_signal_mask: setmask 0, newmask FFFFFFFFFFFEFEFF, mask_bits 0
 4638   59717 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFC9C0, 0xFFFFC9C8)
 3305   63022 [main] nuttx (1892) set_signal_mask: setmask FFFFFFFFFFFEFEFF, newmask 0, mask_bits FFFFFFFFFFFEFEFF
 3421   66443 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFC9B8, 0x0)
  70955 [main] nuttx (1892) C:\tools\cygwin\home\btashton\sources\nuttx\nuttx.exe: *** fatal error - Internal error: Out of memory for new path buf.
 4512   70955 [main] nuttx (1892) C:\tools\cygwin\home\btashton\sources\nuttx\nuttx.exe: *** fatal error - Internal error: Out of memory for new path buf.
  75682 [main] nuttx (1892) cygwin_exception::open_stackdumpfile: Dumping stack trace to nuttx.exe.stackdump
 4727   75682 [main] nuttx (1892) cygwin_exception::open_stackdumpfile: Dumping stack trace to nuttx.exe.stackdump
70579  146261 [main] nuttx (1892) proc_terminate: nprocs 0
  470  146731 [main] nuttx (1892) proc_terminate: leaving
$                                                                                                                                                                                          2490  152125 [main] nuttx (1892) pinfo::exit: Calling ExitProcess n 0x1, exitcode 0x100```

@btashton
Copy link
Contributor Author

btashton commented Sep 28, 2020

@patacongo I see this is mentioned in the README sorry.

Hmm I take that back. It is called out in the README, but the fix does not seem to work.
https://github.com/apache/incubator-nuttx/blob/09a2c37daf99649c1f9d1c88269725318707518b/boards/sim/sim/sim/README.txt#L253

Signed-off-by: Brennan Ashton <[email protected]>
@btashton
Copy link
Contributor Author

sim:module sim:tcpblaster sim:dsptest sim:sotest all failed. A couple others failed as well but that was due to not having patch installed. I'll add that to the required Cygwin tools.

The ARM builds all passed though which is good.

2.5hr is really not great. I'm wondering why this is sooo slow and if there is something we can do about it.

@@ -391,6 +420,9 @@ function run_builds {
Linux)
ncpus=`grep -c ^processor /proc/cpuinfo`
;;
Cygwin)
ncpus=`grep -c ^processor /proc/cpuinfo`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no difference between Linux and Cygwin?

@@ -0,0 +1,5 @@
/arm/stm32f0l0g0,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we remove CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIx from all datalist?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants