TADS Bug Database

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000219TADS 2Interpreterpublic2014-02-28 17:102015-08-06 00:39
Assigned ToMichael Roberts 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformMacintoshOSMacOSOS VersionX
Summary0000219: Possible memory allocation bug
DescriptionI'm in the the very early stages of making a new TADS terp for OS X (and hopefully iOS).

Goal #1: get a TADS 2 terp built and have it start a game.

I've got the terp built, but it crashes in mcmcterm(), with a "*** error for object 0x...: pointer being freed was not allocated" message. Turns out that mcmcini() adjusts its return value by +sizeof(ulong), and it appears that mchfre() (#defined as free()) won't accept this non-exact pointer value.

(The DEBUG preproc sym is defined).

I'm guessing the pointer adjustment in mcmcini() is for trapping memory corruption, and that a similar scheme is emplyed in various other parts of the code.

Is there an assumption here that free() should be able to deal with "within range" pointers? Or is the DEBUG / memory corruption stuff not meant to be compiled in these days?

Sorry, it's been a while since I dealt with C lib runtime stuff like this...

Any help appreciated.

- Rune
TagsNo tags attached.
Fixed In Version2.5.18
Attached Files

- Relationships

-  Notes
Michael Roberts (administrator)
2014-02-28 18:29

Yeah, it looks like you should turn off DEBUG mode. mchfre() clearly needs to have a separate IF_DEBUG version that does a pointer decrement to match the mchalo() pointer increment, but it doesn't, so it's not just you - this won't work anywhere as it is. I don't use DEBUG mode on the Windows builds, so I guess I haven't been maintaining that - I *could* add the debug version of mchfre() to fix this particular problem, but since I evidently haven't compiled in DEBUG mode myself in many years, I suspect that would just turn up other problems. I don't see a lot of point in ironing all that out, since the compiler/OS-level debuggers these days tend to make it easier to track down the sorts of memory problems DEBUG mode was originally intended to flag.
runeberg76 (reporter)
2014-02-28 19:14

Thanks for the quick reply, Mike. #undef'ing DEBUG did indeed get rid of the crash, which is good enough for my purposes.

As for really fixing it: there's at least one other mchalo() client that does a similar pointer increment, and at least one other does not. Asymetrical. Perhaps the best thing is to add a "#undef DEBUG" to the relevant .c files?
Michael Roberts (administrator)
2015-08-06 00:39

I've added this to mcm.c:

#ifdef DEBUG
#error "This file doesn't currently work with DEBUG defined"

That should make it pretty clear what's going on. I'd rather not just #undef it since that's too stealthy - it could create confusion as to why -DDEBUG is having no effect.

If you're running into that in any other files, let me know and I'll add similar code.

- Issue History
Date Modified Username Field Change
2014-02-28 17:10 runeberg76 New Issue
2014-02-28 18:29 Michael Roberts Note Added: 0000383
2014-02-28 19:14 runeberg76 Note Added: 0000384
2015-08-06 00:39 Michael Roberts Note Added: 0000402
2015-08-06 00:39 Michael Roberts Fixed In Version => 2.5.18
2015-08-06 00:39 Michael Roberts Assigned To => Michael Roberts
2015-08-06 00:39 Michael Roberts Status new => resolved
2015-08-06 00:39 Michael Roberts Resolution open => fixed

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker