I'm trying to use FastMM full debug mode in XE7 C++ builder, particularly for FireMonkey. I downloaded the source code and followed the steps outline in 'FastMM4BCB.cpp'. In order to get FastMM compile, I made following changes:
comment out Line 63 in 'FastMM4BCB.cpp', which is:
#pragma option -k- -d -vi- -O2 -b- -3 -a8 -pc -RT- -x -xd -r -AT -vG- -vG0- -vG1- -vG2- -vG3- -vGc- -vGt- -vGd-
in my project file, add a line: #pragma link "FastMM4BCB"
instead of (as described in 'FastMM4BCB.cpp') USEOBJ("FastMM4BCB.cpp")
With these changes, FastMM compiles and runs successfully. However, it reports memory leaks on even blank projects (I tried both FireMonkey and VCL) as follows:
13-20 bytes: Unknown x 8
61-68 bytes: Unknown x 1
189 - 204 bytes: Unknown x 1
With VCL projects, I was able to use full debug mode and get some details about these memory leaks (for example):
--------------------------------2014/10/23 16:58:26--------------------------------
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x628, and the stack trace (return addresses) at the time was:
41C897
41C591
415A2D
40E4B1
40E4BB
40EE45
76F73C5A [Unknown function at RtlImageNtHeader]
76FCB19C [Unknown function at RtlUlonglongByteSwap]
76F957CE [RtlLoadString]
76F73CD3 [Unknown function at RtlImageNtHeader]
76F73CD3 [Unknown function at RtlImageNtHeader]
The block is currently used for an object of class: Unknown
The allocation number is: 12
Current memory dump of 256 bytes starting at pointer address 7EF1A160:
80 80 80 80 80 80 80 80 E0 9B F3 7E 80 80 80 80 C3 7E 6A 2C 80 80 80 80 00 00 00 00 80 9F F1 7E
00 00 00 00 00 00 00 00 A8 7A 40 00 00 00 00 00 15 00 00 00 97 C8 41 00 91 C5 41 00 2D 5A 41 00
23 B1 40 00 B1 E4 40 00 BB E4 40 00 6C 60 42 00 F7 F1 40 00 5A 3C F7 76 9C B1 FC 76 CE 57 F9 76
28 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 80 1D 2A E6
80 80 80 80 80 80 80 80 E0 9B F3 7E 80 80 80 80 7F E2 D5 19 80 80 80 80 00 00 00 00 21 AC F1 7E
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 00 00 00 97 C8 41 00 91 C5 41 00 2D 5A 41 00
6C 60 42 00 4A F6 40 00 5A 3C F7 76 9C B1 FC 76 CE 57 F9 76 D3 3C F7 76 D3 3C F7 76 FE 3C F7 76
€ € € € € € € € à › ó ~ € € € € Ã ~ j , € € € € . . . . € Ÿ ñ ~
. . . . . . . . ¨ z # . . . . . . . . . — È A . ‘ Å A . - Z A .
# ± # . ± ä # . » ä # . l ` B . ÷ ñ # . Z < ÷ v œ ± ü v Î W ù v
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . € . * æ
€ € € € € € € € à › ó ~ € € € € â Õ . € € € € . . . . ! ¬ ñ ~
. . . . . . . . . . . . . . . . . . . . — È A . ‘ Å A . - Z A .
l ` B . J ö # . Z < ÷ v œ ± ü v Î W ù v Ó < ÷ v Ó < ÷ v þ < ÷
With a blank FireMonkey projects, it raises (in full debug mode) an access violation error when app closes at the address 0x80 pattern as marked by FastMM. Any idea how to make it work for FireMonkey an remove these false positive alerts on blank projects? Thanks
Related
Using GNU Parallel 20210222 with --rpl '{0#} $_=sprintf("%02d",$job->seq())' in my ~/.parallel/config, why does
seq 256 | parallel -n 64 echo {0#}
output
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03
04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
and not
01
02
03
04
whereas
seq 256 | parallel -n 64 echo {#}
outputs
1
2
3
4
?
It is hardly surprising that this:
seq 10 | parallel -n 5 echo '{= $_=-$_ =}'
gives the same as this:
seq 10 | parallel --rpl '{-} $_=-$_' -n 5 echo {-}
namely:
-1 -2 -3 -4 -5
-6 -7 -8 -9 -10
You can make {-} into a positional replacement string by prepending with the number of the argument to be replaced:
seq 10 | parallel --rpl '{-} $_=-$_' -n 5 echo {1-} {3-} {5-}
which gives:
-1 -3 -5
-6 -8 -10
The positionality can be be part of the definition:
seq 10 | parallel --rpl '{-} 1 $_=-$_' -n 5 echo {-}
which gives:
-1
-6
{#} is defined in the source code as:
'{#}' => '1 $_=$job->seq()',
So this is a positional replacement string and will only be replaced for the first value.
This
{0#} $_=sprintf("%02d",$job->seq())
is not a positional replacement string, but an ordinary replacement string that will be replaced for each input.
But it can easily be changed into a positional one:
seq 256 | parallel --rpl '{0#} 1 $_=sprintf("%02d",$job->seq())' -n 64 echo {0#}
seq 256 | parallel --rpl '{0#} $_=sprintf("%02d",$job->seq())' -n 64 echo {10#}
The last one looks a little confusing, but that is because we as humans will see '10' and not '1' (the input number) followed by '0#'.
I have been running FastMM4 on my code to see if I have any memory leaks...
This has reported a load of class UniCodeString leaks when I close the program. Are these real and how do I interpret the Event Log: This is a typical block report:
--------------------------------2020/10/21 17:32:01--------------------------------
A memory block has been leaked. The size is: 120
This block was allocated by thread 0x5648, and the stack trace (return addresses) at the time was:
430547 [FastMM4.pas][FastMM4][_ZN7Fastmm411DebugGetMemEx][8737]
409534 [System.pas][System][_ZN6System7_GetMemEx][4803]
412F8C [System.pas][System][_ZN6System17_NewUnicodeStringEi][25403]
414C3C [System.pas][System][_ZN6System16InternalUStrCatNERNS_13UnicodeStringEiPS0_][29902]
4156CB [System.pas][System][_ZN6System9_UStrCatNERNS_13UnicodeStringEi][30998]
5DD71A [System.IniFiles.pas][System.IniFiles][_ZN6System8Inifiles11TMemIniFile8TSection9SetValuesEiNS_13UnicodeStringE][852]
5DEFA6 [System.IniFiles.pas][System.IniFiles][_ZN6System8Inifiles11TMemIniFile11WriteStringENS_13UnicodeStringES2_S2_][1212]
14F335F [IDEIni.pas][IDEIni][_ZN6Ideini15TIDEIniSettings13UpdateSectionEN6System13UnicodeStringE][1153]
14F26E7 [IDEIni.pas][IDEIni][_ZN6Ideini15TIDEIniSettings13UpdateSectionEi][1087]
14F24FD [IDEIni.pas][IDEIni][_ZN6Ideini15TIDEIniSettings4SaveEiiiiibjPN6System7Classes8TStringsENS1_13UnicodeStringE][1078]
14DE604 [IDEMain.pas][IDEMain][_ZN7Idemain10TfmIDEMain9FormCloseEPN6System7TObjectERNS1_7Uitypes12TCloseActionE][573]
The block is currently used for an object of class: UnicodeString
The allocation number is: 675683
Current memory dump of 256 bytes starting at pointer address 7FF4FBF7E170:
24 D9 69 01 B0 04 02 00 01 00 00 00 29 00 00 00 50 00 61 00 74 00 68 00 3D 00 43 00 3A 00 5C 00
50 00 72 00 6F 00 67 00 72 00 61 00 6D 00 20 00 46 00 69 00 6C 00 65 00 73 00 20 00 28 00 78 00
38 00 36 00 29 00 5C 00 50 00 72 00 6F 00 74 00 6F 00 6E 00 49 00 44 00 45 00 5C 00 50 00 44 00
53 00 00 00 CA 9A 8A F5 AF D5 F2 FF 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
00 00 00 00 00 00 00 00 81 E3 F7 FB F4 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 37 48 0A 00 47 05 43 00 00 00 00 00 B6 08 43 00 00 00 00 00
9D 95 40 00 00 00 00 00 1C 54 41 00 00 00 00 00 11 55 41 00 00 00 00 00 01 56 45 01 00 00 00 00
63 02 46 01 00 00 00 00 E2 1E 46 01 00 00 00 00 92 9B 68 00 00 00 00 00 A5 04 41 00 00 00 00 00
$ Ù i . ° . . . . . . . ) . . . P . a . t . h . = . C . : . \ .
P . r . o . g . r . a . m . . F . i . l . e . s . . ( . x .
8 . 6 . ) . \ . P . r . o . t . o . n . I . D . E . \ . P . D .
S . . . Ê š Š õ ¯ Õ ò ÿ € € € € € € € € € € € € € € € € € € € €
. . . . . . . . ã ÷ û ô . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 7 H . . G . C . . . . . ¶ . C . . . . .
• # . . . . . . T A . . . . . . U A . . . . . . V E . . . . .
c . F . . . . . â . F . . . . . ’ › h . . . . . ¥ . A . . . . .
Most of the leaks are small, less than 200 bytes but should I be worrying about them?
Are these real
Very likely. Particularly the one you have shown, yes.
how do I interpret the Event Log
The leak report you have shown indicates a UnicodeString is leaked. UnicodeString is a managed type. The only times I have ever seen a UnicodeString being leaked are when:
it is a member of a class or record, and a dynamically allocated instance of that type is itself leaked. A leak report should show this instance being leaked as well.
a pointer to an allocated UnicodeString has been corrupted due to being overwritten unexpectedly, usually by a logic bug somewhere in the code.
it is declared as a threadvar and is not cleared manually before a thread exits. This is documented behavior:
Dynamic variables that are ordinarily managed by the compiler (long strings, wide strings, dynamic arrays, variants, and interfaces) can be declared with threadvar, but the compiler does not automatically free the heap-allocated memory created by each thread of execution. If you use these data types in thread variables, it is your responsibility to dispose of their memory from within the thread, before the thread terminates.
Let's look at your shown report more closely.
A memory block has been leaked. The size is: 120
Self-explanatory. A memory block allocated with a size of 120 bytes was leaked.
This block was allocated by thread 0x5648, and the stack trace (return addresses) at the time was:
430547 [FastMM4.pas][FastMM4][_ZN7Fastmm411DebugGetMemEx][8737]
409534 [System.pas][System][_ZN6System7_GetMemEx][4803]
412F8C [System.pas][System][_ZN6System17_NewUnicodeStringEi][25403]
414C3C [System.pas][System][_ZN6System16InternalUStrCatNERNS_13UnicodeStringEiPS0_][29902]
4156CB [System.pas][System][_ZN6System9_UStrCatNERNS_13UnicodeStringEi][30998]
5DD71A [System.IniFiles.pas][System.IniFiles][_ZN6System8Inifiles11TMemIniFile8TSection9SetValuesEiNS_13UnicodeStringE][852]
5DEFA6 [System.IniFiles.pas][System.IniFiles][_ZN6System8Inifiles11TMemIniFile11WriteStringENS_13UnicodeStringES2_S2_][1212]
14F335F [IDEIni.pas][IDEIni][_ZN6Ideini15TIDEIniSettings13UpdateSectionEN6System13UnicodeStringE][1153]
14F26E7 [IDEIni.pas][IDEIni][_ZN6Ideini15TIDEIniSettings13UpdateSectionEi][1087]
14F24FD [IDEIni.pas][IDEIni][_ZN6Ideini15TIDEIniSettings4SaveEiiiiibjPN6System7Classes8TStringsENS1_13UnicodeStringE][1078]
14DE604 [IDEMain.pas][IDEMain][_ZN7Idemain10TfmIDEMain9FormCloseEPN6System7TObjectERNS1_7Uitypes12TCloseActionE][573]
The leaked memory was allocated by a thread whose ID was 0x5648 at runtime. The stack trace shows the chain of function calls that led up to the allocation of the memory block that was leaked. In this case, the stack trace begins at your TForm.OnClose event handler, so that thread was clearly the main UI thread. The actual chain of function calls was then:
IDEMain.TfmIDEMain.FormClose() in IDEMain.pas, which called:
IDEIni.TIDEIniSettings.Save() in IDEIni.pas, which called:
IDEIni.TIDEIniSettings.UpdateSection(Integer) in IDEIni.pas, which called:
IDEIni.TIDEIniSettings.UpdateSection(UnicodeString) in IDEIni.pas, which called:
System.IniFiles.TMemIniFile.WriteString() in System.IniFiles.pas, which called:
System.IniFiles.TMemIniFile.TSection.SetValues() in System.IniFiles.pas, which called:
System._UStrCatN() in System.pas, which called:
System.InternalUStrCatN() in System.pas, which called:
System._NewUnicodeString() in System.pas, which called:
System._GetMem() in System.pas, which called:
FastMM4.DebugGetMem() in FastMM4.pas, which allocated the memory that was leaked
So, your OnClose handler was saving a string value to an .INI file, and internally that write performed a string concatenation inside of TSection.SetValues(), the result of which was leaked. I'm guessing because the concatenated string was saved in a TSection object that was itself leaked.
The block is currently used for an object of class: UnicodeString
Self-explanatory.
The allocation number is: 675683
FastMM keeps track of how many memory allocations it performs during the lifetime of the program.
Current memory dump of 256 bytes starting at pointer address 7FF4FBF7E170:
24 D9 69 01 B0 04 02 00 01 00 00 00 29 00 00 00 50 00 61 00 74 00 68 00 3D 00 43 00 3A 00 5C 00
50 00 72 00 6F 00 67 00 72 00 61 00 6D 00 20 00 46 00 69 00 6C 00 65 00 73 00 20 00 28 00 78 00
38 00 36 00 29 00 5C 00 50 00 72 00 6F 00 74 00 6F 00 6E 00 49 00 44 00 45 00 5C 00 50 00 44 00
53 00 00 00 CA 9A 8A F5 AF D5 F2 FF 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
00 00 00 00 00 00 00 00 81 E3 F7 FB F4 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 37 48 0A 00 47 05 43 00 00 00 00 00 B6 08 43 00 00 00 00 00
9D 95 40 00 00 00 00 00 1C 54 41 00 00 00 00 00 11 55 41 00 00 00 00 00 01 56 45 01 00 00 00 00
63 02 46 01 00 00 00 00 E2 1E 46 01 00 00 00 00 92 9B 68 00 00 00 00 00 A5 04 41 00 00 00 00 00
$ Ù i . ° . . . . . . . ) . . . P . a . t . h . = . C . : . \ .
P . r . o . g . r . a . m . . F . i . l . e . s . . ( . x .
8 . 6 . ) . \ . P . r . o . t . o . n . I . D . E . \ . P . D .
S . . . Ê š Š õ ¯ Õ ò ÿ € € € € € € € € € € € € € € € € € € € €
. . . . . . . . ã ÷ û ô . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 7 H . . G . C . . . . . ¶ . C . . . . .
• # . . . . . . T A . . . . . . U A . . . . . . V E . . . . .
c . F . . . . . â . F . . . . . ’ › h . . . . . ¥ . A . . . . .
This is a dump of the raw data in the memory block that was leaked. That block was located at memory address $7FF4FBF7E170. The first half is the hex-formatted representation of the raw bytes, and the second half is the human-readable ASCII interpretation of those bytes.
Since we know the block belongs to a UnicodeString, we can dig into the data a little further.
A UnicodeString begins with a StrRec header:
StrRec = packed record
{$IF defined(CPUX64)}
_Padding: LongInt; // Make 16 byte align for payload..
{$ENDIF}
codePage: Word;
elemSize: Word;
refCnt: Longint;
length: Longint;
end;
The format of the name mangling used in the log tells me you are using one of the Clang-based compilers, so if we assume a 64bit compiler, that would make the StrRec be 16 bytes in size, and if we break up the first 16 bytes of the dump, we get the following values:
24 D9 69 01 _Padding, ignored
B0 04 codePage = 1200, UTF-16
02 00 elemSize = 2, sizeof(WideChar)
01 00 00 00 refCnt = 1
29 00 00 00 length = 41 WideChar elements
That is consistent with a valid UnicodeString. So, if we then look at the next ((41+1)*2)=84 bytes in the dump, we see the following:
50 00 61 00 74 00 68 00 3D 00 43 00 3A 00 5C 00
50 00 72 00 6F 00 67 00 72 00 61 00 6D 00 20 00
46 00 69 00 6C 00 65 00 73 00 20 00 28 00 78 00
38 00 36 00 29 00 5C 00 50 00 72 00 6F 00 74 00
6F 00 6E 00 49 00 44 00 45 00 5C 00 50 00 44 00
53 00 00 00
And from the corresponding ASCII dump:
P . a . t . h . = . C . : . \ .
P . r . o . g . r . a . m . .
F . i . l . e . s . . ( . x .
8 . 6 . ) . \ . P . r . o . t .
o . n . I . D . E . \ . P . D .
S . . .
Which, taking UTF-16 into account, forms the Unicode string value:
'Path=C:\Program Files (x86)\ProtonIDE\PDS'
That is the actual string that was leaked. The concatenation operation in TSection.SetValues() was likely to join the substrings 'Path', '=', and 'C:\Program Files (x86)\ProtonIDE\PDS' together, assuming TMemIniFile.WriteString() had been called like this:
var Ini: TMemIniFile;
...
Ini.WriteString('Path', 'C:\Program Files (x86)\ProtonIDE\PDS');
The rest of the dumped data is just random garbage that happened to be in the same memory block, because FastMM allocates memory in buckets of fixed-sized blocks. In this case, the leaked UnicodeString was allocated in a bucket that was using 120-byte blocks.
If I had to guess, either you leaked the TMemIniFile object (which should appear elsewhere in the leak report), or TMemIniFile in your version of Delphi has a logic bug that leaks a TSection object (which should appear elsewhere in the leak report). This is where you can now start debugging into your code to trace the root cause of the leak.
I wanted to give ROS a try on my Ubuntu 20.04 machine and I installed the ROS packages as per instructions given in the ROS website, but after successful installation, roscd fails with command not found:
joesan#joesan-InfinityBook-S-14-v5:/opt/ros/noetic$ roscd
bash: roscd: command not found
joesan#joesan-InfinityBook-S-14-v5:/opt/ros/noetic$
Here is the content inside the noetic folder:
joesan#joesan-InfinityBook-S-14-v5:~$ cd /opt/ros/noetic/
drwxr-xr-x joesan joesan 4 KB Sat Aug 29 08:46:37 2020 .
drwxr-xr-x joesan joesan 4 KB Fri Aug 28 21:18:54 2020 ..
.rw-r--r-- joesan joesan 0 B Fri Jul 24 18:47:51 2020 .catkin
.rw-r--r-- joesan joesan 55 B Fri Jul 24 18:47:51 2020 .rosinstall
.rwxr-xr-x joesan joesan 13 KB Fri Jul 24 18:47:51 2020 _setup_util.py
drwxr-xr-x joesan joesan 4 KB Fri Aug 28 21:19:38 2020 bin
.rwxr-xr-x joesan joesan 506 B Fri Jul 24 18:47:51 2020 env.sh
drwxr-xr-x joesan joesan 4 KB Fri Aug 28 21:18:54 2020 etc
drwxr-xr-x joesan joesan 4 KB Fri Aug 28 21:19:39 2020 include
drwxr-xr-x joesan joesan 12 KB Fri Aug 28 21:19:39 2020 lib
.rw-r--r-- joesan joesan 283 B Fri Jul 24 18:47:51 2020 local_setup.bash
.rw-r--r-- joesan joesan 346 B Fri Jul 24 18:47:51 2020 local_setup.sh
.rw-r--r-- joesan joesan 293 B Fri Jul 24 18:47:51 2020 local_setup.zsh
.rw-r--r-- joesan joesan 260 B Fri Jul 24 18:47:51 2020 setup.bash
.rw-r--r-- joesan joesan 2.7 KB Fri Jul 24 18:47:51 2020 setup.sh
.rw-r--r-- joesan joesan 270 B Fri Jul 24 18:47:51 2020 setup.zsh
drwxr-xr-x joesan joesan 12 KB Fri Aug 28 21:19:40 2020 share
joesan#joesan-InfinityBook-S-14-v5:/opt/ros/noetic$
As you can see I have this line in my .bashrc as well:
# Source the ROS setup profile
source /opt/ros/noetic/setup.bash
Any ideas why I could not get roscd command working? I installed the full version:
sudo apt install ros-noetic-desktop-full
Is there anything that I'm missing?
So finally I was able to get this resolved! I have a .bash_profile where I have all my user specific commands and shortcuts. In this file I also source additional setup files. So what I did now was to remove the source command for ROS from the .bashrc and put this in the .bash_profile file and source the whole .bash_profile file from within .bashrc like this:
if [ -f ~/.bash_profile ]; then
. ~/.bash_profile
fi
In the .bash_profile, I have the source command like this:
# Source the ROS setup profile
source /opt/ros/noetic/setup.bash
This help me fix the error!
if i add IdGlobalProtocols unit by indy into my project, fastmm log a memory leak caused by TIdCriticalSection. If i remove IdGlobalProtocols from my uses list the leak desappear.
this happen even if i only start and close an empty form, eg.
Project3.dpr
program Project3;
uses
sharemem,
Vcl.Forms,
Unit2 in 'Unit2.pas' {Form2};
{$R *.res}
begin
Application.Initialize;
Application.MainFormOnTaskbar := True;
Application.CreateForm(TForm2, Form2);
Application.Run;
end.
Unit2.pas
unit Unit2;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs,
IdGlobalProtocols;
type
TForm2 = class(TForm)
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form2: TForm2;
implementation
{$R *.dfm}
end.
Project3_FastMM_Log.txt
--------------------------------2017/4/21 17:44:57--------------------------------
Leak di un blocco. La dimensione è: 36
Questo blocco è stato allocato dal thread 0x14F8, e lo stack trace (indirizzo restituito) in quel momento era:
406E62 [System.pas][System][#GetMem$qqri][4614]
407CA3 [System.pas][System][TObject.NewInstance$qqrv][16452]
4084CA [System.pas][System][#ClassCreate$qqrpvzc][17790]
505D06 [System.SyncObjs.pas][System.SyncObjs][Syncobjs.TCriticalSection.$bctr$qqrv][1032]
4149A2 [Winapi.Windows.pas][Winapi.Windows][Windows.GetProcAddress$qqsuipb][35524]
5E8897
40964C [System.pas][System][InitUnits$qqrv][22339]
4096B8 [System.pas][System][#StartExe$qqrp23System.PackageInfoTablep17System.TLibModule][22411]
410517 [SysInit.pas][SysInit][#InitExe$qqrpv][1419]
5E898C
74D6337A [BaseThreadInitThunk]
773A9882 [Unknown function at RtlInitializeExceptionChain]
773A9855 [Unknown function at RtlInitializeExceptionChain]
Il blocco è attualmente usato da una istanza della classe: TIdCriticalSection
Il numero di allocazione è: 378
Dump della memoria di 256 byte partendo dall'indirizzo del puntatore 7EF9EB60:
2C A4 5C 00 F8 13 2A 00 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA A4 57 B5 80 80 80 80 00 00 00 00 91 FD F9 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7D 01 00 00 62 6E 40 00 6F 9B 40 00 FC 9F 40 00 02 89 5E 00 4C 96 40 00 B8 96 40 00 17 05 41 00
8C 89 5E 00 7A 33 D6 74 82 98 3A 77 55 98 3A 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 14 00 00 F8 14 00 00
7E 6E 40 00 29 9C 40 00 99 AF 40 00 23 C0 40 00 B9 EC 5D 00 E1 EC 5D 00 E0 95 40 00 CF 89 5E 00
7A 33 D6 74 82 98 3A 77 55 98 3A 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 00 00 B0 04 02 00 89 46 31 4A
, ¤ \ . ø . * . ÿ ÿ ÿ ÿ . . . . . . . . . . . . . . . . . . . .
ª ¤ W µ € € € € . . . . ‘ ý ù ~ . . . . . . . . . . . . . . . .
} . . . b n # . o › # . ü Ÿ # . . ‰ ^ . L – # . ¸ – # . . . A .
Œ ‰ ^ . z 3 Ö t ‚ ˜ : w U ˜ : w . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . ø . . . ø . . .
~ n # . ) œ # . ™ ¯ # . # À # . ¹ ì ] . á ì ] . à • # . Ï ‰ ^ .
z 3 Ö t ‚ ˜ : w U ˜ : w . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . ° . . . ‰ F 1 J
What i doing wrong?
I'm on Delphi Berlin Update 2
A quick question: ls . | grep -E "^[0-9]" gives me the results in the following format:
1
2
3
4
5
How can I let it be simply displayed as 1 2 3 4 5?
Try
ls . | grep -E "^[0-9]" | tr '\n' ' ' ; echo
try this with tr:
your cmd ....|tr "\n" ' '
try ls . | grep -E "^[0-9" | tr '\n' ' '
Using awk
ls . | awk '/^[0-9]/ {printf "%s ",$0}'
Or more clean:
ls . | awk '/^[0-9]/ {printf "%s ",$0} END {print ""}'
If it is available, you can use the column command from bsdmainutils:
ls | grep '^[0-9]' | column
Output:
1 2 3 4 5
Another test:
seq 50 | column
Example output:
1 6 11 16 21 26 31 36 41 46
2 7 12 17 22 27 32 37 42 47
3 8 13 18 23 28 33 38 43 48
4 9 14 19 24 29 34 39 44 49
5 10 15 20 25 30 35 40 45 50