from:"Wataru Noguchi"

[PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.

2013-09-25 Thread Wataru Noguchi

Git for Windows crashes when clone Japanese multibyte repository.
- Japanese Base Encoding is Shift-JIS.
- It happens Japanese multibyte directory name and too-long directory path
- Linux(ex. Ubuntu 13.04 amd64) can clone normally.
- example repository is here:

git clone https://github.com/wnoguchi/mingw-checkout-crash.git

- The reproduce crash repository contains following file only.
  - following directory and file name is encoded for this commit log.
  - actually file name is decoded.]
  
%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt
- only one commit.

This commit reduce gcc optimization level from O2 to O1 when MinGW Windows 
environment.

Signed-off-by: Wataru Noguchi 
---
 git-compat-util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/git-compat-util.h b/git-compat-util.h
index a31127f..394c23b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -90,6 +90,8 @@
 #define WIN32_LEAN_AND_MEAN  /* stops windows.h including winsock.h */
 #include 
 #include 
+/* reduce gcc optimization level to 1 */
+#pragma GCC optimize ("O1")
 #define GIT_WINDOWS_NATIVE
 #endif
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] Re: [PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.

2013-09-25 Thread Wataru Noguchi

Hi,

I'm sorry resend email many times...
My GMail setting default to HTML format.
So mail sent to Git ML is rejected...


Thanks for your reply.

> If changing the optimization level turns out to be the right fix, I
> would prefer to see this change made in the Makefile instead of
> git-compat-util.h.

Yes, I see.
I think so.
I shuld write optimization level change code to Makefile instead of
git-compat-util.h.



2013/9/26 Jonathan Nieder :
> (cc-ing the Git for Windows maintainers)
> Hi,
>
> Wataru Noguchi wrote:
>
>> Git for Windows crashes when clone Japanese multibyte repository.
>> - Japanese Base Encoding is Shift-JIS.
>> - It happens Japanese multibyte directory name and too-long directory path
>> - Linux(ex. Ubuntu 13.04 amd64) can clone normally.
>> - example repository is here:
>>
>> git clone https://github.com/wnoguchi/mingw-checkout-crash.git
>>
>> - The reproduce crash repository contains following file only.
>>   - following directory and file name is encoded for this commit log.
>>   - actually file name is decoded.]
>>   
>> %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt
>> - only one commit.
>>
>> This commit reduce gcc optimization level from O2 to O1 when MinGW Windows 
>> environment.
>>
>> Signed-off-by: Wataru Noguchi 
>
> Thanks.
>
>> ---
>>  git-compat-util.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index a31127f..394c23b 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -90,6 +90,8 @@
>>  #define WIN32_LEAN_AND_MEAN  /* stops windows.h including winsock.h */
>>  #include 
>>  #include 
>> +/* reduce gcc optimization level to 1 */
>> +#pragma GCC optimize ("O1")
>>  #define GIT_WINDOWS_NATIVE
>>  #endif
>
> Do you know why reducing the optimization level avoids a crash?
> Perhaps this is just masking the symptoms and the problem is still
> lurking.
>
> If changing the optimization level turns out to be the right fix, I
> would prefer to see this change made in the Makefile instead of
> git-compat-util.h.  That way, the user building can still easily
> override the optimization settings to -O0 if they want to during a
> debugging session.
>
> What do you think?
>
> Hope that helps,
> Jonathan




Hi,

Thanks for your advise.

> To find out what the real cause is, I suggest using a tool similar to
> valgrind. Valgrind does not run on Windows, but I DuckDuckWent e.g.
> http://code.google.com/p/drmemory/ as an alternative that could be tried
> to identify the problem.

I will try debugging by using any tools more real cause.
* Valgrind and drmemory, etc.


2013/9/26 Johannes Schindelin :
> Hi,
>
> On Wed, 25 Sep 2013, Jonathan Nieder wrote:
>
>> Wataru Noguchi wrote:
>>
>> >   - actually file name is decoded.]
>> >   
>> > %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt
>> >
>> > This commit reduce gcc optimization level from O2 to O1 when MinGW
>> > Windows environment.
>>
>> Do you know why reducing the optimization level avoids a crash?
>
> I suspect that the optimization level causes smaller (or no) buffer bytes
> between data structures and the crash is the symptom of a buffer overflow.
> In that light, I think that reducing the optimization level is most likely
> just working around this particular issue, and other scenarios might still
> crash until we fix the underlying

[PATCH] mingw-multibyte: fix memory acces violation and path length limits.

2013-09-28 Thread Wataru Noguchi

fix: Git for Windows crashes when clone Japanese multibyte repository.

Reproduce condition:

- Japanese Base Encoding is Shift-JIS.
- It happens Japanese multibyte directory name and too-long directory path
- Linux(ex. Ubuntu 13.04 amd64) can clone normally.
- example repository is here:

git clone https://github.com/wnoguchi/mingw-checkout-crash.git

- The reproduce crash repository contains following file only.
  - following directory and file name is encoded for this commit log.
  - actually file name is decoded.]
  
%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt
- only one commit.

Cause:

- convert_attrs() in convert.c: if (!ccheck[0].attr) but ccheck[0].attr always 
not NULL.
  thus git_check_attr() in attr.c (check[i].attr->attr_nr) cause access 
violation.
- checkout_entry() in entry.c: static char path[PATH_MAX + 1]; declared.
  But its size is 261 on MinGW environment.
  This length is Windows full path limits. But for relative path is too short.

This commit fixes:

- convert_attrs() in convert.c: initialize ccheck[0].attr with NULL.
- git-compat-util.h: redifine PATH_MAX value to 4096 when MinGW environment.

Signed-off-by: Wataru Noguchi 
---
 convert.c |  5 +
 git-compat-util.h | 10 ++
 2 files changed, 15 insertions(+)

diff --git a/convert.c b/convert.c
index 11a95fc..5eaa206 100644
--- a/convert.c
+++ b/convert.c
@@ -724,6 +724,11 @@ static void convert_attrs(struct conv_attrs *ca, const 
char *path)
 {
int i;
static struct git_attr_check ccheck[NUM_CONV_ATTRS];
+   
+   if (NUM_CONV_ATTRS != 0) {
+   ccheck[0].attr = NULL;
+   ccheck[0].value = NULL;
+   }
 
if (!ccheck[0].attr) {
for (i = 0; i < NUM_CONV_ATTRS; i++)
diff --git a/git-compat-util.h b/git-compat-util.h
index a31127f..ba02c69 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -237,6 +237,16 @@ extern char *gitbasename(char *);
 #ifndef PATH_MAX
 #define PATH_MAX 4096
 #endif
+#ifdef GIT_WINDOWS_NATIVE
+/* Git for Windows checkout PATH_MAX is reduce to 260.
+ * but if checkout relative long path name, its length too short.
+ * thus, expand length.
+ */
+#ifdef PATH_MAX
+#undef PATH_MAX
+#endif
+#define PATH_MAX 4096
+#endif
 
 #ifndef PRIuMAX
 #define PRIuMAX "llu"
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

2013-09-28 Thread Wataru Noguchi


Hi,

Thanks for comments.

My currently working repository is

https://github.com/wnoguchi/git/tree/hotfix/mingw-multibyte-path-checkout-failure

I have revert commits to 1f10da3.
I'll try failure step.

- gcc optimization level is O2.(fail)
- gcc O0, O1 works fine.


$ gdb git-clone
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 "i686-pc-mingw32"...
(gdb) r https://github.com/wnoguchi/mingw-checkout-crash.git
Starting program: C:\msysgit\git/git-clone.exe https://github.com/wnoguchi/mingw
-checkout-crash.git
[New thread 800.0xa10]
Error: dll starting at 0x779f not found.
Error: dll starting at 0x7590 not found.
Error: dll starting at 0x779f not found.
Error: dll starting at 0x778f not found.
[New thread 800.0x92c]
Cloning into 'mingw-checkout-crash'...
Error: dll starting at 0x29f not found.
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 8 (delta 0), reused 8 (delta 0)
Unpacking objects: 100% (8/8), done.
Checking connectivity... done
[New thread 800.0xea0]

Program received signal SIGSEGV, Segmentation fault.
0x004d5200 in git_check_attr (
path=0xacc6a0 ""..., num=5, check=0x572440) at attr.c:754
754 const char *value = check_all_attr[check[i].attr->attr_n
r].value;
(gdb) list
749 int i;
750
751 collect_all_attrs(path);
752
753 for (i = 0; i < num; i++) {
754 const char *value = check_all_attr[check[i].attr->attr_n
r].value;
755 if (value == ATTR__UNKNOWN)
756 value = ATTR__UNSET;
757 check[i].value = value;
758 }
(gdb) up
#1  0x004a796b in convert_attrs (ca=0x28f950,
path=0xacc6a0 ""...) at convert.c:740
740 if (!git_check_attr(path, NUM_CONV_ATTRS, ccheck)) {
(gdb) list
735 ccheck[i].attr = git_attr(conv_attr_name[i]);
736 user_convert_tail = &user_convert;
737 git_config(read_convert_config, NULL);
738 }
739
740 if (!git_check_attr(path, NUM_CONV_ATTRS, ccheck)) {
741 ca->crlf_action = git_path_check_crlf(path, ccheck + 4);

742 if (ca->crlf_action == CRLF_GUESS)
743 ca->crlf_action = git_path_check_crlf(path, cche
ck + 0);
744 ca->ident = git_path_check_ident(path, ccheck + 1);
(gdb) list -
725 int i;
726 static struct git_attr_check ccheck[NUM_CONV_ATTRS];
727
728 //  if (NUM_CONV_ATTRS != 0) {
729 //  ccheck[0].attr = NULL;
730 //  ccheck[0].value = NULL;
731 //  }
732
733 if (!ccheck[0].attr) {
734 for (i = 0; i < NUM_CONV_ATTRS; i++)
(gdb) p ccheck[0].attr
$1 = (struct git_attr *) 0xa081e38f


Next, change PATH_MAX value to 4096 if MinGW environment.(6cae216)
Works fine.
Is this failure caused by PATH_MAX length too short? or my repository directory 
depth too deep?
But when optimization disabled(O0) in Makefile , works fine...(bf0acff)
Do you know what's happen?


Thanks.


(2013/09/29 8:18), Johannes Schindelin wrote:

Hi,

On Sun, 29 Sep 2013, Wataru Noguchi wrote:


--- a/convert.c
+++ b/convert.c
@@ -724,6 +724,11 @@ static void convert_attrs(struct conv_attrs *ca, const 
char *path)
  {
int i;
static struct git_attr_check ccheck[NUM_CONV_ATTRS];
+   
+   if (NUM_CONV_ATTRS != 0) {
+   ccheck[0].attr = NULL;
+   ccheck[0].value = NULL;
+   }


I wonder whether it would make more sense to use

memset(ccheck, 0, sizeof(ccheck))

? But then, ccheck is static and *should* be initialized to all 0
according to the C standard. And re-initializing it to NULL would
invalidate the values that were set earlier.

Also, if NUM_CONV_ATTRS == 0, I would expect


if (!ccheck[0].attr) {


to access an invalid location...


diff --git a/git-compat-util.h b/git-compat-util.h
index a31127f..ba02c69 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -237,6 +237,16 @@ extern char *gitbasename(char *);
  #ifndef PATH_MAX
  #define PATH_MAX 4096
  #endif
+#ifdef GIT_WINDOWS_NATIVE
+/* Git for Windows checkout PATH_MAX is reduce to 260.
+ * but if checkout relative long path name, its length too short.
+ * thus, expand length.
+ */
+#ifdef PATH_MAX
+#undef PATH_MAX
+#endif
+#define PATH_MAX 4096
+#endif


This looks fine, but I am wary... did you not say that a crash was caused
by this? In that case, we would have a user that

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

2013-10-01 Thread Wataru Noguchi


Hi,

Thanks for your patch.

Unfortunately, in my case still crash...

But PATH_MAX length kinds issues interesting.

I'll try investigate a little more.

- PATH_MAX and O2

Thanks.

(2013/10/01 2:00), René Scharfe wrote:

Am 29.09.2013 04:56, schrieb Wataru Noguchi:

Hi,

Thanks for comments.

My currently working repository is

https://github.com/wnoguchi/git/tree/hotfix/mingw-multibyte-path-checkout-failure

I have revert commits to 1f10da3.
I'll try failure step.

- gcc optimization level is O2.(fail)
- gcc O0, O1 works fine.


$ gdb git-clone
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 "i686-pc-mingw32"...
(gdb) r https://github.com/wnoguchi/mingw-checkout-crash.git
Starting program: C:\msysgit\git/git-clone.exe https://github.com/wnoguchi/mingw
-checkout-crash.git
[New thread 800.0xa10]
Error: dll starting at 0x779f not found.
Error: dll starting at 0x7590 not found.
Error: dll starting at 0x779f not found.
Error: dll starting at 0x778f not found.
[New thread 800.0x92c]
Cloning into 'mingw-checkout-crash'...
Error: dll starting at 0x29f not found.
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 8 (delta 0), reused 8 (delta 0)
Unpacking objects: 100% (8/8), done.
Checking connectivity... done
[New thread 800.0xea0]

Program received signal SIGSEGV, Segmentation fault.
0x004d5200 in git_check_attr (
   path=0xacc6a0 ""..., num=5, check=0x572440) at attr.c:754
754 const char *value = check_all_attr[check[i].attr->attr_n
r].value;
(gdb) list
749 int i;
750
751 collect_all_attrs(path);
752
753 for (i = 0; i < num; i++) {
754 const char *value = check_all_attr[check[i].attr->attr_n
r].value;
755 if (value == ATTR__UNKNOWN)
756 value = ATTR__UNSET;
757 check[i].value = value;
758 }


I get a different crash on Linux if I set PATH_MAX to 260.  The following
hackish patch prevents it.  Does it help in your case as well?  If it does
then I'll send a nicer (but longer) one.

Thanks,
René


diff --git a/unpack-trees.c b/unpack-trees.c
index 1a61e6f..9bd7dcb 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -961,7 +961,7 @@ static int clear_ce_flags(struct cache_entry **cache, int 
nr,
int select_mask, int clear_mask,
struct exclude_list *el)
  {
-   char prefix[PATH_MAX];
+   char prefix[4096];
return clear_ce_flags_1(cache, nr,
prefix, 0,
select_mask, clear_mask,




--
=
  Wataru Noguchi
  wnoguchi.0...@gmail.com
  http://wnoguchi.github.io/
=
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [msysGit] [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

2013-10-01 Thread Wataru Noguchi


Hi,

Thanks for your advice.

I see. I'll try following tool for optimization affection.

Thanks.

(2013/09/29 20:01), Stefan Beller wrote:

On 09/29/2013 04:56 AM, Wataru Noguchi wrote:


- gcc optimization level is O2.(fail)
- gcc O0, O1 works fine.


Maybe you could try to compile with
STACK found at http://css.csail.mit.edu/stack/
That tool is designed to find
Optimization-unstable code.





--
=====
  Wataru Noguchi
  wnoguchi.0...@gmail.com
  http://wnoguchi.github.io/
=
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

2013-10-02 Thread Wataru Noguchi


Hi,

At last, I foundfollowing Makefile optimization suppression works fine in my 
case.

CFLAGS = -g -O2 -fno-inline-small-functions -Wall

Following optimization option cause crash,

-finline-small-functions


// entry.c:237

int checkout_entry(struct cache_entry *ce,
   const struct checkout *state, char *topath)
{
//--
// crash!
static char path[PATH_MAX + 1];
//--
// works fine. but bad practice.
static char path[4096 + 1];
//--
struct stat st;
int len = state->base_dir_len;

if (topath)
return write_entry(ce, topath, state, 1);


Thanks.


(2013/10/01 22:35), Wataru Noguchi wrote:

Hi,

Thanks for your patch.

Unfortunately, in my case still crash...

But PATH_MAX length kinds issues interesting.

I'll try investigate a little more.

- PATH_MAX and O2

Thanks.

(2013/10/01 2:00), René Scharfe wrote:

Am 29.09.2013 04:56, schrieb Wataru Noguchi:

Hi,

Thanks for comments.

My currently working repository is

https://github.com/wnoguchi/git/tree/hotfix/mingw-multibyte-path-checkout-failure

I have revert commits to 1f10da3.
I'll try failure step.

- gcc optimization level is O2.(fail)
- gcc O0, O1 works fine.


$ gdb git-clone
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 "i686-pc-mingw32"...
(gdb) r https://github.com/wnoguchi/mingw-checkout-crash.git
Starting program: C:\msysgit\git/git-clone.exe https://github.com/wnoguchi/mingw
-checkout-crash.git
[New thread 800.0xa10]
Error: dll starting at 0x779f not found.
Error: dll starting at 0x7590 not found.
Error: dll starting at 0x779f not found.
Error: dll starting at 0x778f not found.
[New thread 800.0x92c]
Cloning into 'mingw-checkout-crash'...
Error: dll starting at 0x29f not found.
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 8 (delta 0), reused 8 (delta 0)
Unpacking objects: 100% (8/8), done.
Checking connectivity... done
[New thread 800.0xea0]

Program received signal SIGSEGV, Segmentation fault.
0x004d5200 in git_check_attr (
   path=0xacc6a0 ""..., num=5, check=0x572440) at attr.c:754
754 const char *value = check_all_attr[check[i].attr->attr_n
r].value;
(gdb) list
749 int i;
750
751 collect_all_attrs(path);
752
753 for (i = 0; i < num; i++) {
754 const char *value = check_all_attr[check[i].attr->attr_n
r].value;
755 if (value == ATTR__UNKNOWN)
756 value = ATTR__UNSET;
757 check[i].value = value;
758 }


I get a different crash on Linux if I set PATH_MAX to 260.  The following
hackish patch prevents it.  Does it help in your case as well?  If it does
then I'll send a nicer (but longer) one.

Thanks,
René


diff --git a/unpack-trees.c b/unpack-trees.c
index 1a61e6f..9bd7dcb 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -961,7 +961,7 @@ static int clear_ce_flags(struct cache_entry **cache, int 
nr,
  int select_mask, int clear_mask,
  struct exclude_list *el)
  {
-char prefix[PATH_MAX];
+char prefix[4096];
  return clear_ce_flags_1(cache, nr,
  prefix, 0,
      select_mask, clear_mask,







--

  Wataru Noguchi
  wnoguchi.0...@gmail.com
  http://wnoguchi.github.io/

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

2013-10-05 Thread Wataru Noguchi


Hi,

I put following printf logs.

int checkout_entry(struct cache_entry *ce,
   const struct checkout *state, char *topath)
{
static char path[PATH_MAX + 1];
struct stat st;
int len = state->base_dir_len;

if (topath)
return write_entry(ce, topath, state, 1);

memcpy(path, state->base_dir, len);
fprintf(stderr, "path: %s\n", path);
fprintf(stderr, "len: %d\n", len);
strcpy(path + len, ce->name);
len += ce_namelen(ce);
fprintf(stderr, "path: %s\n", path);
fprintf(stderr, "len: %d\n", len);
fprintf(stderr, "path_max: %d\n", PATH_MAX);


--


crash result

wnoguchi@WIN-72R9044R72V /usr/tmp (master)
$ git clone https://github.com/wnoguchi/mingw-checkout-crash.git a2
Cloning into 'a2'...
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 8 (delta 0), reused 8 (delta 0)
Unpacking objects: 100% (8/8), done.
Checking connectivity... done
path:
len: 0
path: dummy 1-long-long-long-dirname/dummy 2-long-long
-long-dirname/dummy 3-long-long-long-dirname/dummy 4-l
ong-long-long-dirname/dummy 5-long-long-long-dirname/.txt
len: 302
path_max: 259

crash!!

--

build with

CFLAGS = -g -O2 -fno-inline-small-functions -Wall


wnoguchi@WIN-72R9044R72V /usr/tmp (master)
$ git clone https://github.com/wnoguchi/mingw-checkout-crash.git a3
Cloning into 'a3'...
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 8 (delta 0), reused 8 (delta 0)
Unpacking objects: 100% (8/8), done.
Checking connectivity... done
path:
len: 0
path: dummy 1-long-long-long-dirname/dummy 2-long-long
-long-dirname/dummy 3-long-long-long-dirname/dummy 4-l
ong-long-long-dirname/dummy 5-long-long-long-dirname/.txt
len: 302
path_max: 259

Warning: Your console font probably doesn't support Unicode. If you experience s
trange characters in the output, consider switching to a TrueType font such as L
ucida Console!

works fine.



this result means actual path byte length over run path buffer?

static char path[PATH_MAX + 1];

hmmm...

I'm not sure why -fno-inline-small-functions works.


(2013/10/04 2:36), Erik Faye-Lund wrote:

On Thu, Oct 3, 2013 at 7:25 PM, Antoine Pelisse  wrote:

I've not followed the thread so much but, in that
entry.c::checkout_entry,() we do:

memcpy(path, state->base_dir, len);
strcpy(path + len, ce->name);

which can of course result in memory violation if PATH is not long enough.



...aaand you're spot on. The following patch illustrates it:

$ /git/git-clone.exe mingw-checkout-crash.git
Cloning into 'mingw-checkout-crash'...
done.
fatal: argh, this won't work!
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

---

diff --git a/entry.c b/entry.c
index acc892f..505638e 100644
--- a/entry.c
+++ b/entry.c
@@ -244,6 +244,9 @@ int checkout_entry(struct cache_entry *ce,
   if (topath)
   return write_entry(ce, topath, state, 1);

+ if (len > PATH_MAX || len + strlen(ce->name) > PATH_MAX)
+ die("argh, this won't work!");
+
   memcpy(path, state->base_dir, len);
   strcpy(path + len, ce->name);
   len += ce_namelen(ce);



On Thu, Oct 3, 2013 at 12:26 AM, Wataru Noguchi  wrote:

Hi,

At last, I foundfollowing Makefile optimization suppression works fine in my
case.

CFLAGS = -g -O2 -fno-inline-small-functions -Wall

Following optimization option cause crash,

-finline-small-functions

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--

  Wataru Noguchi
  wnoguchi.0...@gmail.com
  http://wnoguchi.github.io/

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.

Re: [msysGit] Re: [PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.

[PATCH] mingw-multibyte: fix memory acces violation and path length limits.

Re: [msysGit] [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

Re: [msysGit] [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

Re: [PATCH] mingw-multibyte: fix memory acces violation and path length limits.

8 matches

Site Navigation

Mail list logo

Footer information