Re: big orbit problem.

[Havoc Pennington <hp redhat com>]

On Thu, 11 Nov 1999 bob@cs.csoft.net wrote:
> um,  here is all the code up to the resulting corruption. I dont see
> anything that would corrupt memory like you said.

These bugs are notoriously hard to find; the bug could be anywhere in the
program (or in ORBit, I don't deny it, but there's no real reason to
suspect that).

>  and besides, the value
> is being change at CORBA_string_dup and not before.
> 

That doesn't matter; once you corrupt memory you can cause memory to
become corrupted at arbitrary other times (because you have pointers
pointing to weird places, or weird values due to two sections of code
using the same memory).

> Boom. If you can show me where the corruption is, great. But, I dont see
> anything in the code that would do that.
> 

Well, where do you think this is causing corruption:

CORBA_char *CORBA_string_dup(CORBA_char *string)
{
        if(!string)
                return NULL;

        return strcpy(ORBit_alloc(strlen(string)+1, NULL, NULL), string);
}

The only likely candidate is that ORBit_alloc() is broken, which seems
reasonably unlikely. In any case it looks as safe as your code - which is
also calling ORBit_alloc() implicitly, I suspect.

The point is just that you shouldn't go on a CORBA_string_dup() wild goose
chase. That may or may not be the problem.

I'd run your program:

 - With the env variable MALLOC_CHECK_ set to 2
 - With Electric Fence
 - With memprof

and see if one of those turns up the problem.

Unless someone else sees it in the code, of course.

Havoc