git/t/t5321-pack-large-objects.sh

#!/bin/sh
#
# Copyright (c) 2018 Johannes Schindelin
#

test_description='git pack-object with "large" deltas

'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-pack.sh

# Two similar-ish objects that we have computed deltas between.
A=01d7713666f4de822776c7622c10f1b07de280dc
B=e68fe8129b546b101aee9510c5328e7f21ca1d18

test_expect_success 'setup' '
	clear_packs &&
	{
		pack_header 2 &&
		pack_obj $A $B &&
		pack_obj $B
	} >ab.pack &&
	pack_trailer ab.pack &&
	git index-pack --stdin <ab.pack
'

test_expect_success 'repack large deltas' '
	printf "%s\\n" $A $B |
	GIT_TEST_OE_DELTA_SIZE=2 git pack-objects tmp-pack
'

test_done
pack-objects (mingw): demonstrate a segmentation fault with large deltas There is a problem in the way 9ac3f0e5b3e4 (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 https://github.com/git-for-windows/git/issues/1839. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-16 21:02:50 +00:00			`#!/bin/sh`
			`#`
			`# Copyright (c) 2018 Johannes Schindelin`
			`#`

			`test_description='git pack-object with "large" deltas`

			`'`
			`. ./test-lib.sh`
			`. "$TEST_DIRECTORY"/lib-pack.sh`

			`# Two similar-ish objects that we have computed deltas between.`
			`A=01d7713666f4de822776c7622c10f1b07de280dc`
			`B=e68fe8129b546b101aee9510c5328e7f21ca1d18`

			`test_expect_success 'setup' '`
			`clear_packs &&`
			`{`
			`pack_header 2 &&`
			`pack_obj $A $B &&`
			`pack_obj $B`
			`} >ab.pack &&`
			`pack_trailer ab.pack &&`
			`git index-pack --stdin <ab.pack`
			`'`

pack-objects (mingw): initialize `packing_data` mutex in the correct spot In 9ac3f0e5b3e4 (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 https://github.com/git-for-windows/git/issues/1839. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-16 21:02:52 +00:00			`test_expect_success 'repack large deltas' '`
pack-objects (mingw): demonstrate a segmentation fault with large deltas There is a problem in the way 9ac3f0e5b3e4 (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 https://github.com/git-for-windows/git/issues/1839. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-16 21:02:50 +00:00			`printf "%s\\n" $A $B \|`
			`GIT_TEST_OE_DELTA_SIZE=2 git pack-objects tmp-pack`
			`'`

			`test_done`