Re: big orbit problem.

[bob cs csoft net]

I have been looking through the orbit code (Complements on the ingenious
method for puting the struct before the pointer to store info about the
vaariable) 
I dont know if this is the problem, but it could be at one point or
another.
it doesnt look like corba_string_dup checks to see if it actually gets a
chunk of memory. it could posibly be failing on the malloc, and strcpying
over a rogue pointer. (or maybe not. I dont know :)

I'll play with those debuggers and see If I can find it out,
but it is very odd. I had a simple program that I made before that was
doing the same thing. I will try to dig up a copy of it for testing.

On Thu, 11 Nov 1999, Havoc Pennington wrote:

> 
> 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
> 
>