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 bug.

Most likely the problem is with our Windows-specific UTF-8 handling, I
would not be surprised if it is my "favorite" bug: an off-by-one.

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.

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

Reply via email to