Re: [lmi] Goodbye to some old tools

[Vadim Zeitlin]

On Thu, 28 Jan 2016 03:07:39 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-20 17:28, Vadim Zeitlin wrote:
GC> [...]
GC> 
GC> > I didn't spend much time on this because IMO mpatrol shouldn't be used at
GC> > all nowadays, it's quite obsolete by now and it's probably better to use a
GC> > dynamic instrumentation tool such as DrMemory (http://drmemory.org/)
GC> > instead.
GC> 
GC> I tried looking at it, but got a "unicorn". You use github, so I guess you
GC> know what that is.

 Actually I've only seen the elusive unicorn once before, in 6+ years of
using GitHub, so I completely forgot what it was and only realized that
it's the static image displayed by GitHub when it doesn't work after
rereading the sentence above thrice. And I do know that GitHub was
offline/inaccessible for several hours yesterday, although I still don't
know why (last time it happened it was strongly suspected to be a DDoS
backed by the government of a very populous Asian country unhappy with the
tools for circumvention of its national firewall being hosted there, so I
wonder who could have taken GitHub offline this time). So I guess this
explains why you saw the unicorn. But  this is definitely exceptional, you
were just very lucky to see it so soon after getting acquainted with GitHub.


GC> Searching elsewhere:
GC> 
GC> https://www.chromium.org/developers/how-tos/using-drmemory
GC> | DrMemory supports Linux, but the support is not as robust.
GC> 
GC> 
https://blog.mozilla.org/jseward/2015/10/05/dr-memory-a-memory-checking-tool-for-windows/
GC> | a promising tool, but just a bit too hard to use
GC> 
GC> I would suppose that the GNU/Linux tools are more mature:

 Yes, I meant DrMemory for debugging under MSW only, sorry for not being
clear. There are better tools for Unix systems. But for MSW I am not aware
of any open source (or even just free) tools better than DrMemory.

GC> > Better yet, build lmi under Linux with address (and/or undefined
GC> > behaviour_ sanitizer, which is much faster than DrMemory or Valgrind but
GC> > still finds most problems. So for now I've just skipped this step.
GC> 
GC> Sounds like a good idea. I guess we should also try building with clang.

 I'm ahead of you here and already tried building with it and it mostly
went fine, I just had to change configure to avoid passing gcc-specific
options to clang and also fix a couple of harmless (but justified) warnings
of its own. I'll submit these patches soon.

 I even used clang static analyzer but it didn't find anything interesting,
which is pretty impressive (unless I used it wrong as it's the first time I
do it outside its "native" OS X environment). The only remaining thing I'd
like to do would be to run the tests and the program itself under the
address sanitizer, but there are a few other things before this in my TODO
list.

 Regards,
VZ