|
Information Source Code Documentation Contact How to Help Gallery | ||||||
Question #5,6,9,10: Good and bad thingsQuestion #5: What are the best things about Valgrind and its skins? Question #6: What are the worst things about Valgrind and its skins? Question #9: Are you happy with the way Valgrind is developed, eg. with respect to mailing lists, bug reporting, release frequency, etc? Question #10: Any other comments, suggestions? These questions were again very badly expressed, and people's
comments were scattered among them so much that I instead
reorganised the responses into the following points: For the "bad" things, a lot of them are really "potential improvements". Although the previous question on other tools kind of overlapped these points a bit, I kept those responses separate. There is a lot of meat in here; I've used broad categories, but it can't be summarised easily. I didn't merge lots of different answers that I probably could, in order to preserve information; I recommend reading it carefully. Good things about the softwareno answer/don't know 7 (ie. answer to the "best things?" question) ------------------------ Distribution ------------------------------- "free" (not clear if speech or beer) 8 runs on Linux 5 open source 4 runs on x86 2 free (as in speech) 2 free (as in beer) 1 --------------------------- Usage ----------------------------------- ease of use/no recompilation 40 "it works"/"it just works" 14 more convenient to run than GDB 1 programs sometimes seg fault normally, but run ok under Valgrind 1 works with any language 1 quick to setup on a new box 1 "it does what it does" 1 -------------------------- Performance-------------------------------- fast 5 fast results 1 small memory footprint 1 faster than Purify (solaris) 1 not bloatware 1 ------------------------------ Docs ----------------------------------- good 1 --------------------------- Robustness -------------------------------- lots of asserts indicates solid code 2 current release is very stable 1 very good testing 1 -------------------------- Skins, Usage ------------------------------- extensible 4 -------------------------- Bug-Finding -------------------------------- accurate/reliable/few false positives 7 finds memory leaks 4 eliminates bugs before they are a problem 3 thorough 3 find difficult bugs 3 finds bugs 3 find real bugs 2 finds bugs quickly 2 finds most bugs 2 finds bugs I wouldn't otherwise know about 2 finds uninitialised errors 2 find bugs more easily than with traditional tools 1 finds memory overruns 1 gives confidence in program correctness 1 really good memory checking 1 clearly points out bugs 1 catches errors that don't crash the program 1 good for detecting non-determinism in my programs 1 full code coverage 1 tests thing no other free software can test 1 bit-level accuracy is good 1 ------------------------ Error Messages ------------------------------- good error messages 3 says why seg faults happened, not just where, like GDB 2 suppression system good 2 stack traces are good 1 gives lots of information 1 good visual display 1 sometimes gives stack traces on seg faults when GDB can't 1 verbose 1 ------------------------- Good Features ------------------------------- attaching GDB 6 command-line interface 2 suppression generation 1 finding bugs normal debuggers like GDB can't 1 ----------------------- Other Good Things ----------------------------- it's simple 2 completeness 1 helps ensure better coding practices 1 lets me do things I thought not possible in C 1 technically sound, good base for further development 1 has good bones 1 KCachegrind is almost exactly what I want in a profiler 1 KCachegrind provides a wealth of optimising info 1 KCachegrind has a nifty interface 1 easy to extend (spec. ioctls) 1 ------------------------- General Praise ------------------------------ saves me lots of time debugging 2 very powerful tool 2 effective 1 best Linux debugging tool 1 flexible 1 incredibly useful 1 valgrind hard to live without 1 in my "top 5 open source projects" 1 exceptional quality 1 stunning piece of kit 1 ultimate solution for memory problems 1 good for profiling 1 superb tool 1 valgrind is a lifesaver 1 one of the more useful open source tools 1 great tool 1 most useful free dev software after Linux and gcc 1 we love Valgrind 1 makes C programming feel as safe as Java, while maintaining the light-weight, efficient feel of C rather than Java 1 in the pantheon of great open-source projects 1 you guys are awesome 1 valgrind/calltree best thing since slice bread 1 KCachegrind is great 1 Valgrind has been an immensely useful tool for tracking down off-by-one problems and misuse of dynamically allocated memory 1 One of the biggest complaints that people have about moving to Linux from either MacOS or Windows is the lack of top-quality development tools. IMO, Valgrind goes a long way to bridge that gap 1 The most widely praised features are being good at finding bugs (42 mentions), and the lack of recompilation (40). Being free software for Linux also gains good points (21 mentions). Some people like the error messages (12 mentions). And lots of general praise. All good, but the "bad things" next are probably more useful to us. Bad things about the software/things to improvenothing/no complaints 11 no answer 7 ---------------------------- Performance ------------------------------ slow 23 memory usage big 3 slow, can change conditions (eg. error goes away) 2 slow, esp FP 1 slow (cachegrind/calltree) 1 calltree is very slow 1 if faster, could use in release mode 1 ------------------------------- Usage --------------------------------- could be easier to use 1 -------------------------------- Docs --------------------------------- docs bad 4 docs too sparse 3 no man page 2 docs not always up-to-date 2 docs should give sample code with example errors 1 confusing docs 1 should explain what bugs are found, what aren't 1 writing own skin is hard, better docs would help 1 lacking detailed error msg explanations 1 more info about filtering leaks from libraries 1 calltree/KCachegrind docs are bad 1 ----------------------------- Robustness ------------------------------ trouble with threads, stack switches, signals 6 wouldn't work with JNI C code under JRE 2 threads not robust enough 1 flaky on semaphores 1 flaky with hardware-fiddling code (esp. OpenGL libs) 1 own libpthread causes problems 1 NVidia/RH9 problems 1 need to increase the thread compile-time constants 1 libjvm.so doesn't work -- out of memory 1 problems with new systems sometimes 1 works badly with gdb/ddd 1 don't work with ATI drivers 1 want better support for highly threaded programs 1 occasional assertion failures 1 problems with libraries on Debian Sarge 1 unpredictable crashes and side-effects 1 KCachegrind has some bugs 1 -------------------------- Missing Features --------------------------- GUI/official GUI 8 3dNow and SSE support lacking 4 static binaries not supported 3 other archs/OSs would be great 2 interactive leak checking 2 want boundary checks on stack vars 2 x-arch translation would be good 1 leak check should do full GC 1 want to use it on my V880 (8cpus/16GB) 1 want better support for icc 1 emacs mode for errors 1 FV would be nice 1 API to use from other debuggers would be nice 1 cache temperature skin would be great 1 doesn't actually correct the code for me 1 scalar syscall arg checking 1 no "eager" mode -- report validity errors immediately 1 no static overrun checking 1 would be good to have a replacement for Quantify 1 no code navigation 1 no parameter listing 1 some syscalls not known (epoll_*) 1 support for pool allocators not too good 1 interactive suppression managing 1 batch translation mode 1 want -l option to list available skins 1 cachegrind needs more easily navigable output 1 want to know where uninit. values are created 1 remote profiling 1 GDB: - want to attach GDB in a 2nd run, exactly where a mem leak occurred in a 1st run 1 - want to run V'd programs within GDB, rather than attaching 1 - valgrind should contain/be part of GDB 1 - want to attach DDD as well as GDB 1 - more control over which errors to attach it on 1 ------------------------- Annoying Features --------------------------- suppressions difficult 5 suppression depth limit of 4 1 --logfile appending .pidXXX is a pain 1 special compilation for syscalls (eg. 253) is annoying, same for ioctls 1 behaviour doesn't always exactly match native 1 thread scheduling can be different to native 1 have to deliberately insert if statements to get early validity checks 1 with icc, lose origins of mem leaks 1 with VALGRIND_OPTS, skin-specific args clash 1 by default stops recording errors at a ridiculously small number 1 can't be used with libcwd, or other libraries that replace malloc(), want to have control over this 1 problems with MPI command line args 1 can mask crashes that occur natively 1 --------------------------- Error Messages ---------------------------- output sometimes hard to read, esp for new users 4 --num-callers=4 is too small 2 when reading freed mem, want alloc context of block too 2 helgrind gives lots of false positives 2 helgrind gives lots of false positives on custom read/write lock 1 attached GDB frames sometimes broken 1 stack traces sometimes weird 1 stack traces sometimes confusing 1 bugs in system libraries not interesting 1 error messages about "lost zero bytes" confusing 1 error messages can be verbose, confusing 1 only identifies errors to lines, not to symbols 1 mem leaks msgs could be more precise 1 sometimes too verbose, hard to sift through 1 wish faults were associated to variables 1 threading/syscall msgs could be better 1 lack of type information in error messages 1 some errors could give more information 1 ---------------------------- Skins, Usage ----------------------------- want better external skin integration 7 want to run multiple skins at once 1 massif not integrated 1 finding massif's graph drawer was not easy 1 replace cachegrind with calltree 1 want calltree in the main distro 1 cachegrind has marginal value because it's inaccurate 1 ------------------------------- Other --------------------------------- platform dependence 2 not on solaris 2 not on windows 1 doesn't find all the same errors as Purify (solaris) 1 V code != real code (but never notice the difference) 1 code is complex 1 reinvents the wheel (viz. bochs, QEMU) 1 KCachegrind takes some understanding 1 10 had no complaints, 6 didn't answer, which presumably means no complaints. Biggest complaint is slowness, 32 mentions. Next is a range of robustness complaints, 23 mentioned, varying but usually involving the tricky (eg. threads, signals); it's hard to take any particular action about this, since it's never a single cause. The docs take a kicking, 18 complaints. For desired features mentioned more than once, a GUI tops the list with 8, 3 want the ability to run static binaries, 2 want interactive leak checking, 2 want stack var checking (although I think many more would say want it if they realised it). Some good ideas among the rest. For annoying things, there were 20 complaints about error messages, about half because they are confusing, about half because they are incorrect or similar. 6 complaints about external skins being hard to use, and 5 complaints about suppressions being difficult. Good things about non-software stuffgenerally happy 72 (ie. answered "yes" to the "are you happy with the way Valgrind is developed" question. Some also had extra comments/quibbles.) ---------------------------- Development ------------------------------ good support 7 active development/maintenance 5 bugs handled quickly 2 patches accepted quickly 1 responsive team 1 active community 1 ------------------------------ Releases ------------------------------- release frequency good 3 --------------------------- Mailing List ------------------------------ mailing list is interesting 3 mailing list is good 3 mailing list support is good 2 -------------------------- Skins, Concepts ---------------------------- they have cool names 1 Overall, 71 people were generally happy, which is pretty good. 17 positive comments about development support, etc. 7 positive mentions of the mailing list. Fairly good results. Bad things about non-software stuff---------------------------- Development ------------------------------ no feedback for a patch submitted 2 ad hoc addition of instructions 1 patch hasn't been incorporated 1 want more help with NVidia cards and RH9 1 should be a release within 1 month of any bug fix 1 feedback for patch took a long time 1 ----------------------------- Releases -------------------------------- yyyymmdd release numbers suck 4 want more frequent releases 2 releases (stable/devel/beta) have been done confusingly 1 want more frequent devel snapshots 1 want better release notes 1 release policy is bad 1 ------------------------------ Website -------------------------------- website should link to external skins 6 website should link to related tools, eg. GUI front-ends 3 website is crappy 2 bad/confusing website 2 website needs updating 1 website is badly structured 1 website should link to CVS 1 need a easier-to-remember URL 1 should have a TODO list for idle hackers 1 -------------------------- Skins, Concepts ---------------------------- (didn't understand question about skins) 4 didn't know about some/most skins 3 "skin" is confusing 2 hate the term "skin" 1 understanding, invoking skins can be confusing 1 existence of skins -- too complicated 1 don't know what skins are 1 don't know what "skin" means 1 concept is intimidating 1 ----------------------------- Publicity ------------------------------- should have an announcement list 2 need to improve awareness/publicity 1 more publicity about releases 1 need to publicise more, webpage is hidden 1 most skins not publicised 1 -------------------------------- CVS ---------------------------------- SF CVS server sucks 1 complaint: code in CVS is broken, sometimes 1 daily snapshots would be nice, to avoid CVS 1 -------------------------------- Bugs --------------------------------- need a bug tracker 3 I'll start reporting bugs when you get a bug tracker 1 18 complaints about the webpage, mostly that it's generally crappy and doesn't link to external skins and GUIs. Skins aren't understood well, need to be explained better (15 mentions). Some complaints (10) about way releases are handled. Few complaints about development, but some patches have been dealt with badly. 6 comments about us marketing Valgrind badly. Neutral things about non-software stuffno opinion 3 no answer 2 Money-related stuff------------------------------- Money --------------------------------- would consider paying for support 2 ask for small donations to fund valgrind.org 1 create a company selling valgrind support 1 good commercial prospects, eg. windows/cut-down open source version 1 maybe get companies to fund features, like ReiserFS 1 would pay for a license to ensure support continues if it were easy 1 would happily give a donation 1 accept donations -- it's equivalent to $500+ packages... 1
|
|||||||
Copyright © 2000-2023 Valgrind™ Developers |
|||||||