On Wed, 30 Nov 2005, Tim Jenness wrote:
>> Having a genuinely invalid locator caused chaos as dat1_import_loc.c tried
>> to cast this to (char *) and use the memory to construct an error message.
>> Maybe a better way to handle that.
>
> I don't understand. It uses emsSetnc and that is meant to restrict the number
> of characters that are stored in the token. It's readonly memory so it
> shouldn't be writing in areas that are dodgy even if the pointer points to
> random memory.
Hi Tim,
the fix you've done is clearly worthwhile, but doesn't get to what
happened here. The locator was over written so had a garbage value, which
didn't point at any accessible memory, readonly or otherwise, so that
caused a core dump when an attempt to dereference it happened (the fact
that it was during an error report and cast to (char *) doesn't matter).
The difference is that in the past this would have mattered less, simply
because it would be a character array that held garbage values, a point
which HDS presumably picked up when decoding and made an error report
with. Now the garbage hits a pointer that HDS actually tries to
dereference, that's slightly less safe than before (I freely admit this
really points to the need for better programming and reveals out more of
your bugs more quickly). So I guess the change in behaviour here is, is do
you really want to core dump or continue to make error reports about
garbage locators?
>> You're right about the other two, looking closer they have a locator leak
>> -- the datAnnul happens in an inner loop to the locator allocation.
>
> Have you fixed them?
Yes.
Cheers,
Peter.
|