>>> I changed mingw.org's mingw-runtime to mingw-64 (32-bit). >>> Then an error didn't occur and correct test.pdf was generated. >>> >>> https://github.com/trueroad/gub/tree/binutils-2.24 >>> >>> I may pull request if you request it. >>> >>> Further, even if the runtime is mingw-w64, >>> bad_alloc occurred when optimization was turned on. >> >> For both of bad_alloc prevented and optimization, >> I tried the following setting. >> Only one file (lily/skyline.cc) optimization is disabled >> and all other files optimization is enabled. > > Do you have a backtrace that might give us some more clue about where > lily/skyline.cc has a problem? > > I thought that I had at one time proposed something to be changed (as > part of some issue?) order to deal with possible memory corruption, but > a quick look through the log messages does not turn up either a commit > from me or a commit message ringing a bell.
I turned off optimization to get correct backtrace, but bad_alloc didn't occur. Therefore I could get only incomplete backtrace. It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc. I think the problem is Skyline::internal_merge_skyline and/or first_intersection. Skyline::internal_merge_skyline has a while loop with push_back. I think that the loop termination condition may break by optimization. So, I tried to disable optimization only not one file whole, but one function. In the case of Skyline::internal_merge_skyline, the result was bad_alloc. In the case of first_intersection, the result was that correct PDF was generated. The source tree when succeeding, is as follows. https://github.com/trueroad/gub/commit/5e63dbde436bd3fca154557672394987c8d2e385 Masamichi Hosoda _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
