|Anonymous | Login||2018-12-13 17:58 EST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000219||TADS 2||Interpreter||public||2014-02-28 17:10||2015-08-06 00:39|
|Assigned To||Michael Roberts|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0000219: Possible memory allocation bug|
|Description||I'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.
|Tags||No tags attached.|
|Fixed In Version||2.5.18|
Michael Roberts (administrator)
|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.|
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)
I've added this to mcm.c:
#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.
|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|