git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Ali Polatel]

[-- Attachment #1: Type: text/plain, Size: 6516 bytes --]

$subject.
git version 1.6.4

Here's what gdb has to say about it:

2456 alip@harikalardiyari> gdb --args git clone http://git.savannah.gnu.org/cgit/xboard.git
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
(gdb) run
Starting program: /usr/bin/git clone http://git.savannah.gnu.org/cgit/xboard.git
[Thread debugging using libthread_db enabled]
Initialized empty Git repository in /usr/src/alip/xboard/.git/
[New Thread 0x7f382f0566f0 (LWP 28121)]
got 6db08230fafeb8a5fd163689e0225608bac64169
walk 6db08230fafeb8a5fd163689e0225608bac64169
Getting alternates list for http://git.savannah.gnu.org/cgit/xboard.git
got 94a064d8ab2c5e91d542015dd7307924b20ce729
got a72effb29a1f88097fa34240d35380128c3c84c8
got 6cab23ba23301b578d4995f3c889e574ea4b9e99
Getting pack list for http://git.savannah.gnu.org/cgit/xboard.git
Getting index for pack 720d634dfc5e7511332c1e6851f7c5c5f88e7af2
Getting index for pack 06483273097cbac210f10a4bd43324ae660053e6
Getting index for pack a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6
Getting pack 720d634dfc5e7511332c1e6851f7c5c5f88e7af2
 which contains a91f883e599185408c2e868458fc870b45f90647
walk a91f883e599185408c2e868458fc870b45f90647
walk 94a064d8ab2c5e91d542015dd7307924b20ce729
walk 6cab23ba23301b578d4995f3c889e574ea4b9e99
got ceb25797d2bdef03233071092e73d7cdf750a63d
got 00f19ab354710c1f41deba65b92af335317b25e5
walk 00f19ab354710c1f41deba65b92af335317b25e5
got 5195908348d5a926726de5d5447a27febd58b0c5
got c7646fb352bb0f7a286e991d893604190d6144bb
got b24e950f7c4105d99cb16959934231ee041e2b4e
Getting pack a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6
 which contains 94a9ed024d3859793618152ea559a168bbcbb5e2
got b72e3e511a5aecf63c36ec720d819babc4a32e80
got 96872f2a88d025fb298254d7215b0a2a46ab2517
got 0a785501c2a0af15b29498dc5304d4f78e464724
got 41c83fb406c79f7482de0a63b3a41d7cdc5d9930
got 8f5adeee096e8325a77f4d0f1198c6de3e5c8c4d
got eb8df7d39eaa78cbba8ea6d43e48a9d5565f85c4
got af0c6fb67a21096bde685ebbb442089e158eaab7
got 81d056612386f3bfbb2d954b1776b385b77b0354
got 2ec8546ca81919b50458f2dfee0fb04deb909732
got fd3b1e187f4711df4b2b9be7a538e5e7a6a9d974
got 15bb2bd5db019f4b5873ff47a81876bf744fe3b7
got d0f226bee1b67eecf307cc625925a0aa6b7543ec
got 266e77e80239db82c6c9c74190b172bb4eb9aa2d
got a546658f7c58b1f72e13d038efc77347060ddcb6
got 87f71b2afc316dc18ed39ec5e0eba041b9bc850e
got c89673fe13e92003dd53fc590b682f4bae229a0f
got 71d706e2cd500e15b0b3fcccaba5530a85173759
got a0978a0f361032a670dc644752dae210a2b3d1e8
got 17463be1dd790b3c8e64eaae95135add449e82db
got 8b401ae12b0e72fe9b03ea1b08b2e4cb89378a8d
got 6cdb7dfebf13e58ce8bbca0a2890057694eee073
got f997ac9797b7427a2c3e3abf8dd95bc2df2bf028
got 7d80cb4c3eb366e28f542b095f958289b4a719e3
got 40fb9ce5458e0df6f33160d7392a8b56aa0e1501
got f945dbf2bcef821a53120501b0a06fc0388a2d5c
got c7b87e2a937e0e83a6f6347649e38c1e4636c14a
got b5b9c2fdb4f3964777c3a3f2f92d2784430feddd
got 0d4b26f7ca8c3108d839e9e339adecb8d1395aad
got b2fcec6a8916695ecb5f1007db2e7fc504d23d05
got 82957eb41b19cd497b761c42cebb4580bddd6baf
got 394a9fdac5b251114074c8bea117c5676fd7caa5
got 9c345f61dd8eaf6c5fb45cc90bb133227609608a
got f02507f1df2b2fc9e999d89b2003ef80b92fae8b
got 5806d53acedf3633d17151c1dd3d0f7316dc3264
got 460073895fc709ae6844800bbe61300bf51a0154
got d4c3dbec93edfd27c52775178ba11242ded59193
got e777067113c5726d1706f266de057aa7361dbec5
got 46e2b200ccb840dfab62258434570c840ebebfa1
got f020f22a9ab9e88c6585d8b204aa8ce016a291e5
got 02c9ec3643c6eb94212be431c72a11f03b4e5b1a
got 0657847b19f925d8af5f450c78dda46f8ae5f7d0
got 05af22bd8201f75fb9718382a3307eda68d5e976
got 427cd7d5dfc211ccd962a18bc9666c72a7966b79
got 77d5bf31108026eb97c6b8e288c9d6d092b767dd
got 22737c1f642d614a14045c72a648bfb0fbfbf9da
got b95f2d1475ce464e507d4dbaf2e3af8f6b6f9a48
got f718239d651c2476ff8b7abff7940d2054f44e4f
got ba30dcb13a69fd3b82a10da5456e47b448d4bcc9
got 83d0f555a7dad1d410761ec89273d795f038860c
got 562609284c1f98090bd14dfddbbe2a4991d1e5a8
got d9a98ef891407dd11863ff5e2553ff79aa24d32e
got 0ae04cca10cea96e05c7d4c261aa5d3b208a0b47
got db9e377a69a3d6bd4a8256d00dca3bee680a6a2a
got 1e1e01c9481a519faffbaf6c645dfa8017cabdb5
got 6cd5f80a6aa0390d2412db7d49427ce845d7c946
got b5381c9bfd883c7a84167b022a64c5ca0385930d
got cd0415a4adb0af252cfdf588323a5814a249e90c
got 2a574b7641b9c0f6414b9943695391b6b8252a54
got 5d662edd417ae9f858cb374e03f09a7639b2c03d
got 2bae494f2cf9486b771c706a1eec6217e46ce778
got 8f84481839d7eeb3e0b0da0088b3093742b546cd
got a6d954d86827b3d3777c186d836f4b533602e567
walk 83d0f555a7dad1d410761ec89273d795f038860c
walk 2bae494f2cf9486b771c706a1eec6217e46ce778
Getting pack 06483273097cbac210f10a4bd43324ae660053e6
 which contains 74e24bdc2ec3f275da63ca1396a773e7043cb9e9

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f382f0566f0 (LWP 28121)]
0x00000000004ada21 in process_object_response (callback_data=<value optimized out>) at http-walker.c:93
93	http-walker.c: No such file or directory.
	in http-walker.c
(gdb) thread apply all bt

Thread 1 (Thread 0x7f382f0566f0 (LWP 28121)):
#0  0x00000000004ada21 in process_object_response (callback_data=<value optimized out>) at http-walker.c:93
#1  0x00000000004ab3e3 in process_curl_messages () at http.c:657
#2  0x00000000004ab475 in step_active_slots () at http.c:571
#3  0x00000000004add95 in fetch (walker=0x13d3b50, sha1=<value optimized out>) at http-walker.c:476
#4  0x00000000004a74e3 in walker_fetch (walker=0x13d3b50, targets=4, target=<value optimized out>, write_ref=0x0, 
    write_ref_log_details=<value optimized out>) at walker.c:176
#5  0x00000000004a0e46 in fetch_objs_via_curl (transport=0x20, nr_objs=4, to_fetch=0x13d5780) at transport.c:375
#6  0x000000000049feab in transport_fetch_refs (transport=0x13d4300, refs=<value optimized out>) at transport.c:1064
#7  0x0000000000416a05 in cmd_clone (argc=<value optimized out>, argv=<value optimized out>, prefix=<value optimized out>)
    at builtin-clone.c:513
#8  0x0000000000404391 in handle_internal_command (argc=2, argv=0x7fff89c74b10) at git.c:246
#9  0x000000000040453d in main (argc=2, argv=0x7fff89c74b10) at git.c:438
(gdb) 

-- 
Regards,
Ali Polatel

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, Ali Polatel wrote:

> Here's what gdb has to say about it:
>
> [...]

Here's what valgrind has to say about it (with a current 'next' + 
patches):

==25434== Invalid read of size 8
==25434==    at 0x407433: process_object_response (http-walker.c:91)
==25434==    by 0x405713: finish_active_slot (http.c:657)
==25434==    by 0x40448F: process_curl_messages (http.c:119)
==25434==    by 0x40546A: step_active_slots (http.c:571)
==25434==    by 0x4080E8: fetch_object (http-walker.c:476)
==25434==    by 0x408316: fetch (http-walker.c:526)
==25434==    by 0x42876C: loop (walker.c:176)
==25434==    by 0x428C65: walker_fetch (walker.c:287)
==25434==    by 0x40401F: main (remote-curl.c:111)

Ciao,
Dscho

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, Johannes Schindelin wrote:

> On Mon, 17 Aug 2009, Ali Polatel wrote:
> 
> > Here's what gdb has to say about it:
> >
> > [...]
> 
> Here's what valgrind has to say about it (with a current 'next' + 
> patches):
> 
> ==25434== Invalid read of size 8
> ==25434==    at 0x407433: process_object_response (http-walker.c:91)
> ==25434==    by 0x405713: finish_active_slot (http.c:657)
> ==25434==    by 0x40448F: process_curl_messages (http.c:119)
> ==25434==    by 0x40546A: step_active_slots (http.c:571)
> ==25434==    by 0x4080E8: fetch_object (http-walker.c:476)
> ==25434==    by 0x408316: fetch (http-walker.c:526)
> ==25434==    by 0x42876C: loop (walker.c:176)
> ==25434==    by 0x428C65: walker_fetch (walker.c:287)
> ==25434==    by 0x40401F: main (remote-curl.c:111)

Oops, forgot the more important part:

==25434==  Address 0x87a7bd0 is 0 bytes inside a block of size 64 free'd
==25434==    at 0x4C265AF: free (vg_replace_malloc.c:323)
==25434==    by 0x4075F5: release_object_request (http-walker.c:128)
==25434==    by 0x408022: abort_object_request (http-walker.c:452)
==25434==    by 0x4080D7: fetch_object (http-walker.c:470)
==25434==    by 0x408316: fetch (http-walker.c:526)
==25434==    by 0x42876C: loop (walker.c:176)
==25434==    by 0x428C65: walker_fetch (walker.c:287)
==25434==    by 0x40401F: main (remote-curl.c:111)

Seems that an object request is aborted, but the slot, and therefore the 
callback, is called nevertheless.  Tay, does that ring a bell?

Ciao,
Dscho

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Lars Hjemli]

On Mon, Aug 17, 2009 at 15:56, Ali Polatel<polatel@gmail.com> wrote:
> $subject.
> git version 1.6.4
>
> Here's what gdb has to say about it:
>
> 2456 alip@harikalardiyari> gdb --args git clone http://git.savannah.gnu.org/cgit/xboard.git
>...
> Getting pack 06483273097cbac210f10a4bd43324ae660053e6
>  which contains 74e24bdc2ec3f275da63ca1396a773e7043cb9e9
>
> Program received signal SIGSEGV, Segmentation fault.

This is the http clone interface generated by cgit, and a quick test
gives me an identical segfault, while `git clone
http://git.sv.gnu.org/r/xboard.git` succeeds. I can only guess, but
maybe this has something to do with caching in cgit:

$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/info/packs
P pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
P pack-06483273097cbac210f10a4bd43324ae660053e6.pack
P pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack

$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
>pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack

$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.idx
>pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.idx

$ git verify-pack -v pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack
[snip]
non delta: 115 objects
chain length = 1: 64 objects
chain length = 2: 57 objects
chain length = 3: 16 objects
chain length = 4: 10 objects
chain length = 5: 7 objects
chain length = 6: 1 object
pack-720d634dfc5e7511332c1e6851f7c5c5f88e7af2.pack: ok

$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-06483273097cbac210f10a4bd43324ae660053e6.pack
>pack-06483273097cbac210f10a4bd43324ae660053e6.pack

$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-06483273097cbac210f10a4bd43324ae660053e6.idx
>pack-06483273097cbac210f10a4bd43324ae660053e6.idx

$ git verify-pack -v pack-06483273097cbac210f10a4bd43324ae660053e6.pack
[snip]
74e24bdc2ec3f275da63ca1396a773e7043cb9e9 blob   921 286 12694
[snip]
non delta: 233 objects
chain length = 1: 86 objects
chain length = 2: 74 objects
chain length = 3: 47 objects
chain length = 4: 8 objects
chain length = 5: 5 objects
chain length = 6: 1 object
pack-06483273097cbac210f10a4bd43324ae660053e6.pack: ok


$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack
>pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack

$ curl http://git.savannah.gnu.org/cgit/xboard.git/objects/pack/pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.idx
>pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.idx

$ git verify-pack -v pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack
[snip]
non delta: 1139 objects
chain length = 1: 454 objects
chain length = 2: 349 objects
chain length = 3: 301 objects
chain length = 4: 235 objects
chain length = 5: 179 objects
chain length = 6: 96 objects
chain length = 7: 52 objects
chain length = 8: 37 objects
chain length = 9: 21 objects
chain length = 10: 6 objects
chain length = 11: 5 objects
chain length = 12: 1 object
chain length = 13: 2 objects
chain length = 14: 1 object
chain length = 15: 2 objects
chain length = 16: 1 object
chain length = 17: 1 object
chain length = 18: 2 objects
chain length = 19: 1 object
chain length = 20: 1 object
chain length = 21: 1 object
chain length = 22: 1 object
chain length = 23: 2 objects
chain length = 24: 2 objects
chain length = 25: 1 object
chain length = 26: 1 object
chain length = 27: 1 object
chain length = 28: 1 object
chain length = 29: 1 object
chain length = 30: 1 object
chain length = 31: 1 object
chain length = 32: 1 object
chain length = 33: 2 objects
chain length = 34: 3 objects
chain length = 35: 2 objects
chain length = 36: 1 object
chain length = 37: 1 object
chain length = 38: 1 object
chain length = 39: 2 objects
chain length = 40: 3 objects
chain length = 41: 1 object
chain length = 42: 2 objects
chain length = 43: 1 object
chain length = 44: 1 object
chain length = 45: 2 objects
chain length = 46: 1 object
pack-a0a25c7cc57128b5317e0b5e7b8de7a59afe9af6.pack: ok

Hmm, the packs looks ok so maybe the problem is related to our usage
of libcurl after all...

--
larsh

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Tay Ray Chuan]

Hi,

On Mon, Aug 17, 2009 at 10:22 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Seems that an object request is aborted, but the slot, and therefore the
> callback, is called nevertheless.  Tay, does that ring a bell?

thanks Johannes, your diagnosis was a vital clue.

Ali, could you see if this patch fixes it for you? On my side, I had
some difficulty reproducing your problem reliably (it happened
sometimes but not on other times).

--
Cheers,
Ray Chuan

-- >8 --
Subject: [PATCH] http.c: set slot callback members to NULL when releasing object

Set the members callback_func and callback_data of freq->slot to NULL
when releasing a http_object_request. release_active_slot() is also
invoked on the slot to remove the curl handle associated with the slot
from the multi stack (CURLM *curlm in http.c).

These prevent the callback function and data from being used in http
methods (like http.c::finish_active_slot()) after a
http_object_request has been free'd.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
 http.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/http.c b/http.c
index a2720d5..1ae19e0 100644
--- a/http.c
+++ b/http.c
 -1285,5 +1285,10 @@ void release_http_object_request(struct http_object_request *freq)
 		free(freq->url);
 		freq->url = NULL;
 	}
-	freq->slot = NULL;
+	if (freq->slot != NULL) {
+		freq->slot->callback_func = NULL;
+		freq->slot->callback_data = NULL;
+		release_active_slot(freq->slot);
+		freq->slot = NULL;
+	}
 }
--
1.6.4.193.gaceaa.dirty

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Ali Polatel]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Tay Ray Chuan yazmış:
> Hi,
> 
> On Mon, Aug 17, 2009 at 10:22 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > Seems that an object request is aborted, but the slot, and therefore the
> > callback, is called nevertheless.  Tay, does that ring a bell?
> 
> thanks Johannes, your diagnosis was a vital clue.
> 
> Ali, could you see if this patch fixes it for you? On my side, I had
> some difficulty reproducing your problem reliably (it happened
> sometimes but not on other times).
> 

It works, I don't get any segfaults after applying this patch.

-- 
Regards,
Ali Polatel

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 857 bytes --]

Hi,

On Wed, 26 Aug 2009, Ali Polatel wrote:

> Tay Ray Chuan yazmış:
> 
> > On Mon, Aug 17, 2009 at 10:22 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > > Seems that an object request is aborted, but the slot, and therefore 
> > > the callback, is called nevertheless.  Tay, does that ring a bell?
> > 
> > thanks Johannes, your diagnosis was a vital clue.
> > 
> > Ali, could you see if this patch fixes it for you? On my side, I had
> > some difficulty reproducing your problem reliably (it happened
> > sometimes but not on other times).
> > 
> 
> It works, I don't get any segfaults after applying this patch.

Great!

But why did you drop me from the Cc: list?  It's not every day that I can 
pay that close attention to the mails I get; mails which are not addressed 
to me directly fall off the plate on other days...

Ciao,
Dscho

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Tay Ray Chuan]

Hi,

2009/8/26 Ali Polatel <polatel@gmail.com>:
> It works, I don't get any segfaults after applying this patch.

Junio, I hope you don't mind me asking but why hasn't this patch been
accepted? It addresses a pretty severe problem, and the sooner users
have it the better.

-- 
Cheers,
Ray Chuan

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Junio C Hamano]

Tay Ray Chuan <rctay89@gmail.com> writes:

> 2009/8/26 Ali Polatel <polatel@gmail.com>:
>> It works, I don't get any segfaults after applying this patch.
>
> Junio, I hope you don't mind me asking but why hasn't this patch been
> accepted? It addresses a pretty severe problem, and the sooner users
> have it the better.

The procedure ideally goes like this:

    (0) original bug report is sent; Ali did this with:

        Date: Mon, 17 Aug 2009 16:56:52 +0300
        Message-ID: <20090817135651.GA4570@harikalardiyari>

    (1) a helpful contributor (or somebody ashamed of having introduced
        the bug ;-)) sends a potential fix as an RFT to the reporter, with
        Cc: to list.  You did this with:

        Date: Wed, 26 Aug 2009 20:20:53 +0800
        Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>

	This message was clear that it was a request-for-test of a
	potential fix, not a "I know this is the correct fix to the
	problem; the maintainer, please apply".  It wasn't even Cc:'ed to
	me, and not CC'ing me is the right thing to do for this kind of
	request-for-test patches.

    (2) success/failure report is given.  Ali did this with:

        Date: Wed, 26 Aug 2009 16:12:35 +0300
        Message-ID: <20090826131235.GF16486@harikalardiyari>

	to report a success.

    (3) Upon seeing (2), the sender of (1) submits the final patch for
        inclusion, with To: me and CC: list.

        The sender makes sure that it is easy for me and others who sees
        (3) first without necessarily having followed the earlier
        discussions to find the previous messages (i.e. 0, 1, 2).  In this
        case, sending a follow-up to (2) is sufficient, just like you did
        in the message I am responding to, because these three steps were
        neatly threaded already.

        If you knew the flow I am describing here, you would have sent
        "the final patch for inclusion" instead of the message I am
        replying to.  The final patch for inclusion would have consisted
        of:

	* The usual "applicable patch": a proper subject, the log message,
          your Signed-off-by:, and Tested-by: to credit Ali;

        * Optionally, after the three-dash line before the diffstat, any
          out-of-band communication, e.g.

          "Junio, please apply to 'maint'; this is a fix for a grave bug,
          and the problem goes all the way down to version 1.6.1."

        * And the diffstat and the diff.

My request for this procedure is not red tape.

While an issue (such as this http one) is resolved that is in an area
(e.g. http) people other than me (i.e. you) are much more familiar with, I
do not have to keep track of the discussion while more capable hands are
on top of it.  Having (3) as the concluding step will

 - give me a way to easily verify, if I wanted to, the claim that this is
   the right solution, by referring to the previous dialog; and

 - give you a way to make sure that what is recorded is the correct final
   solution (this is especially important if steps 1 and 2 have to be
   repeated before reaching the final solution), and that the necessary
   background information (e.g. credits to the original reporter) are
   given in your own words, instead of having _me_ come up with one with
   less-than-perfect understanding of the issues I would gain after
   skimming the archive for the previous discussion.

Nobody can expect me to keep track of everything; the final "Here is the
good one" would help the process flow smoothly and reduce the chance of
mistakes.

Thanks.

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Nobody can expect me to keep track of everything; the final "Here is the
> good one" would help the process flow smoothly and reduce the chance of
> mistakes.

I forgot to add...

In this case, it is _now_ clear to me that you consider your 

    Subject: Re: git clone http://git.... segfaults
    To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
    Cc: Ali Polatel <polatel@gmail.com>, git@vger.kernel.org
    Date: Wed, 26 Aug 2009 20:20:53 +0800
    Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>

to be the final version, so I'd just add "noticed by Ali Polatel who later
tested this patch to verify; Dscho helped to identify the problem spot."
at the end of the commit log message in the message and apply.  IOW, no
need to resend.

Ali's original report is about 1.6.4 so I presume this is 'maint'
material, so let's include this in 1.6.4.2.

Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults

[Tay Ray Chuan]

Hi,

On Sat, Aug 29, 2009 at 9:10 AM, Junio C Hamano<gitster@pobox.com> wrote:
> I forgot to add...
>
> In this case, it is _now_ clear to me that you consider your
>
>    Subject: Re: git clone http://git.... segfaults
>    To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>    Cc: Ali Polatel <polatel@gmail.com>, git@vger.kernel.org
>    Date: Wed, 26 Aug 2009 20:20:53 +0800
>    Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
>
> to be the final version,

(I refer to this and your previous message) Thanks for taking the time
to explain the procedures/workflow involved. Yes, I thought Ali's
report on the patch was sufficient to flag the patch as
here-is-the-good one, but I didn't indicate this to you clearly
enough. Sorry for all the trouble.

> so I'd just add "noticed by Ali Polatel who later
> tested this patch to verify; Dscho helped to identify the problem spot."
> at the end of the commit log message in the message and apply.  IOW, no
> need to resend.

Thanks again. Somehow, I neglected to include credits to Ali and Dscho.

-- 
Cheers,
Ray Chuan