Issue #1011: Resolve StackOverflowErrors on page serialization #1141
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JGit commit objects are a recursive data structure; they have links to their parent commits. Serializing a JGit commit will try to recursively serialize all reachable ancestors as faras they have been loaded. If that ancestor chain is too long, a StackOverflowError is thrown during Wicket's page serialization if a page has a reference to sucha JGit commit. Fixed by making sure that pages o not contain references to JGit commits. Use the (existing) wrapper object RepositoryCommit instead. * RepositoryCommit has a transient reference to the JGit commit and reads the commit from the repository upon de-serialization. * RefModel is a similar case (JGit tags/branches may also have links to the commits they point to). Solved a bit differently by making it a pure data object by transferring the interesting data from the JGit object in the constructor. * Change DataViews instantiated with RevCommit to use RepositoryCommit instead. * Change inner anonymous DataViews to ensure they do not have a synthesized field referencing the "allRefs" map. Such a synthesized field would also get serialized, and then serialize JGit commits again. Finally, remove non-transient logger instances in Wicket classes. Those might lead to NotSerializableException. These StackOverflowErrors have been reported in several places since 2014: * https://groups.google.com/forum/#!topic/gitblit/GH1d8WSlR6Q * https://bugs.chromium.org/p/gerrit/issues/detail?id=3316 * https://groups.google.com/d/msg/repo-discuss/Kcl0JIGNiGk/0DjH4mO8hA8J * https://groups.google.com/d/msg/repo-discuss/0_P6A3fjTec/2kcpVPIUAQAJ * gitblit-org#1011 * tomaswolf/gerrit-gitblit-plugin#21
|
More details and analysis can be found at tomaswolf/gerrit-gitblit-plugin#21 (comment) and following comments. |
chalstrick
pushed a commit
to chalstrick/jgit
that referenced
this pull request
Nov 24, 2016
ObjectId is serializable, and so are its subtypes. Ensure that serialization does not follow the hash collision chain internal to the ObjectIdOwnerMap, otherwise completely unrelated objects may get serialized when a RevObject is serialized. Note that serializing a RevCommit or RevTag may serialize quite a few objects due to the parent/object links they contain. A user has no real control over how many objects will be written when a RevCommit is serialized. C.f [1]. This change does not resolve that, but in any case this internal hash collision chain link should not participate in serialization. [1] gitblit-org/gitblit#1141 Change-Id: Ice331a9dc80a59ca360fcc04adaff8b5e750d847 Signed-off-by: Thomas Wolf <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
They are caused by Gitblit pages holding references to JGit RevCommits.
JGit commit objects are a recursive data structure; they have links to
their parent commits. Serializing a JGit commit will try to recursively
serialize all reachable ancestors as faras they have been loaded. If
that ancestor chain is too long, a StackOverflowError is thrown during
Wicket's page serialization if a page has a reference to sucha JGit
commit.
Fixed by making sure that pages o not contain references to JGit
commits. Use the (existing) wrapper object RepositoryCommit instead.
reads the commit from the repository upon de-serialization.
to the commits they point to). Solved a bit differently by making it
a pure data object by transferring the interesting data from the JGit
object in the constructor.
instead.
synthesized field referencing the "allRefs" map. Such a synthesized
field would also get serialized, and then serialize JGit commits
again.
Finally, remove non-transient logger instances in Wicket classes. Those
might lead to NotSerializableException.
These StackOverflowErrors have been reported in several places since
2014: