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 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. Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html