Re: AbiWord is too buggy for Bonita

Michael D. Crawford wrote:

>
> One some platforms, there are debugging memory allocators. I think on
> OS X, one can set the environment variable MALLOC_DEBUG, and then it
> checks for all sorts of error conditions. It should also work under
> Linux and BeOS.
>
> I think I can do that under Windows if I can build with gcc. Visual
> C++ probably has some such debugging support but I don't know yet what
> it might be.

AbiWord build great with MingW/MSYS, which (if you're unfamiliar with
it) is a Windows GCC and a build environment. If you need a custom
build, check out the CVS source and try that. "Sum1", our main Windows
QA tester, uses both that and MSVC, if I recall correctly. There is
build documentation for debug builds, or just stop by #abiword on
irc.gimp.org

If you just want to test bugs, you can try using a CVS HEAD (Developer
series, what will be 2.3.x) nightly build. The link is a
(unintentionally) well-hidden, but the page is here
http://www.abisource.com/developers/download.phtml . Sum1 contributes
nightly builds as installer packages, and I maintain the ClearDefinition
nightly builds.

For what it's worth, I use my nightly ("Afternoonly") builds in my day
to day use, and I actually find AbiWord to be more useable than recent
versions of Word (that, admittedly, I have only used when I couldn't get
AbiWord).

>
> I've long used a tool called Spotlight, from http://www.onyx-tech.com/
> to find memory bugs on a Mac. But I'm afraid it is Mac OS-9 only, it
> doesn't work on OS X. It's been several years since they released it
> with no updates since. I'm hoping they have an OS X tool in the
> works, because for a long time their domain had expired, but they
> recently resurfaced.
>
> It is not too hard to roll your own memory debugger, that may allow
> better control and ease of use. One simple thing to do is to allocate
> a block a little larger than what you need, initialize a header and
> trailer at each end of the block, and pass back to the caller a
> pointer just pass the header.
>
> Then if you write off either end of the block, you can easily detect
> it, and if you're lucky, even a read off either end might get the
> bogus value you initialized your header too, and turn an
> unreproducible bug into a reproducible one.
>
> You can also do leak detection with a custom allocator.
>
> Best,
>
> Michael D. Crawford
> GoingWare Inc. - Expert Software Development and Consulting
> http://www.goingware.com/
> crawford@goingware.com
>
> Tilting at Windmills for a Better Tomorrow.
>

-- 
Ryan Pavlik
--
"Forget injuries, never forget kindnesses."  --Confucius