Skip to content
This repository has been archived by the owner on Jun 18, 2021. It is now read-only.

Fix fprintf calls on Windows #27

Closed
wants to merge 1 commit into from

Conversation

richardlau
Copy link
Member

pSymbol->Address is ULONG64 but fprintf's %p format on x86 expects 32-bits.

Also wrapped the long edited lines.

Fixes #26

}
}
} else { // SymFromAddr() failed, just print the address
fprintf(fp, "%2d: [pc=0x%p]\n", i, pSymbol->Address);
fprintf(fp, "%2d: [pc=0x%p]\n", i,
reinterpret_cast<void*>(pSymbol->Address));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If SymFromAddr() fails, is pSymbol->Address valid here?
@rnchamberlain

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that line was copied from 4 lines above, where SymFromAddr() has succeeded. The SymFromAddr() call might copy the address into pSymbol->Address in failure cases, but yes, it would be better/more logical to use dwAddress instead at this point. Can you add that to your fix? Thanks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor

@rnchamberlain rnchamberlain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

fprintf(fp, "%2d: [pc=0x%p] %s [+%d] in %s: line: %lu\n", i, pSymbol->Address, pSymbol->Name, dwOffset, line.FileName, line.LineNumber);
fprintf(fp, "%2d: [pc=0x%p] %s [+%d] in %s: line: %lu\n", i,
reinterpret_cast<void*>(pSymbol->Address), pSymbol->Name,
dwOffset, line.FileName, line.LineNumber);
} else {
// SymGetLineFromAddr64() failed, just print the address and symbol
if (dwOffset64 <= 32) { // sanity check
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rnchamberlain Is this sanity check valid? It seems to be consistently failing for me and we drop into the else clause.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nb. Consistently dropping into the else clause here is why only test-api.js is failing in #26 as it's succeeding the SymGetLineFromAddr64 call -- The other tests fail the call and then fail the sanity check. The original fprintf for the else clause of the sanity check doesn't have parameters after the pSymbol->Address argument, so there the fprintf call there didn't crash.

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

pSymbol->Address is ULONG64 but fprintf's %p format on x86 expects 32-bits.

Fixes nodejs#26
@richardlau
Copy link
Member Author

Updated. I've dropped the sanity check as it seemed wrong and prevents the name of the method being printed.

@rnchamberlain
Copy link
Contributor

@richardlau I can't remember why that if (dwOffset64 <= 32) sanity check was in there. It's checking the offset from the symbol (the displacement parameter returned by SymFromAddr()). These are function-name symbols we are getting, and it seems that the address could be some way down in the function. So checking for <= 32 is clearly too limiting. Agree to drop it, we'll keep a lookout for bogus symbols appearing. Planning to land this PR tomorrow.

rnchamberlain pushed a commit that referenced this pull request Dec 6, 2016
pSymbol->Address is ULONG64 but fprintf's %p format on x86 expects 32-bits.

Fixes #26

PR-URL: #27
Reviewed-By: Richard Chamberlain <richard_chamberlain@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: George Adams <george.adams@uk.ibm.com>
@rnchamberlain
Copy link
Contributor

Landed as d988b6c

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants