This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-26 18:38:26 UTC ---
(In reply to comment #10)
> Yes, this certainly fixes my segfault.

For me, it only fixes the segfault, also avoids all valgrind and glibc errors
messages at runtime and drastically improves the valgring report in terms of
memory leaks, to 0 definitely and 0 indirectly lost (try not ding 'delete
__reduct', as was effectively happening before the patch, for example, to see
what I mean). The report is still not perfect, indeed, there may be other leaks
somewhere else, I'm going to audit other bits of the parallel infrastructure as
I said. This is the valgrind report I get here on an i7-980X I have at hand:

==7206== LEAK SUMMARY:
==7206==    definitely lost: 0 bytes in 0 blocks
==7206==    indirectly lost: 0 bytes in 0 blocks
==7206==      possibly lost: 3,344 bytes in 11 blocks
==7206==    still reachable: 2,984 bytes in 3 blocks
==7206==         suppressed: 0 bytes in 0 blocks

> Valgrind complains a little - although I am not sure if this is important (I
> am very new to the helgrind tool).  In case it is useful, I attach the
> output I get,

Sure it would be useful. Note, in general, a few memory issues have been fixed
already in 4.5.x and 4.6.x, thus at some point, if you are serious about
parallel mode, updating GCC will be certainly recommended.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]