Skip to content
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

[logcat-parse] Support repeated handles. #35

Merged
merged 1 commit into from
May 23, 2016

Conversation

jonpryor
Copy link
Member

I've come across some log files which would contain several thousand
global references, as per the grefc values, but when processing via
logcat-parse grefs.AlivePeers.Count() would invariably return 11,
or some other ludicrously low value given the input.

On further investigation, a problem is with repeated handle values.
Once a handle has been disposed, there's no reason why it couldn't be
reused again:

+g+ grefc 1 gwrefc 0 obj-handle 0x4a00009/L -> new-handle 0x19004aa/G from thread '(null)'(3)
-g- grefc 0 gwrefc 0 handle 0x19004aa/G from thread '(null)'(3)
# OK, created + destroyed an instance...

+g+ grefc 1 gwrefc 0 obj-handle 0x4a00009/L -> new-handle 0x19004aa/G from thread '(null)'(3)
# OK, created a *different* instance

Unfortunately, logcat-parse would treat the second +g+ as if it were
an alias of the originally created instance. As such,
grefs.AlivePeers.Count() would return 0, not 1, which is wrong.

To better support this, keep a separate alive list of peers, and
only consult the "alive" list when performing handle lookups. This
prevents the original -- dead! -- PeerInfo from being reused, allowing
us to have (more?) accurate peer information.

I've come across some log files which would contain *several thousand*
global references, as per the `grefc` values, but when processing via
logcat-parse `grefs.AlivePeers.Count()` would invariably return `11`,
or some other ludicrously low value given the input.

On further investigation, a problem is with repeated handle values.
Once a handle has been disposed, there's no reason why it couldn't be
reused again:

	+g+ grefc 1 gwrefc 0 obj-handle 0x4a00009/L -> new-handle 0x19004aa/G from thread '(null)'(3)
	-g- grefc 0 gwrefc 0 handle 0x19004aa/G from thread '(null)'(3)
	# OK, created + destroyed an instance...

	+g+ grefc 1 gwrefc 0 obj-handle 0x4a00009/L -> new-handle 0x19004aa/G from thread '(null)'(3)
	# OK, created a *different* instance

Unfortunately, `logcat-parse` would treat the second +g+ as if it were
an alias of the originally created instance. As such,
`grefs.AlivePeers.Count()` would return 0, not 1, which is wrong.

To better support this, keep a separate `alive` list of peers, and
only consult the "alive" list when performing handle lookups. This
prevents the original -- dead! -- PeerInfo from being reused, allowing
us to have (more?) accurate peer information.
@dellis1972 dellis1972 merged commit c37e029 into dotnet:master May 23, 2016
radekdoulik added a commit to radekdoulik/java.interop that referenced this pull request Aug 27, 2018
Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1:

9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (dotnet#47)
bdf0158 Better support no installed JDKs on macOS (dotnet#48)
6353659 Log what is happening during path selection (dotnet#46)
3ef860b Take BUILD_NUMBER into consideration for Version sorting (dotnet#45)
d3de054 Allow an optional locator to be provided to JdkInfo (dotnet#43)
917d3b3 Don't require quotes around `release` values (dotnet#41)
7427692 [tests] Unit tests for finding NDK location based on $PATH (dotnet#40)
dbc517b Merge pull request dotnet#38 from jonpryor/jonp-ndk-via-path
511d580 Allow finding NDK location based on $PATH
b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (dotnet#37)
a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (dotnet#35)
fae7e0a [tests] Remove temporary directories (dotnet#36)
07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (dotnet#34)
radekdoulik added a commit that referenced this pull request Aug 27, 2018
Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1:

9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (#47)
bdf0158 Better support no installed JDKs on macOS (#48)
6353659 Log what is happening during path selection (#46)
3ef860b Take BUILD_NUMBER into consideration for Version sorting (#45)
d3de054 Allow an optional locator to be provided to JdkInfo (#43)
917d3b3 Don't require quotes around `release` values (#41)
7427692 [tests] Unit tests for finding NDK location based on $PATH (#40)
dbc517b Merge pull request #38 from jonpryor/jonp-ndk-via-path
511d580 Allow finding NDK location based on $PATH
b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (#37)
a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (#35)
fae7e0a [tests] Remove temporary directories (#36)
07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (#34)
@github-actions github-actions bot locked and limited conversation to collaborators Apr 15, 2024
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.

3 participants