New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: Not printing value before (not object bound directly) produces wildly different behaviour (and assembly) #48041
Comments
As @randall77 pointed out in #48035 (comment) , it is hard to understand what this code is intended to do. Could you be clearer about what the intended behavior is, and make sure the use of unsafe.Pointer is valid per https://pkg.go.dev/unsafe#Pointer . Thanks. |
Hello! I'm sorry. I'll try to explain. In general, before this, to use this: In context:
I'm attempting to read 4 bytes at the current iteration + aforementioned padding + argument padding (I.e. if I specify a data skip with the wildcard opcode 0xCC, if I want to capture a pointer address at runtime, I want to add 2 to get there and read there). The unsafe usage there is just as a way to debug the contents of the value without directly printing it or any of that. I hope it didn't get picked up as legitimate usage. It was just another way to indicate or display the issue. I didn't get much time to actually research more myself, but I've posted the assembly for preparing the function call above. I could provide a project with the whole ordeal, but it's dependent on a specific process currently. I could write, if asked for, a project that will depend on another local small application and replicate the process which is currently bound to the process I'm now interacting with. I'm sorry for not responding earlier. There's a language barrier which sometimes prevents me from fully expressing what I'm trying to say. |
What does |
readMemoryDll is a wrap for a ReadProcessMemory WINAPI call, Dll part implies that the lpBaseAdress will be a formation of the passed DLL's bass address to uintptr + in this scenario (i+j+pad). It returns a pointer to what I'm writing the memory copied content to so I can interpret it as I wish. "Process will literally fail" means that the RPM call will fail by trying to read at a bogus address, on that I detail more in the OP, obviously unless I do the aforementioned print. It'll panic because it is made to, because the WINAPI ReadProcessMemory result is 0. That is, again, because lpBaseAddress is bogus. "Fault with correct result" is me trying to SEGV the program, and succeeding, for the debug log. The debug log specifies the segv address as the result I'm seeking of the aforementioned operation. "Result should be readable (and valid)" is a specification that the returned pointer should not be nil, and should be from a readable memory page. |
Not clear to me then. I encourage you to do some debugging yourself. It's not a good use of anyone's time to debug remotely back and forth like this. Run under a debugger, set breakpoints, see where that bad address is coming from. If you can give us a whole program that we can run, then we might be able to help you. |
No new information |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I'm trying to use my combinations result with a method wrap, the combinations result being the ptrdiff from a base pointer to determine a position from where to read at.
What did you expect to see?
Result of what happens when I print the value (I'd pass a call fail and I'd get a health integer variable which I'd just then be reading from memory)
What did you see instead?
My method constantly failing by the argument passed being bogus. It consistently tries to read at '0x12ffc88b3422b764', but, when I turn the result into a variable, then I try to turn it into an underlying content read, I fault at an address which is the correct result with the operation.
Failing code label for context:
Full method:
Failing label's assembly when not printing:
Then failing, not succeeding, label's assembly, when printing:
The text was updated successfully, but these errors were encountered: