Remote debugging
Host- system: x86, 64Bit; Windows 10 with
wsl2: Ubuntu 18.04.5 LTS
remote system: KARO **QS8M **Eval Kit with QS8M-MQ00 NXP i.MX 8M-Mini Quad Core Cortex-A53
Linux qs8m-mq00 5.15.32-karo+gc01cf92b4155 #1 SMP PREEMPT Fri Aug 5 13:54:11 UTC 2022 aarch64 GNU/Linux
Build directory setup- string:
DISTRO=karo-wayland MACHINE=qs8m-mq00 source karo-setup-release.sh -b build-qs8m-mq00-karo-wayland
**bitbake karo-image-weston **
Target IP: 192.168.180.61
I am trying to retrace the description of remote debugging with VisualStudioCode (VSCode) according:
https://karo-electronics.github.io/docs/software-documentation/vscode/index.html
Running:
'Continue'(F5) - does partially work.
step over; step into; step out : do not work
What also looks strange, that sometimes the debug session jumps into subroutine 'sub' and sometimes not !
No reliable debugging possible.
enter image description here
After pressing 'F5' (Debug):
enter image description here
also wondering:
enter image description here
(but the same as in Your app- note)
enter image description here
"Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.":
. /opt/karo-wayland/5.10-kirkstone/environment-setup-armv8a-poky-linux
enter image description here
Remote system:
$ aarch64-poky-linux-g++ --version
aarch64-poky-linux-g++ (GCC) 11.2.0
Have You an idea on that?
(1) Why does Step over; debugging: 'Step over'; 'Step into'; 'Step out' does not work?
(2) Debugging not reliable sometimes enters into sub-routine sometimes not(!)
Thanks& Regards
Michael
Remote debugging with single Step, StepInto, StepOver possible.
Related
I have a Windows 10 laptop where no TeX distribution was ever installed before (double-checked for config directories, files, and environment variables).
Wanting to install TeX Live 2021, I followed the full installation guide and also read the Windows-specific warnings. I've now tried several times, following different installation procedures - cleaning up everything (deleting base & user directories, environment variables, etc) before each time - but still don't manage to get a working installation. Before I report a bug at tex-live#tug, I wanted to ask for advice here, in case I'm doing something wrong. Here is what I did, step by step, and the problems I encountered in the process.
1. First I tried running the recommended online installer install-tl-windows.exe. It never got past the screen that tries to contact or load from a repository, even after a 30-min wait. Tried a dozen times, choosing different mirrors nearby and far away. No luck.
2. Then I downloaded and unpacked the install-tl.zip and run install-tl-windows.bat therein. This time the main installation window appeared. I left all default paths and environment variables (note that I do have write access to C:); in the selection scheme I unselected all languages except US & UK English, unselected XeTeX, LuaTeX, ConTeXt; also unselected TeXworks (I use Emacs), and clicked Install. After one to three hours (depending on the mirror I chose), the installation was complete.
I tried compiling a minimal latex document (see below), and got an error similar to the one in this old question:
I can't find the format file `pdflatex.fmt'
Following the advice in the answers to that question and similar questions elsewhere online such as this, I tried running texhash and fmtutil-sys --all. The latter gave the error
no appropriate script or programme found fmtutil.
for which there are also many posts online.
2a. Not understanding what the problem could be, I re-tried with all possible combinations of the following three options: (a) choosing different mirrors; (b) leaving the full selection of packages (ie without unselecting some languages, LuaTeX etc); (c) redoing the procedure by choosing "Run as Administrator". No luck.
3. At this point I tried downloading the ISO file with the full installation. Mounted the image and run install-tl-windows.bat (as normal user, as recommended; I repeat that I do have write access to C:). Everything proceeded as in step 2. above. At the end of the installation I tried running pdflatex on the minimal latex document. New error this time:
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./minimal-template.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
! LaTeX Error: File `article.cls' not found.
Very strange. A file search revealed that article.cls is in the TeXLive file system; but kpathsea did not see it indeed.
4. At this point I opened the TeX Live Shell from the Start Menu; selected a CTAN mirror; updated the TL Manager which was not up to date; updated all packages; run Regenerate filename database; and run Regenerate formats. With the latter I got this error:
tex live shell:
mtutil [INFO]: total formats: 59
fmtutil [INFO]: exiting with status 53
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 53:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --all
Here is a snip from the full set of errors appearing in the "Other" tab (I'm replacing my user directory with asterisks for privacy; note that I do have write access to these directories):
start load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
finish load https://www.nic.funet.fi/pub/TeX/CTAN/systems/texlive/tlnet
start load http://contrib.texlive.info/current
finish load http://contrib.texlive.info/current
running mktexlsr ...
done running mktexlsr.
running mtxrun --generate ...
done running mtxrun --generate.
running updmap-sys ...
done running updmap-sys.
regenerating fmtutil.cnf in C:/texlive/2021/texmf-dist
running fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
tlmgr.pl: fmtutil-sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX failed (status 255), output:
Unknown option: status-file
Try "fmtutil --help" for more information.
C:\texlive\2021\bin\win32\runscript.tlu:915: command failed with exit code 255:
perl.exe c:\texlive\2021\texmf-dist\scripts\texlive\fmtutil.pl --sys --byengine luatex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX
running fmtutil-sys --byengine luajithbtex --no-error-if-no-format --no-error-if-no-engine=luajithbtex,luajittex,mfluajit --status-file=C:\Users\***\AppData\Local\Temp\rPSb0Dpak2\WW_dJvUHgX ...
I tried to continue anyway with Regenerate fontmaps, and then tried again pdflatex on the minimal document. New error:
This is pdfTeX, Version 3.141592653-2.6-1.40.23 (TeX Live 2021/W32TeX) (preloaded format=pdflatex)
restricted \write18 enabled.
---! c:/texlive/2021/texmf-var/web2c/pdftex/pdflatex.fmt made by different executable version
(Fatal format file error; I'm stymied)
5. I tried again steps 3. and 4., but with "Run as Administrator". Same errors.
OK at this point I give up and really don't know what to do. Am I doing something wrong? For the moment I have to concur with this post: installation of TeX Live 2021 is an utter failure.
Here is the minimal latex file I used for testing (copy & paste):
\documentclass{article}
\begin{document}
test
\section{Section}
test
\end{document}
Found, that the download is not working because the system path to "cmd.exe" is not found. Therefore: open a cmd window and add the system path prior to starting the .bat file (set PATH=%PATH%;C:\Windows\system32)
I'm working with OpenEdge Progress-4GL AppBuilder and Procedure Editor, and now I'd like to start working with the OpenEdge Debugger, release 11.6.
As found on quite some places on the internet, I've taken following actions to enable debugging of my Progress application:
Using Proenv, I've launched following command:
prodebugenable -enable-all
I get following response:
OpenEdge Release 11.6 as of Fri Oct 16 19:01:51 EDT 2015
==============================================================================
PROGRESS Debug Enabler
==============================================================================
Debugging is enabled for the Progress 4GL installed in
C:\PROGRE~1\OpenEdge.
For your information, some information on environment variables:
proenv>set DLC
DLC=C:\PROGRE~1\OpenEdge
proenv>set WRK
WRKDIR=C:\OPENED~1\WRK
proenv>set ENABLE_OPENEDGE_DEBUGGER
Environment variable ENABLE_OPENEDGE_DEBUGGER not defined
As far as my application is concerned, the application is based on a shortcut, which looks as follows:
C:\Progressx86\OpenEdge\bin\prowin32.exe
-basekey "INI"
-ininame c:\progress\our_application\progress.ini
-pf c:\progress\our_application\misc\run_our_application.pf
-p our_application.r
-rr
The file "run_our_application.pf" contains a list of entries, like the following:
-db our_DB
-H DC1
-N tcp
-S 6543
To the mentioned shortcut, I've added -debugReady 5001 in order to enable debugging, based on TCP portnumber 5001. When I launch the application, I get a warning message about this, and netstat -aon gives me following entry:
TCP 0.0.0.0:5001 0.0.0.0:0 LISTENING 11344
Where 11344 is confirmed as the prowin32 application.
In OpenEdge debugger, I've following entries in menu item "Edit", "Preferences", "Attachable":
C:\progress\our_application
Z:\Progress\our_application\PRG
C:\Progressx86\OpenEdge
For your information: The Z:-drive is an external server drive, Z:\Progress\our_application\PRG is the directory where files (*.w and *.p) get compiled into *.r files, the file our_application.r can be found there.
Nevertheless, when I open a *.w file and I go to the menu "Debug", the "Attach to Process" menu item stays disabled.
What can I do in order to debug my application/*.w file?
There are several ways of debugging. Start simple. You should be able to use any of the following:
from the procedure editor
Instead of selecting [ Compile / Run ], select [ Compile / Debug ]. The AVM will start executing the current file and the debugger will suspend execution on the first line.
from any alert-box
Add -debugalert to your startup parameters and every alert-box will display an additional 'Help' button. Clicking on it will show the stack-trace and a 'Debug' button. Clicking on that will start the debugger, execution is suspended at the line of the alert-box, this can be your own alert-box or an error.
stand-alone debugger
Start the debugger application (the Windows shortcut starts proDebugger.bat) and select [ Debug / Attach To Process... ] you can then either enter a PID or select a local running session (AVM).
remote attachable debugger
This is what you seem to be trying to setup - this allows you to attach the stand alone debugger (see option 3) to a process running on another machine, this can be useful when you have an AppServer or WebSpeed agent that you want to debug.
PDSOE debugger
Not relevant for you since you are not using Progress Developer Studio for OpenEdge, but just mentioning it for completeness. This allows adding break points in your source code by double clicking in the left margin and stepping through your source code instead stepping through a debug-listing.
Starting 2020-12-09, VSCode's Rust Analyzer extension no longer loads for me. On launch, it prints out this error message:
Cannot activate rust-analyzer: bootstrap error. See the logs in "OUTPUT > Rust Analyzer Client" (should open automatically). To enable verbose logs use { "rust-analyzer.trace.extension": true }
Enabling extension tracing produces the following diagnostic just before failing:
INFO [12/10/2020, 10:03:22 AM]: Using server binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: Checking availability of a binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe --version: {
status: 3221225506,
signal: null,
output: [ null, '', '' ],
pid: 1648,
stdout: '',
stderr: ''
}
where <user> is the name of the user account I use to log into the system1.
The status value reported in the error diagnostic (3221225506) translates to 0xC0000022 (STATUS_ACCESS_DENIED). Navigating to the binary from within VSCode's integrated terminal and trying to execute rust-analyzer-windows.exe --version doesn't produce any output, which seems to reinstate that running this executable from VSCode is somehow blocked.
It appears that something changed with respect to access rights executing the server binary from within VSCode. In between Rust Analyzer working and Rust Analyzer no longer working I didn't update Rust, nor rustup, nor VSCode, nor any extensions.
I did install 2020-12 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB4592438), though, and the time Rust Analyzer started failing coincides with the time the update got installed. That could literally just be a coincidence.
What additional steps can I take to get to the root cause of the issue, and how do I get Rust Analyzer working again?
Version information:
Rust Analyzer (stable): v0.2.408
Windows 10 Pro: Version 10.0.19042 Build 19042
VSCode: 1.51.1 (user setup)
1 This is also the user account VSCode runs under, including all of its spawned processes. Navigating to the path from a command prompt running under this account reveals that rust-analyzer-windows.exe is present, and executing rust-analyzer-windows.exe --version prints a version identifier, as expected.
Unfortunately, I didn't quite get to investigate the root cause of this.
A system reboot that was forced upon me appears to have restored World Peace.
Clearing proxy config works for me.
I'm not sure this covered all situation, but it might be related to the network.
I'm doing a university project on QNX RTOS (using an academic license). I'm following Building a BSP.
So far I've managed to build (using bios_mkusbimage script in the BSP archive) .img file for x86_64 target. Then I converted .img to .vdi file (VBoxManage convertdd input.img output.vdi) and finally loaded it. The result is:
Or, as text:
Loading IFS...decompressing...done
System page at phys:000000000010c000 user:ffff808000003000 kern 808000006000
Starting next program at vffff80000007388b MFLAGS=1 .11 ClockCycles offsets within tolerance elcome to Q. Neutrino SDP 7.0 on x8664 system
Starting slogger2 server ...
Starting PCI server ...
Set PCI device list ...
Starting EIDE block driver ...
unable to access /dev/hd0t179 'ot3Tt11:7.n:nele7i7la:TensleieCted
Starting USD host ...
Starting devb-umass o audio device has been detected
Starting input services ...
Starting serial driver ...
Starting consoles ...
Starting shells ...
#
The OS seems to boot successfully, but I'm unable to type anything.
I'm looking either for a way to fix the keyboard input, or get a SSH/telnet/... connection to the QNX shell.
I am using some earlier build for Windows 64-bit downloaded form here:
dl.dropboxusercontent.com/u/63393258/osm2pgsql_testRelease.zip
from this website:
awcull.com/2015/09/30/postgis-osm2pgsql-windows.html
but it is crashing when I am importing large pbf with whole Europe downloaded from download.geofabrik.de/
I'm tired of this shit... I tried slim and non-slim mode, I tried modifying cache size, nothing worked so far. Our server has 32 GB of RAM.
Where can I download latest osm2pgsql build for Windows 64-bit? Alternatively which compiler do you suggest to make my own build on Windows Server 2012 64-bit. Thanks.
The command I run osm2pgsql last time it crashed was:
PS C:\OSM\rendering> osm2pgsql -U postgres -m -d osm -p osm -E 3857 -s -C 25000 -S C:\OSM\osm2pgsql\default.style C:\OSM\Data\europe-latest.osm.pbf
It crashed with standard Windows dialog saying "the application stopped blablabla" with details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: osm2pgsql.exe
Application Version: 0.0.0.0
Application Timestamp: 53ea21fd
Fault Module Name: ntdll.dll
Fault Module Version: 6.3.9600.18438
Fault Module Timestamp: 57ae642e
Exception Code: c00000fd
Exception Offset: 0000000000030d02
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 1033
Additional Information 1: 33ad
Additional Information 2: 33ad00700702b0ab4dc632df7667ec82
Additional Information 3: 2ebb
Additional Information 4: 2ebbf5b91303f76c5b7f75f6255100fa
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=280262
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Now I'm trying without "-C" option but I bet it will crash again...
PS C:\OSM\rendering> osm2pgsql -U postgres -m -d osm -p osm -E 3857 -s -S C:\OSM\osm2pgsql\default.style C:\OSM\Data\europe-latest.osm.pbf
Necromancing.
The latest build (Continuous Integration) can always be found on AppVeyor.
You need to get the current build (or in history a historic build by the git-commit hash).
https://ci.appveyor.com/project/openstreetmap/osm2pgsql
=> Environment arch x64
=> Artifacts tab
=> Donwload osm2pgsql_Release_x64.zip
The link might break, so if it does, you need to google "appveyor osm2pgsql",
it should usually be the first result.
Download from gis.stackexchange
Here is the Github link
Here is the Hot-Installer reference.