I am using VS Code 1.24.0 on macOS to edit YAML files that are saved to an NFS share (published on a QNAP NAS) and used by an Ubuntu 18 linux system.
When saving the YAML file VS Code often inserts a bunch of non-printable control characters which causes an error parsing the YAML. To fix it I need to open the file with vim and remove them.
00000110 20 73 65 72 76 65 72 3a 20 4e 41 53 31 0a 20 20 | server: NAS1. |
00000120 70 65 72 73 69 73 74 65 6e 74 56 6f 6c 75 6d 65 |persistentVolume|
00000130 52 65 63 6c 61 69 6d 50 6f 6c 69 63 79 3a 20 52 |ReclaimPolicy: R|
00000140 65 74 61 69 6e 00 00 00 00 00 00 00 00 00 00 00 |etain...........|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 |.............|
0000027d
Note 1: It never happens if I use VS Code on the linux system and edit the files locally; but I need to use this as a headless server so this is not how I want to work.
Note 2: This appears to be a similar issue to that raised here some time ago - but no solution is available.
Related
i've coded a sniffer with libpcap dealing with data link layer. but i've implemented only the ethernet part. Since this morning, i receive this kind of frame all day long. Could you help me to find the protocol used there and the layer ?
Thx
FF FF FF FF FF FF 0A 61 FC 80 B6 EF 26 00 00 00 AF 81 01 00 61 65 72 6F 68 69 76 65 20 67 72 61 74 75 69 74 6F 75 73 20 61 72 70 2C 20 61 70 5F 6D 61 63 3D 66 34 65 61 3A 62 35 36 35 3A 33 61 30 30 2C 20 69 70 3D 31 30 2E 31 33 36 2E 31 2E 34 34 2C 20 73 65 71 3D 32 37 65 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FF FF FF FF
destination MAC
0A 61 FC 80 B6 EF
source MAC
26 00
Ethertype
00 00 AF 81 01 00 61 65 72 6F 68 69 76 65 20 67 72 61 74 75 69 74 6F 75 73 20 61 72 70 2C 20 61 70 5F 6D 61 63 3D 66 34 65 61 3A 62 35 36 35 3A 33 61 30 30 2C 20 69 70 3D 31 30 2E 31 33 36 2E 31 2E 34 34 2C 20 73 65 71 3D 32 37 65 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Data: ÿÿÿÿÿÿ
aü¶ï&¯aerohive gratuitous arp, ap_mac=f4ea:b565:3a00, ip=10.136.1.44, seq=27ea
When I use powershell tee-object cmdlet to save the output to a file, blank lines are created between each actual line. Output gets doubled and ugly, in both screen output, as well in the redirected file.
regular command, and output:
# db2 connect to sample
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
but, when you use Tee-Object against it... here is what happens:
# db2 connect to sample | Tee-Object test.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
In both screen output, and also in the generated file a well:
# type test.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
--- edit ---
#js2010, here is the entire hex-format for better reading.. cant paste it properly in the comments.
# format-hex test.out
Path: E:\PowerShell_Tests\db2mon\test.out
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 FF FE 0D 00 0A 00 0D 00 0A 00 20 00 20 00 20 00 .þ........ . . .
00000010 44 00 61 00 74 00 61 00 62 00 61 00 73 00 65 00 D.a.t.a.b.a.s.e.
00000020 20 00 43 00 6F 00 6E 00 6E 00 65 00 63 00 74 00 .C.o.n.n.e.c.t.
00000030 69 00 6F 00 6E 00 20 00 49 00 6E 00 66 00 6F 00 i.o.n. .I.n.f.o.
00000040 72 00 6D 00 61 00 74 00 69 00 6F 00 6E 00 0D 00 r.m.a.t.i.o.n...
00000050 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 20 00 .............. .
00000060 44 00 61 00 74 00 61 00 62 00 61 00 73 00 65 00 D.a.t.a.b.a.s.e.
00000070 20 00 73 00 65 00 72 00 76 00 65 00 72 00 20 00 .s.e.r.v.e.r. .
00000080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 3D 00 . . . . . . .=.
00000090 20 00 44 00 42 00 32 00 2F 00 4E 00 54 00 36 00 .D.B.2./.N.T.6.
000000A0 34 00 20 00 31 00 31 00 2E 00 35 00 2E 00 30 00 4. .1.1...5...0.
000000B0 2E 00 30 00 0D 00 0A 00 0D 00 0A 00 20 00 53 00 ..0......... .S.
000000C0 51 00 4C 00 20 00 61 00 75 00 74 00 68 00 6F 00 Q.L. .a.u.t.h.o.
000000D0 72 00 69 00 7A 00 61 00 74 00 69 00 6F 00 6E 00 r.i.z.a.t.i.o.n.
000000E0 20 00 49 00 44 00 20 00 20 00 20 00 3D 00 20 00 .I.D. . . .=. .
000000F0 53 00 41 00 4D 00 55 00 45 00 4C 00 0D 00 0A 00 S.A.M.U.E.L.....
00000100 0D 00 0A 00 20 00 4C 00 6F 00 63 00 61 00 6C 00 .... .L.o.c.a.l.
00000110 20 00 64 00 61 00 74 00 61 00 62 00 61 00 73 00 .d.a.t.a.b.a.s.
00000120 65 00 20 00 61 00 6C 00 69 00 61 00 73 00 20 00 e. .a.l.i.a.s. .
00000130 20 00 20 00 3D 00 20 00 53 00 41 00 4D 00 50 00 . .=. .S.A.M.P.
00000140 4C 00 45 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 L.E.............
00000150 0D 00 0A 00 ....
Also, your 2nd test reveals that the problem is not about using tee-object cmdlet, but actually, just piping the output causes it...
Another information, If I perform a redirect to a file, from a regular windows cmd window, the issue does not happens,
from cmd window:
E:\PowerShell_Tests\db2mon>db2 connect to sample > cmd.out
E:\PowerShell_Tests\db2mon>type cmd.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
but, performing the same redirect from a powershell session, created the double lines again:
# db2 connect to sample > pwsh.out
PS [Samuel]E:\PowerShell_Tests\db2mon
# Get-Content pwsh.out
Database Connection Information
Database server = DB2/NT64 11.5.0.0
SQL authorization ID = SAMUEL
Local database alias = SAMPLE
--- end edit ---
--- edit 2 ---
#js2010
# db2 connect to sample | format-hex
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 20 20 44 61 74 61 62 61 73 65 20 43 6F 6E 6E Database Conn
00000010 65 63 74 69 6F 6E 20 49 6E 66 6F 72 6D 61 74 69 ection Informati
00000020 6F 6E on
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 44 61 74 61 62 61 73 65 20 73 65 72 76 65 72 Database server
00000010 20 20 20 20 20 20 20 20 3D 20 44 42 32 2F 4E 54 = DB2/NT
00000020 36 34 20 31 31 2E 35 2E 30 2E 30 64 11.5.0.0
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 53 51 4C 20 61 75 74 68 6F 72 69 7A 61 74 69 SQL authorizati
00000010 6F 6E 20 49 44 20 20 20 3D 20 53 41 4D 55 45 4C on ID = SAMUEL
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 20 4C 6F 63 61 6C 20 64 61 74 61 62 61 73 65 20 Local database
00000010 61 6C 69 61 73 20 20 20 3D 20 53 41 4D 50 4C 45 alias = SAMPLE
--- end edit 2 ---
Does any one has any clue on what is going on, and how can I "fix" it ?
Thanks
As your Format-Hex output implies, db2 - bizarrely - uses CRCRLF ("`r`r`n" in PowerShell terms) rather than the usual CRLF sequences ("`r`n") as newlines (to separate its output lines) - it is a behavior it shares with sfc.exe.
When you print to the display, this anomaly doesn't surface, but it does when you capture or redirect the output, such as via Tee-Object.
The workaround is to eliminate every other line, which discards the extra lines that result from PowerShell interpreting a CR ("`r") by itself as a newline too:
$i = 0
db2 ... | Where-Object { ++$i % 2 } | Tee-Object test.out
Update: You've since provided a convenient wrapper function based on this solution in your own answer.
for other Db2 DBAs out there trying to use powershell as me..
I have created this small hack, to handle this for all my db2 ps sessions.
Edit your powershell user profile, creating an function and alias as above:
$Home[My ]Documents\PowerShell\Microsoft.PowerShell_profile.ps1 :
# db2 settings for powershell
Set-Item -Path env:DB2CLP -value "**$$**"
# Handle db2 output, avoiding doubled lines due 'CRCRLF' pattern
Function Handle-Db2 {
$i = 0
db2 $args | Where-Object { ++$i % 2 }
}
New-Alias -Name "db2ps" Handle-Db2
Now, if you want to use the hacked version, instead of calling db2 .... you can use db2ps ... instead and have a proper output.
# db2ps describe table employee | Tee-Object employee.out
Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
EMPNO SYSIBM CHARACTER 6 0 No
FIRSTNME SYSIBM VARCHAR 12 0 No
MIDINIT SYSIBM CHARACTER 1 0 Yes
LASTNAME SYSIBM VARCHAR 15 0 No
WORKDEPT SYSIBM CHARACTER 3 0 Yes
PHONENO SYSIBM CHARACTER 4 0 Yes
HIREDATE SYSIBM DATE 4 0 Yes
JOB SYSIBM CHARACTER 8 0 Yes
EDLEVEL SYSIBM SMALLINT 2 0 No
SEX SYSIBM CHARACTER 1 0 Yes
BIRTHDATE SYSIBM DATE 4 0 Yes
SALARY SYSIBM DECIMAL 9 2 Yes
BONUS SYSIBM DECIMAL 9 2 Yes
COMM SYSIBM DECIMAL 9 2 Yes
14 record(s) selected.
# db2ps describe table employee | Select-String "DEC"
SALARY SYSIBM DECIMAL 9 2 Yes
BONUS SYSIBM DECIMAL 9 2 Yes
COMM SYSIBM DECIMAL 9 2 Yes
It would be nice if IBM fix this odd CRCRLF behavior on db2 commands on windows.
Until this not happens, enjoy!
Regards
My managed process is suspected to have caused a BSOD at a client site. I received a full memory dump (i.e.: including kernel, physical pages only) - but still am not able to inspect my process' stacks.
After switching to my process context -
.process /p /r <MyProcAddress>
I see only -
1: kd> k
# ChildEBP RetAddr
00 b56e3b70 81f2aa5d nt!KeBugCheckEx+0x1e
01 b56e3b94 81e7b68d nt!PspCatchCriticalBreak+0x71
02 b56e3bc4 81e6dfd1 nt!PspTerminateAllThreads+0x2d
03 b56e3bf8 8d48159a nt!NtTerminateProcess+0xcd
WARNING: Stack unwind information not available. Following frames may be wrong.
04 b56e3c24 81c845e4 klif+0x7559a
05 b56e3c24 77da6bb4 nt!KiSystemServicePostCall
06 0262f34c 00220065 ntdll!KiFastSystemCallRet
07 0262f390 003e0022 0x220065
08 0262f394 0073003c 0x3e0022
09 0262f398 00730079 0x73003c
0a 0262f39c 006e003a 0x730079
0b 0262f3a0 006d0061 0x6e003a
0c 0262f3a4 00200065 0x6d0061
0d 0262f3a8 00610076 0x200065
0e 0262f3ac 0075006c 0x610076
0f 0262f3b0 003d0065 0x75006c
10 0262f3b4 00770022 0x3d0065
11 0262f3b8 006e0069 0x770022
12 0262f3bc 006f0077 0x6e0069
13 0262f3c0 00640072 0x6f0077
14 0262f3c4 00200022 0x640072
...
Which is natural for managed process. SOS extension does not work for kernel dumps.
Is there anything I can do to view the throwing managed stack? It was previously said to be 'much more difficult', but hopefully not impossible.
PS.
I'm aware of the presence of Kaspersky driver kilf.sys in the stack, and this is my personal suspect. But the question is more general - hopefully there's a way to understand what my process was doing at the time.
the stack as you posted is not correct
it appears to be overwritten or is a result of some other artefact
with such a stack details you will have a hard time deciphering
anything useful at all
the contents of stack converted to a printable range in english looks like this
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 00 3E 00 22 00 22 00 65 00 73 00 3C 00 3E 00 22 .>.".".e.s.<.>."
00000010 00 73 00 79 00 73 00 3C 00 6E 00 3A 00 73 00 79 .s.y.s.<.n.:.s.y
00000020 00 6D 00 61 00 6E 00 3A 00 20 00 65 00 6D 00 61 .m.a.n.:. .e.m.a
00000030 00 61 00 76 00 20 00 65 00 75 00 6C 00 61 00 76 .a.v. .e.u.l.a.v
00000040 00 3D 00 65 00 75 00 6C 00 77 00 22 00 3D 00 65 .=.e.u.l.w.".=.e
00000050 00 6E 00 69 00 77 00 22 00 6F 00 77 00 6E 00 69 .n.i.w.".o.w.n.i
00000060 00 64 00 72 00 6F 00 77 00 20 00 22 00 64 00 72 .d.r.o.w. .".d.r
try !analyze -v and see what is the bsod analysis results
I write the following bytes into a file named disk.img
FA 8D 36 1B 7C E8 01 00 F4 AC 3C 00 74 0C B4 0E
BB 07 00 B9 01 00 CD 10 EB EF C3 4D 61 79 20 74
68 65 20 66 6F 72 63 65 20 62 65 20 77 69 74 68
20 79 6F 75 21 0D 0A 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
..enough zero to make the size of file 512bytes.
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 55 AA
The above bytes are proper instructions and magic number that should work when loading into the boot sector. But after I executed "qemu-X86_64 disk.img", error happens.
Error -13 while loading disk.img
Does anyone know how to solve the problem or what is the reason that might lead to this error?
Thank you!
I don't know if you can fill an image with just anything and expect it to work just because you have 55 AA in the correct place. Since you seem to be writing a bootloader make sure your code thinks it is executing at the correct place. It should be in offset 0x7C00 (if I remember this correctly, double check that). You set it by writing the line [org 0x7C00] at the top of your assembly file.
Also I'm not sure you can have only a 512 byte file. Try to make the disk image bigger than that using something like dd if=/dev/zero of=disk.img bs=512 count=2000 and then just copy your bootloader to the first part of the disk using dd again.
Also, you should use the -hda or -fda tags, so it would be qemu -hda disk.img. -hda means hard drive image, and -fda means floppy disk image.
I've inherited a project that at some point creates a zip file, adds an XML file to the zip and then adds a number of PNG files to the same archive. All works fine on the simulator, but whenever I run the same code on the device itself the resulting png files are altered and unopenable when opened on my Mac.
They still appear to be png files, but the 'corrupt' export ones are slightly larger than the true files are, and hex dumps show the contents differ drastically. Headers are preserved though...
Original:
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 6d 00 00 00 75 08 06 00 00 00 44 7d 6f |...m...u.....D}o|
00000020 a0 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 |?....tEXtSoftwar|
00000030 65 00 41 64 6f 62 65 20 49 6d 61 67 65 52 65 61 |e.Adobe ImageRea|
00000040 64 79 71 c9 65 3c 00 00 38 32 49 44 41 54 78 da |dyq?e<..82IDATx?|
Corrupt:
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 04 43 67 42 49 |.PNG........CgBI|
00000010 30 00 20 02 10 f3 44 7c 00 00 00 0d 49 48 44 52 |0. ..?D|....IHDR|
00000020 00 00 00 6d 00 00 00 75 08 06 00 00 00 44 7d 6f |...m...u.....D}o|
00000030 a0 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 |?....tEXtSoftwar|
00000040 65 00 41 64 6f 62 65 20 49 6d 61 67 65 52 65 61 |e.Adobe ImageRea|
00000050 64 79 71 c9 65 3c 00 00 38 65 49 44 41 54 ed bd |dyq?e<..8eIDAT??|
(I appreciate a small chunk of the file header is not very helpful but the intention is to show that the corruption occurs within the PNG and not the ZIP itself.)
So I guess what I'm asking is whether anyone has experienced anything like this before? I just tried using the following wrapper http://www.flyblog.info/catprogramming/202.html and experienced the same issue, so am guessing its libzip itself causing the issue?
Does anyone have a simple, tried and tested method for adding files to a zip file on the Ipod that I can try and swap in?
If it helps, here is the code that creates the zip:
ZipArchive* zip = [[ZipArchive alloc] init];
BOOL ret = [zip CreateZipFile2: zipPath];
NSMutableSet *imageNames = [NSMutableSet set];
[curAlbum collectImageNames:imageNames];
for (NSString *imageName in imageNames) {
NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageName ofType:#""];
NSLog(imagePath);
ret = [zip addFileToZip:imagePath newname:#"test.png"];
}
[zip release];
Any advice appreciated :-)
In addition to Noah's answer Xcode also compresses PNG files:
It might be worth setting COMPRESS_PNG_FILES = NO in the target info window.
When Xcode builds an application for the device, it alters any PNG resources, converting them to BGRA (as opposed to the usual RGBA) and premultiplying the alpha channel. There isn't a way to prevent this using any project settings that I know of; you might try giving the resources you include with the app an extension other than ".png" to see if Xcode then copies them without alteration.