git gc crashes at 33% of counting objects #1839
Comments
|
Just want to add that I'm seeing this too, and it affects more than just (Not sure why the output errors are partially interleaved...) Rolling back to 2.18 fixes both issues for me, so I don't think it's real corruption. Running Unfortunately, like @michalfita, I am unable to share the repo. |
|
It seems that I am affected by this problem as well. Since 2.19.0.windows.1 I cannot execute I am running Windows 10 64Bit (Microsoft Windows [Version 10.0.17134.285]) on both machines. The repository in question is https://github.com/ultimate-pa/ultimate -- perhaps an interesting thing is that we need long paths. Output with |
|
I'm hitting this as well on a moderately large repo. This is breaking gc, bundle, and push operations (not sure what else). I'm going to try going back to 1.18 to see if that fixes the issue. C:>git --version --build-options C:>cmd.exe /c ver Microsoft Windows [Version 10.0.17763.1] C:>type "C:\Program Files\Git\etc\install-options.txt" |
|
Good news is that I can downgrade to 2.18.x and have it working again. |
|
I see the same behavior.
5 0 10586 117
Debugging shows The call stack -
Dump SummaryDump File: git.dmp : E:\temp\git.dmp System InformationOS Version: 6.1.7601 ModulesModule Name Module Path Module Version git.exe C:\Program Files\Git\mingw64\libexec\git-core\git.exe 2.19.0.1 |
|
Same for me. Downgrading to 1.18 fixed the issue. |
|
I have the same issue and I can reproduce it with 2 specific binary files:
I hope someone can fix it. $ git version |
|
If you have a few minutes spare (~30+), are you able to try a bit of debugging via the SDK and wiki advice? Also, that second fail, did it really have the trailing That would suggest that the line Plus the fact that this was second time around. (maybe a pack hadn't been fully written correctly on Windows) |
|
Sorry, I have no time at this moment. But next week I'll try the SDK. Also, that second fail, did it really have the trailing ) close brackets? May this will be helpful: |
|
I have been working on this issue with @thomas-patzig and can share a few observations that may also be helpful:
|
|
Hi, ...and the same issue: What should I test? |
|
Have a check that the write and read process (in git) do complete properly, and that there are no stray (temporary repacking) files left over in directories. If I remember correctly, the Linux way of preparing the files may conflict with the Windows way (inodes and ownership stuff). I think the git project will be writing a temporary file, and then attempting to rename it in place to become the new pack file. It maybe that some virus scanner has an open handle on the temp file, so windows won't release it for the rename, or one of many variants on those lines. Maybe have a look at #1769 to gain more clues as to the GfW tribulations. |
|
@thomas-patzig Great MCVE! The access violation is caused by using an uninitialized critical section by The code is only triggered when processing a large delta, which was created for the two big binary files in your MCVE: Moving the initialization to diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index d1144a8f7e..29d48f3867 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2299,7 +2299,6 @@ static void init_threaded_search(void)
pthread_mutex_init(&cache_mutex, NULL);
pthread_mutex_init(&progress_mutex, NULL);
pthread_cond_init(&progress_cond, NULL);
- pthread_mutex_init(&to_pack.lock, NULL);
old_try_to_free_routine = set_try_to_free_routine(try_to_free_from_threads);
}
diff --git a/pack-objects.c b/pack-objects.c
index 6ef87e5683..6070b6d565 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -148,6 +148,8 @@ void prepare_packing_data(struct packing_data *pdata)
1U << OE_SIZE_BITS);
pdata->oe_delta_size_limit = git_env_ulong("GIT_TEST_OE_DELTA_SIZE",
1UL << OE_DELTA_SIZE_BITS);
+
+ pthread_mutex_init(&pdata->lock, NULL);
}
struct object_entry *packlist_alloc(struct packing_data *pdata,Change available on my branch pack-lock-init. |
|
Just to add my +1, I am also hitting this issue with Git for Windows 2.19.0. As it has for others, reverting to Git for Windows 2.18.0 fixes the problem for me. |
|
I built the branch https://github.com/kgybels/git/commits/pack-lock-init, and I have not seen this issue again. At least one of my coworkers has also been using this fix successfully. |
The real question here is: why has the |
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 <[email protected]>
An [occasional crash in `git gc`](git-for-windows/git#1839) (which had been introduced into v2.19.0) has been fixed. Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Johannes Schindelin <[email protected]>
…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 #1839. Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
…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 <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 #1839. Signed-off-by: Doug Kelly <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Setup
defaults?
to the issue you're seeing?
My repository doesn't use any symlinks. I'm forced to use McAfee antivirus solutions. I'm using poshgit.
Details
PowerShell Core 6
Minimal, Complete, and Verifiable example
this will help us understand the issue.
Finished garbage collection, especially as automated crashes either.
URL to that repository to help us with testing?
It's proprietary repository belonging to my company, so I can't.
The text was updated successfully, but these errors were encountered: