> Adding the error nr in the Valgrind output would help, but I am not > sure the improvement in gdbserver usage is worth always printing an > error nr (and adding an option --with-error-nr=yes/no looks an overkill > to me). Unless an error nr would be generally useful ? See e.g. how > the 'loss record nr' is now used in 3.8.0SVN to give more details (e.g. > the list of blocks leaked) about a leak. > > In any case, it looks more logical (and might be sufficient) to have > --vgdb-error compared to the nr of shown errors rather than to the > nr of found (and possibly suppressed/possibly not shown errors). > > Can you try the patch below and see if that is working and > sufficient for you ?
Thanks for the patch. I have manually applied it to 3.7.0 (not svn) and it is a big improvement. The number seems to be offset by 1 from what I would expect though, eg. --vgdb-error=5 stops after detecting 6 errors. One reason for printing the error number in the output would be to avoid having to manually count them if there are many. Personally I think it would be nicer to always have the errors numbered to help navigating large amounts of output . thanks, Rob ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
