Skip to content

Wrong/confusing memory addrs on Windows #76

Open
@Swatinem

Description

@Swatinem

This came up in getsentry/sentry-rust#386, with a possible workaround in getsentry/sentry-rust#387.

On Windows, we currently get values such as these:

actual_load_addr() = "0x7ff6b4091000"
stated_load_addr() = "0x1000"
virtual_memory_bias() = "0x7ff6b4090000"

Trying to use the actual_load_addr for symbolication yields the wrong results, and virtual_memory_bias() would give us the right value, though the name is very confusing in that case, and does not match the impl on other OSs.

virtual_memory_bias internally uses the module_base, and that value is also in line with what minidumps, and other minidump-related tools like breakpad and crashpad are yielding, and our symbolication is based on those.

CC @mitsuhiko (original author of #37) @jan-auer

We had a small talk yesterday, and concluded that it probably does not make sense to have this distinction on Windows at all, and essentially stated should always be 0, and thus actual == bias.

However I have looked a bit at the impl here, and it seems that those values are based on iterating/finding the executable segments of an executable, so not sure what the right approach to fix this might be right now.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions