Slashdot Mirror

Yes, that's what old programmers used to do: build and test with efence and valgrid, and recompile
https://linux.die.net/man/3/li...
http://valgrind.org/
Interestingly neither of these lang standing approaches (Hi Bruce) appears to be mentioned in the IEEE paper.
Peer review ain't what she used to be.

That's the right direction. Apple already has a pretty good version of it. (See below.)

Bounds checking C like this now is weak and very, very late:
https://gcc.gnu.org/ml/gcc/199...
https://www.lrde.epita.fr/~aki...
http://blog.qt.io/blog/2013/04...
http://valgrind.org/docs/manua...
https://en.wikipedia.org/wiki/...

But the grand champion memory debugger is the Mac OS X standard malloc libraries. You can simply set environment variables and instantly get better debugging than most methods on all other platforms. I presume this is because Objective C/C++ is such a pain to debug that they just built in features to always be available, even for production apps.

http://www.cocoawithlove.com/2...

Those libraries are clever because when debugging array bounds corruption and used/free, all mallocs get their own mmapped memory block surrounded by unmapped memory. Plus writing patterns into free / allocated memory to detect writing to freed memory, etc. This is great because it triggers a system signal that debuggers can catch deterministically.

I found and used those techniques on my last big project a couple years ago. The Windows desktop app and imaging C++ libraries were full of errors, memory corruption, struct and 32bit/64bit problems, etc. I had to do a lot of debugging and rewriting to port to Mac OS X, then a lot to solve corruption and threading issues. And found out, the hard way, what a mess the "standard" pthreads API / libraries were. Just spurred me on to switch to C++11 to have standard threads. This Mac OS X built-in debugging along with gdb made it a snap to find all of those kinds of errors, even for code meant for Android, Linux, and Windows.

I bought Purify and have been happy with it. Hopefully they remain true to blocking all ads and trackers.

I too was once reasonably happy with Purify, but what does it have to do with ad-blocking escapes me... Maybe, things have changed since I switched to valgrind...

Lucky values in uninitialized variables and such.

CFLAGS+=-Wall -Wextra -Wshadow -Werror -pedantic-errors

And then use tool like http://valgrind.org/

Nearly all of the development tools of Linux are available on OSX via ports, brew or simply compiling oneself. Even fairly advanced stuff like valgrind. There is no shortage of cross platform GUI toolkit like Qt.

In what way is OSX crippled as a dev box ?

Well, obviously the lack of systemd.

Nearly all of the development tools of Linux are available on OSX via ports, brew or simply compiling oneself. Even fairly advanced stuff like valgrind. There is no shortage of cross platform GUI toolkit like Qt.

In what way is OSX crippled as a dev box ?

There are also other statical analysis tools like splint. The catch is that it produces a large volume of data which is tedious to sift through, but once done you will have found the majority of the bugs in your code.

However the root cause is that the language itself permits illegal and bad constructs. It's of course a performance trade-off, but by coding part of the code in a high level language and leave the performance critical parts to a low level may lower the exposure and force focus on the problems to a certain limited area.

A secondary cause is that if you write code - write it as clean as possible and broken down into pieces. If coding C there's always the option of declaring a function as "static inline" to tell the compiler that what you do is going to get right into the execution flow because you know that it will improve performance.

Dynamic analysis is also good - like Valgrind, but they have shortcomings. Just be aware that fuzzing can confuse dynamic analysis tools as well producing inconsistent results, which means that for the initial tests you need to be able to turn off fuzzing to get rid of the consistent problems.

Sounds like Valgrind

Today is your lucky day, it's available for free at http://clang.llvm.org/ and http://valgrind.org/.
Make sure you read the instructions before you start, though. You can find them at http://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628.
Enjoy!

Memory management is a non-issue with RAII, smart pointers, Boehm garbage collector, and finally Valgrind.

This smells like an argument you've wheeled out before.

Firstly, Valgrind is not something you use on a production deployment of a webserver; it's performance overhead is really substantial. (Good tool, but makes all memory accesses much slower.) Your suggestion makes me suspect that you don't write high-performance websites for a living. (There are nasty gotchas if you don't go fast enough.)

Secondly, RAII only solves some kinds of memory problem (where other languages would use a finally clause) and it is not syntactically clear when it's being used (not unless you're only using it close to the declaration of the class concerned, but that's got other issues). It's OK when you can bind the object lifetime to a scope, but that's definitely not always true. Smart pointers are better general tools, but rather noisy and inefficient (their refcount management is necessarily conservative and so ends up adding some overhead, which is not necessarily good for cache coherency). They also don't tackle circular structures (if that matters to you).

Lastly, full GC has substantial costs of its own (it increases memory consumption of the application, and churns that memory around more rapidly) and a generational collector will outperform pure Boehm on many workloads, though the fact that the Boehm collector supports thread-local allocation is a big plus; a lot of workloads can be split nicely into parts that are constrained to a single thread. The Boehm GC is good, but is it the right kind of good for a website implementation? I'd need to see some evidence - not just opinion - before commenting in depth.

Your C++ info is so 90s. FYI:
A descent C++ web framework: Wt
Memory management is a non-issue with RAII, smart pointers, Boehm garbage collector, and finally Valgrind.
Qt or LiteSQL don't need to be "standard" to do their job.

Oh, interesting. VALGRIND looks like dynamic analysis. The results in the article are from static analysis. Each is really useful, but they tend to find different sorts of problems.

If you'd like to download the five problematic submissions and run VALGRIND against them, please email me the results. I'd be interested to see what is actually detected.

This is not a good thing: by definition x86 code is not portable across platforms.

Using dynamic translation techniques (a la valgrind) it should be possible to run x86 code on other platforms with excellent performance.

With dynamic translation you can either design a completely new bytecode that is equally alien to all platforms or choose an existing platform as a "bytecode". I think x86 is actually a pretty good choice. The x86 architecture has segment registers that help isolate untrusted code. These segment registers are accessible from user mode on all major x86 operating systems (unlike the paging hardware that is available only to the OS kernel). Also, all other major architectures sets have more general purpose registers than x86. This makes it possible to devote a dedicated register to each of the emulated x86 register while still having a few free registers to manage the state of the dynamic translation engine.

Ok, so x86 assembly is a weird and not very orthogonal instruction set. So what? This merely makes the lookup and translation tables in the dynamic execution engine a bit bigger when compared to some "ideal" bytecode. I don't think this makes a good argument against an otherwise very elegant solution.

That's not how fair use works - using an entire piece would never fall under fair use, under any definition or description I've read. Also, references to the group cannot be stripped out if they're part of the licensing conditions, even under the BSD license.

The submitter should trust that paper authors will cite properly if they've used the software to obtain scientifically relevant results. Any paper that doesn't cite the software used is pretty useless anyway, the reader won't know where they got the relevant result from. Here's an example of existing practice in this area by a software author. I would say your supervisor is being impractical if they insist on doing more than that, a cite clause would probably put off a lot of users and packagers.

There's also valgrind, for Linux users, and mudflap, for gcc users. I haven't tried mudflap yet, but valgrind is a very good runtime memory checker, and mudflap claims to do similar things.

So who writes these 'automated tools' and who checks those?

To take it a step further, try running the code in Callgrind. Callgrind is part of the Valgrind suite. It basically runs your app on a soft CPU. It's intended for use as a profiling tool, but it gives you a complete map of what is calling what, and how many times. The output is most valuable when you create snapshots around specific use cases in the code -- you can do that with callgrind's external control tool. KCachegrind is an excellent tool for viewing callgrind output.

Valgrind is fantastic for something like this.

I work on a C/C++ code base that is a lot bigger than 500k lines. I've worked with results produced by Klocwork and also with the output from Reasoning. Both of these services/packages will cost you money but both provide good insight into your code. The commercial packages generally produce more focused results with less false-positives, so while they cost you money up front, your developers will spend less time weeding out the noise.

If paying money out for a commercial package isn't your thing, don't overlook the old standby lint or splint, an updated successor.

Also well worth investigating to see how your code is actually running is Valgrind and it's associated tools. The Valgrind toolkit will give you a good idea where memory is being leaked, where variables and pointers are going off the rails. Valgrind hooks into a running program, so it's important to make sure that you test all the corners of the codebase if you go this route.

Cheers,
Toby Haynes

Combine that with thorough test cases, and you can be virtually assured that you have no memory errors in your C/C++ code.

They may not be complete solutions, but a few practices avoid a lot of problems:

• NEVER use gets(3)
• Use the versions of the string functions that count, e.g. snprintf(3) instead of sprintf(3)
• Run your code through valgrind

Yes

The Print statement has been and still is the ultimate in debugging. Debuggers aren't really that useful, hardly more than runtime syntax error checkers. Sure, it's nice to have a tool that will tell you what line the program was on when it segfaulted, and I use them for that. But most of those sorts of bugs are caused by illegal memory accesses and I find Valgrind pretty good for finding those.

When I'm trying to find where the code first started derailing, and I need to look at large, complex objects, the debugger isn't so good. Good for viewing little pieces of the trainwreck, not so good for big pictures or finding subtle bugs. Takes about as much time to stick in print statements to track progress as it does to set breakpoints. For something like displaying huge, sparse arrays where the interesting values are scattered about in some pattern of elements too complicated to program the debugger to filter, a little routine is a lot better. For a totally arbitrary example, how could you tell the debugger you want to see every 4th and 5th element of an array? You can't. But that's a very easy print statement nested in a loop: for (i=0; iSIZE_OF_ARRAY; i++) { if (i%4==0 || i%5==0) printf("%d ", array[i]); } Same goes for displaying most data structures. Linked lists, trees, stacks, and so on are all easier to examine and track with tailored print statements. Also, when I do use the debugger, I sometimes add code purely to give me an easy breakpoint to give to the debugger. Like, want to look at the 10000th time the else branch of an if statement in a big loop is taken? Stick in a few lines "if (i==10000) { printf("debug"); } and set a breakpoint on that printf statement, it'll be way faster than instructing the debugger to ignore the next 9999 crossings of a nearby breakpoint. And print statements can be sent to a file, where one can apply all kinds of useful tools such as grep, sort, cmp and diff, graphing software, and spreadsheets.

I have been think if it isn't posible
to make a valgrind tool which scans for secuity issus ?

http://valgrind.org/info/tools.html

http://valgrind.org/ used to include a tool called hellgrind for finding just such problems. unfortunately, hellgrind has gone away for a bit (it broke when the VM was re-done to support non-x86 platforms), but julian & co are working hard to get it working again Real Soon Now (tm). if you're using x86, you can use an old release of valgrind (2.2.0 i think) and you should be fine.

personally, i can't say enough good things about valgrind. there are a couple non-obvious issues (support for sse/sse2/sse3 is still in the works, so if you get an inexplicable SIGILL, this is probably the problem), but it's saved me hundreds of hours over the past year (and i'm sure it'll save me even more in the future).

that all said, my (admittedly limited) experience with threading is that it's best to design the deadlocks away before you even touch the editor. i wonder if there are any design tools which support deadlock / contention checking at the model or design level?

Unless there was a coincidence in naming, I think valgrind refers to the (really quite awesome) open source debugging tool for Linux. Valgrind's primary purpose is to let you run your x86 Linux executables in an emulation environment where any memory-access errors can be detected and reported; it makes debugging much easier than in the "real world", where an error might only cause a crash or other visible symptom 1% of the time. I suspect this researcher merely "appropriated" the valgrind source code as a test harness for her ideas. It's certainly much cheaper to do it that way than do build your own x86 fab...

As far as security holes in the VM itself: yes, that is a possibility, but keep in mind that the complexity of a VM is finite, which means that sooner or later (hopefully sooner) it can be fully debugged and thus be secure. The complexity of the programs it runs, on the other hand, is infinite, because new programs are being created all the time. So the advantage of a VM is that you can get the small amount of "golden" secure VM code to protect you against from the buggy code that runs inside it.

Consider this: an Intel chip is just a VM implemented in hardware. Hardware security flaws do exist, of course, but they are also quite rare compared to software flaws, mainly because there are so few hardware implementations being built.

Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the name of the main entrance to Valhalla
(the Hall of the Chosen Slain in Asgard). Over this entrance there resides a wolf and over it there is the head
of a boar and on it perches a huge eagle, whose eyes can see to the far regions of the nine worlds. Only those
judged worthy by the guardians are allowed to pass through Valgrind. All others are refused entrance.

Borland C++ was very robust and in your experience bad programmers habitually blame the compiler? Maybe so. I have been convinced at least once that I found a bug in gcc only to find out it was my code. Nevertheless Borland C++ up to 4.5 was not a good compiler. Not suspecting the compiler is maddening when the problem IS the compiler. You will spend days chasing your tail and not finding anything wrong with your code. So much for productivity. Did your dozen or so professional applications ever use more than 64K in a single array? If they didn't you would never see these problems, and you could easily be convinced that Borland C++ 3.1 was a great compiler because aside from that, it was pretty good. Maybe despite your dozens of professional efforts, you never exercised the compiler where it was weak. Come on, forgetting to initialize variables and running past the bounds of arrays are fairly trivial bugs to check for, and I did check for that stuff. We even have tools such as valgrind that automate such checks. Compiling with Borland C++, I eventually noticed quite a few working programs, mine or others, would fail just as soon as I pushed the memory usage of any one array over 64k. Didn't matter which memory model I picked. Didn't matter if I used huge pointers or not. Never got any warnings or error messages from the compiler about these arrays, not even using the equivalent to gcc's -Wall flag, and if the problem was that I was violating a 64K segmentation limit, shouldn't the compiler have at least warned me? Shrink those arrays back under 64K and the programs worked fine again. And what do you have to say about a>>=1; bombing to the assembler?

I needed big arrays. Gcc never had a prob with that. Borland C++ just couldn't do big arrays.

• Instanciate coding guidelines - code must be easy to read. Minor variation in coding flavour shouldnt be here, merely the large scope.
• Avoid if...else if...else if...else if... - constructs. They are especially hard to follow, and can often be replaced by switch/case-statements.
• Require large modularization of code. - No function/method should be more than about 40 to 100 lines, the fewer the better, but don't be too rigid here - some functions/methods are better of being straight-on than modularized.
• Code for each case-statement in a switch should be a call to a method/function that encapsulates actions and declarations. (not always possible, but if the code exceeds 4-5 lines a function/method should be considered).
• Don't nest a switch/case inside a switch/case - do the nested switch in a called function/method.
• All code must be reviewed.
• Test cases for each module, which requires writing a bunch f test code that can be used for regression testing changes.
• Don't allow compiler warnings. (-Wall shall be used if using gcc, possibly also other options)
• Declare your own types to manage code neatly.
• It's better to write code cleanly than to write it in the most compact manner unless it's a real performance issue.
• Document each module to describe why it is and what it is doing.
• Place each class in it's own file - like Java.
• Be sure to keep as much as possibly 'private' and only relax to 'protected' or 'public' when needed.
• Variables in classes should have get/set methods and shouldn't be accessed directly unless there is a performance issue. Set methods can then be able to validate indata and reject or throw an exception on bad data.
• If something can't be resloved without a compiler warning - think again and if still not possible - document that reason before the code review.
• Run the code under analysis of leak and memory access testing software like Valgrind and/or PurifyPlus. Preferrably both during unit testing and system testing.
• Be paranoid. Check for 'null' results and do detailed try/catch blocks instead of a try/catch over a large block. Using detailed checks allows you to take appropriate action on detail errors.
• Instaciate an extensive beta-testing program.
• Inline-declare function/methods that are broken out if they should be inline with the code for performance reasons.

For code written in C you can use Splint

• Write unit tests. Make a policy to include one test for each new function/method introduced to the base code.
• Run Valgrind tests on the unit tests periodically.
• Use Smart Pointers, maybe from Boost. Do not allocate new naked (regular) pointers in the heap.
• Re-use code. Re-factor as much as possible. Do not allow for large, obscure, zillion-line functions.
• Use well known, well debugged libraries such as the stlport (for STL) as much as possible. Maybe Qt.
• Be const-correct. Pass const-references as much as possible.
• Make simplicity and readibility of the code a strong requirement. Good code should look damn clean.
• Don't ask in ./, we are a bunch of asses after all ;-)

When I was a 2nd year student we weren't this sort of stuff, makes me wish I went to Stanford.

You really don't need to go to some high-ranked CS university to do cool projects. I hear a lot of people on Slashdot griping about how they couldn't go to MIT/CMU/Stanford/CalTech/whatever. Okay, maybe you get some good lectures and have some bright people handy to work with, but that's really a drop in the bucket compared to what you choose to do yourself. If you read about the things you're interested in, work on some projects, you *will* know far more than the people that went to Ivy League U and didn't do anything themselves -- just went to class and read enough content to get their grades. You have powerful, inexpensive computers easily available. You have free high-quality development software (if you don't have Valgrind and gcc on your computer, you're really missing out). You have an Internet's worth of excellent resources available, along with research papers on every neat thing you can think of free for the downloading. You don't need a professor or a boss to say "okay, write me a Foobar" to write a Foobar -- as a matter of fact, if you're writing a Foobar for yourself, it's probably going to be a better Foobar than if you're writing it because someone else is making you do so. Same goes for reading an algorithms book or a research paper.

Plus, if you don't want to tackle a whole game, choose something that you *do* like doing -- AI, graphics, sound engine, networking -- and pick a random existing open-source project and put your ideas into it. Then you have a nice end result that you can show off to people ("That game you're playing? Yeah, I'm one of the authors"), you have encouragement to keep going (because it isn't just a lone you -- you get feedback when you do something cool), and if you want a good practical excuse, you have a resume item that shows that not only do you have the ability to work with people to produce neat things -- but you've done so simply because you like making neat things. Also, it's *fun* to add a new feature to a game and then play using said feature with the rest of the dev team.

Remember that Woz never got his college degree (well, until a few years ago, when he decided to go back and get it). He built cool things because he liked making cool things, not because someone in a suit told him to make something cool. The same's true of an awful lot of techie folks out there -- school is a convenient tool, but it's much less important than going out and actively learning about things, and the fact that your uni has "State" in its name doesn't have a heck of a lot to do with what you learn. Sure, your professor will assign a bunch of books to read, but you can write that final paper without learning all that much, and certainly with big gaps in what you know. On the other hand, you can read all you want about just about anything I can think of on that Internet-connected computer in front of you.

Universities enforce a lower bound on your knowledge at graduation. They have nothing to do with setting a ceiling.

has (ir)rational purify gotten any easier to use? i showed my boss valgrind (http://valgrind.org/) and he couldn't believe how (relatively) painless it was to use. well, painless in terms of actually using, not painless in terms of how bloody slow things run (but that's kinda to be expected since they're emulating the machine...)

i've reached a point where i run whatever project i'm working on through valgrind at least once every two weeks and usually more often than that (before every non-trivial commit). if there were something splint-like for c++ (but at the same price point), i'd write a clever wrapper script to run that first and then whatever the compiler du jour is.

2) real garbage collection. It is not possible to have effective collection without support from the compiler. The Boehm's collector is not a precise collector, because it can not use type information; it is only the compiler that knows such things.

If you are having problems finding where you need to deallocate memory, or are using memory in an invalid manner, I suggest looking into Valgrind. You can run your program through valgrind and it will give you real-time analysis of your program and any invalid memory read/writes you are performing.

A virtualization layer cannot do everything. However it can do a lot. Valgrind catches a lot of bugs in code because it is a virtualization layer.

Most importantly the layer can easily know where the stack return address is and prevent you from changing that. It also knows where the stack is, and what memory you have allocated, so it can prevent you from writing to anything else. It can also prevent you from running code in that area unless the memory was written with a function called dlopen (or other such), and it also can know in advance where dlopen is implemented so you can't write your own. (and why would you write your own when the system provides one, unless you wanted your code exploitable)

It is a matter of tradeoffs. Run your code in valgrind and you get 1/20th original speed. Run in a power powerful system and you go slower yet.

Many bounds-checking and memory-leak tools have been obsoleted by Valgrind. In my opinion, it's truly great piece of software and when working on PPC, I often find it worth the effort to make sure my code compiles on x86 too just to get it running on Valgrind.