Closed KeithBrown39423 closed 4 months ago
Here are the results from the Windows event viewer if it helps
Faulting module name: hexdump.exe, version: 0.0.0.0, time stamp: 0x666340b7
Exception code: 0xc0000005
Fault offset: 0x00000000000036b0
Faulting process id: 0x0x5874
Faulting application start time: 0x0x1DAB8FF685921DD
Faulting application path: \\wsl.localhost\Arch\home\keith\projects\zig\Hexdump\release\x86_64\windows\bin\release\x86_64\windows\bin\hexdump.exe
Faulting module path: \\wsl.localhost\Arch\home\keith\projects\zig\Hexdump\release\x86_64\windows\bin\release\x86_64\windows\bin\hexdump.exe
Report Id: 3740cd5a-6b13-4374-8e4b-54b3616f52af
Faulting package full name:
Faulting package-relative application ID:
Faulting application name: hexdump.exe, version: 0.0.0.0, time stamp: 0x66613a70
Faulting module name: hexdump.exe, version: 0.0.0.0, time stamp: 0x66613a70
Exception code: 0xc0000005
Fault offset: 0x00000000000036b0
Faulting process id: 0x0x64BC
Faulting application start time: 0x0x1DAB8FE4C51C9E7
Faulting application path: C:\Users\keith\Downloads\hexdump.exe
Faulting module path: C:\Users\keith\Downloads\hexdump.exe
Report Id: deedc38f-cab4-4ff1-8d55-cf70f3e5ceb1
Faulting package full name:
Faulting package-relative application ID:
I'll test this once I get home. I have a feeling this may be a system dependent error.
Nevermind same issue here...
2 things I've noticed off the bat. Two issues where you're treating a u64 as usize. Keep in mind usize doesn't always mean a u64, as 32-bit systems will use u32. This is done on lines https://github.com/KeithBrown39423/Hexdump/blob/1b4b1591559244d7eca40eeeb7d0236ef58eaf5a/src/main.zig#L136 https://github.com/KeithBrown39423/Hexdump/blob/1b4b1591559244d7eca40eeeb7d0236ef58eaf5a/src/main.zig#L165
These can be fixed by wrapping the variable in a @intCast
Now the program won't exit silently, actually now it's quite "loud". As a segmentation fault occurs.
Segmentation fault at address 0x59002c
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\unicode.zig:1563:33: 0x4d49f0 in wtf8ValidateSlice (hexdump.exe.obj)
return utf8ValidateSliceImpl(input, .can_encode_surrogate_half);
^
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\unicode.zig:1623:31: 0x49ae8a in init (hexdump.exe.obj)
if (!wtf8ValidateSlice(s)) {
^
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\unicode.zig:1235:56: 0x49a72f in utf8ToUtf16LeImpl__anon_6188 (hexdump.exe.obj)
.can_encode_surrogate_half => try Wtf8View.init(remaining),
^
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\unicode.zig:1742:29: 0x48d595 in wtf8ToWtf16Le (hexdump.exe.obj)
return utf8ToUtf16LeImpl(wtf16le, wtf8, .can_encode_surrogate_half);
^
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\os\windows.zig:2268:50: 0x48369e in sliceToPrefixedFileW (hexdump.exe.obj)
temp_path.len = try std.unicode.wtf8ToWtf16Le(&temp_path.data, path);
^
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\fs\Dir.zig:800:56: 0x4778c1 in openFile (hexdump.exe.obj)
const path_w = try windows.sliceToPrefixedFileW(self.fd, sub_path);
^
C:\Users\zacke\Downloads\Hexdump-release\src\main.zig:48:35: 0x47416d in main (hexdump.exe.obj)
const file = fs.cwd().openFile(args.file, .{}) catch |err| {
^
C:\Users\zacke\OneDrive\Desktop\zig-windows-x86-0.12.0\lib\std\start.zig:350:53: 0x478b6c in WinStartup (hexdump.exe.obj)
std.os.windows.ntdll.RtlExitUserProcess(callMain());
^
???:?:?: 0x7505fcc8 in ??? (KERNEL32.DLL)
???:?:?: 0x771a7cbd in ??? (ntdll.dll)
???:?:?: 0x771a7c8d in ??? (ntdll.dll)
Fixed
Describe the bug When running the Windows binary, if you specify a filename, it silently fails with the error code -1073741819. It also takes around 15-25 seconds before it actually fails. When running it on WSL, it gives the error code 5.
To Reproduce Steps to reproduce the behavior:
hexdump.exe <file>
echo %ERRORLEVEL%
to see the error code.Expected behavior Printing out the hexdump of the specified file.
Screenshots
Desktop (please complete the following information):