Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32

Forum List Topic List

[ prev topic | next topic ]  

SW4STM32 bug reporting or source code?

Posted by kmklimek on 2019-04-02 09:34

Is there any place where I can fill a bug report I found in fr.ac6.mcu.externaltools_2.0.1.201801120948.jar plugin in MCUExternalToolsTool::install method? Is there any place where I can check source code?

I would happily provide a patch or at least detailed bug report if I only knew where I can do it. I’ll use this topic to explain it.

All started with introduction of CI process inside company I work for. There are many OpenSTM32 projects here so I started making dockerized openstm32. Everything went fine till first test. Whole process hanged AFTER “build finished” and did not end. However every next run was fine. I could not accept a solution like this (it’s just lazy workaround) so I started debugging this. From jstack dump attached I’ve found out that

  1. main thread is sleeping at __org.eclipse.cdt.managedbuilder.internal.core.HeadlessBuilder.start(HeadlessBuilder.java:547) -> source codeQuestion
  2. Another thread that I suspected was Worker-3 at MCUExternalToolsTool.java:266 process.waitFor();
  3. Pinned down line has guided me to the line 250 final String[] cmd = { “tar”, “-jxvf”, archive.getAbsolutePath(), “-C”, dest.getParent() }; which tells me that some bz2 archive is unpacked
  4. My first guess was st-gnu-arm-gcc-7-2018-q2-update_gdb-5_4-2016q3-linux.tar.bz2 so I simply unpacked it and removed the archive before the first run (in Dockerfile as a part of installation process)
  5. I’ve rerun CI builder and there it was, working all fine.


So my final conclusion is: there is a bug in tar process handling which leads to unusable (in dockerized CI) headless builds. Bug is related to the MCUExternalToolsTool.java:263 MCUExternalToolsTool.this.startStreamReader(console, process);. Started runner does nothing but I gues it should read output from started process. While it does not read the output started process simply hangs till output buffers are read.

jstacklong.dump (13.40 Kb)
Reads: 3975
Link
Posted by jLn_38 on 2019-04-02 10:37

Hi Kmklimek,

For the questions I don’t have the answers I’d let the relevant people reply. The only thing I could certify is that st-gnu-arm-gcc-7-2018-q2-update_gdb-5_4-2016q3-linux.tar.bz2 is expected to be unpacked into a compiler folder next to the archive. This process is done during the first startup after installation, or each toolchain update, and reports tar outputs into the Console view.

Anyway and regardless docker I’ve have the same trouble here when running the headless script just after the installation, workaround like you did in your dockerfile...

Link
Posted by kmklimek on 2019-04-02 10:44
I know that it is required but installation process is bugged (codeside) which leads to situation like this. I hope I pinned out problem completly and dev team will have easy job on fixing it.
Link