[stensal]

I'm the founder and built the SDK.

Agreed, ASAN and Valgrind cover the most memory errors and are readily available for almost all platforms.

The SDK is designed for a different purpose -- to catch all runtime memory issues with a very high probability. The generated executables can be deployed and used by the end users who don't want to upgrade just for the fixes of memory errors. There are many cases the memory errors are never exploited. By using the pre-built QMS executables, you know when you are exploited, and the exploit will be stopped by the runtime checking.

Edit: Even though I have been reading HN for a quite long time. This is my first post, I just registered recently. I could not figure out how to post Show HN and had to ask a friend to post it for me.

Added more details.

[cryptonector]

I couldn't figure out much from the site as to how this works. Can you go into some detail?

[stensal]

I guess you ask how this dynamic type system works. It basically gives each valid pointer a type, which includes the size information and liveness information of memory pointed by the pointer. When a pointer is dereferenced, the runtime checking will verify whether the dereference is valid. Null (and uninitialized) pointer does not have a type.

It uses a completely different mechanism from the one used by ASAN and Valgrind.

Edit: delete a wrong answer.

[jerrysievert]

Interestingly, SillyMUD and its descendant Phoenix at one point had similar memory checks that occurred at runtime, as well as shared memory with reference counting and a paging virtual memory system.

Unfortunately, even with that and it having been run with purify (a commercial predecessor to valgrind), i was still able to find some severe memory issues that didn’t manifest by compiling with address and memory sanitization about 25 years later.

[stensal]

I didn't know SillyMUD. But I did read the paper about an interpretation based memory checking tool many years ago. Unfortunately, I forgot the name. I believe the interpretation based memory checking tool assigns each pointer a type. So the idea is not new.

ASAN is great because of its compatibility with existing libraries, as you have pointed out, is available in both gcc/clang. Valgrind is in the same league. Both are fantastic tools even though they might miss some errors.

[cryptonector]

OK, Thanks. Now, how does the run-time determine the type and size of an object for which the application has a pointer? The type, presumably, from static typing, but then you have to be careful with type punning. The size, presumably, from the allocation. This doesn't sound that different from ASAN and valgrind. What is different?

[stensal]

Yes, you have stated it correctly. The size and liveness information are from allocations (either stack or heap). ASAN and Valgrind do not associate these information with pointers, but add redzones (extra paddings with special bit patterns) before and after each legit memory block. It only triggers error reporting if a pointer happens to point to one of the redzones. However, redzones always have limited sizes. They cannot cover the ranges of out-of-bound pointers.

It's dynamic typing.

[cryptonector]

Are pointers in this environment bigger than usual? Or do they point at a descriptor that then points at (or contains) the real object?

How does type punning work? Does you compiler scribble the types a pointer has been cast to in the object descriptor?

[stensal]

No, the pointer always has the native pointer size. I think the type in my use of "dynamic type system" confused you. The type has a very narrow meaning, it has only two values. It is either POINTER or NON_POINTER. A POINTER type is like a tuple of size and liveness. It does not track the static types like integer, float, or struct, etc. Hope this clarify it. Perhaps, I should call it 'dynamic pointer tracking system'. Does it sound more clear?