Follow-up: Running :
valgrind --leak-check=full --show-reachable=yes ./vwc ../../shakespeare.txt results in: ==1871== LEAK SUMMARY: ==1871== definitely lost: 1,159,488 bytes in 72,468 blocks ==1871== indirectly lost: 594,828 bytes in 72,468 blocks ==1871== possibly lost: 3,293,008 bytes in 6,709 blocks ==1871== still reachable: 409,434 bytes in 1,682 blocks ==1871== suppressed: 0 bytes in 0 blocks ==1871== So there is definitely something fishy going on here, either: - the Vala Hashmaps are buggy, or - the refrence counting of Vala is buggy or - something eludes me here. Serge. On Sat, Jun 11, 2011 at 11:30 AM, Serge Hulne <[email protected]> wrote: > I mentioned earlier on this mailing list a problem ("segmentation > fault": usually the sign of a memory allocation gone wrong) which > occurs when merely substituting > > isalnum() > for > issspace () > > in a simplistic scanner, see: > > http://mail.gnome.org/archives/vala-list/2011-June/msg00062.html > > > This simple substitution produces a totally unexpected segmentation > fault when the application (see link above) is run on a text file a > few hundreds of MB large. > > - Is there a way to try to assess what went wrong ? > - Is there a Valgring-like utility for Vala ? > - Does anybody have an idea why this is happening ? > - Can Vala be trusted to develop non-trivial applications (is it ripe, > debugged, tested, robust enough) ? > > > Serge. > _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
