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

Fix gc segfault #47

Closed
wants to merge 3 commits into from
Closed

Conversation

jamill
Copy link

@jamill jamill commented Oct 15, 2018

In 9ac3f0e (pack-objects: fix performance issues on packing large
deltas, 2018-07-22), a mutex was introduced that is used to guard the
call to set the delta size. This commit added code to initialize
it, but at an incorrect spot: in init_threaded_search(), while the
call to oe_set_delta_size() (and hence to packing_data_lock()) can
happen in the call chain check_object() <- get_object_details() <-
prepare_pack() <- cmd_pack_objects(), which is long before the
prepare_pack() function calls ll_find_deltas() (which initializes
the threaded search).

Another tell-tale that the mutex was initialized in an incorrect spot is
that the function to initialize it lives in builtin/, while the code
that uses the mutex is defined in a libgit.a header file.

Let's use a more appropriate function: prepare_packing_data(), which
not only lives in libgit.a, but has to be called before the
packing_data struct is used that contains that mutex.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is a problem in the way 9ac3f0e (pack-objects: fix
performance issues on packing large deltas, 2018-07-22) initializes that
mutex in the `packing_data` struct. The problem manifests in a
segmentation fault on Windows, when a mutex (AKA critical section) is
accessed without being initialized. (With pthreads, you apparently do
not really have to initialize them?)

This was reported in git-for-windows#1839.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…spot

In 9ac3f0e (pack-objects: fix performance issues on packing large
deltas, 2018-07-22), a mutex was introduced that is used to guard the
call to set the delta size. This commit even added code to initialize
it, but at an incorrect spot: in `init_threaded_search()`, while the
call to `oe_set_delta_size()` (and hence to `packing_data_lock()`) can
happen in the call chain `check_object()` <- `get_object_details()` <-
`prepare_pack()` <- `cmd_pack_objects()`, which is long before the
`prepare_pack()` function calls `ll_find_deltas()` (which initializes
the threaded search).

Another tell-tale that the mutex was initialized in an incorrect spot is
that the function to initialize it lives in builtin/, while the code
that uses the mutex is defined in a libgit.a header file.

Let's use a more appropriate function: `prepare_packing_data()`, which
not only lives in libgit.a, but *has* to be called before the
`packing_data` struct is used that contains that mutex.

This fixes git-for-windows#1839.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@derrickstolee
Copy link

/allow

@gitgitgadget
Copy link

gitgitgadget bot commented Oct 16, 2018

User undefined is now allowed to use GitGitGadget.

@derrickstolee
Copy link

/allow jamill

@gitgitgadget
Copy link

gitgitgadget bot commented Oct 16, 2018

User jamill already allowed to use GitGitGadget.

@jamill
Copy link
Author

jamill commented Oct 16, 2018

@dscho I updated the PR description. I updated the test number to not conflict with other tests that have been added upstream. Is there anything else I should check before slash-submitting this?

@dscho
Copy link
Member

dscho commented Oct 16, 2018

@jamill I think all that remains to do is: submit (see e.g. #31 (comment)).

@jamill
Copy link
Author

jamill commented Oct 16, 2018

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Oct 16, 2018

Submitted as pull.47.git.gitgitgadget@gmail.com

Copy link
Member

dscho commented Nov 5, 2018

This branch is now known as js/pack-objects-mutex-init-fix.

Copy link
Member

dscho commented Nov 5, 2018

This patch series was integrated into pu via git@620b00e.

Copy link
Member

dscho commented Nov 5, 2018

This patch series was integrated into next via git@620b00e.

Copy link
Member

dscho commented Nov 5, 2018

This patch series was integrated into master via git@620b00e.

Copy link
Member

dscho commented Nov 5, 2018

Closed via 620b00e.

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

Successfully merging this pull request may close these issues.

3 participants