llvm dev - Jan 2007 - [LLVMdev] Semi-random crashes seemingly related to Arguments

I've been having somewhat semi-random crashes that seem to be related  
to my use of Argument objects, usually when I then try to use them for  
processing, for examples in a CallInst.

Do I need to copy or wrap the Argument if I want to use it as a  
Value?  Or can I just use the reference that I am getting (multiple  
times)?  I think there is probably something very fundamental about  
the ownership model / memory management or how Argument objects work  
that I am missing (or (e) all of the above).

The code below is what I use to fetch arguments from the Function  
object in order to use them.  I wrap them up in an Objective-C object  
that just holds on to the pointer.  The really weird part is the line  
above the (non-exception) return statement.  It is obviously totally  
useless and should have no effect whatsoever.  However, without it I  
will crash sometime later, either when creating a CallInst that uses  
the Argument in question or when actually generating code for the  
CallInst slightly later.   (I used to have an NSLog() there that had  
the same effect, but my hunch was that it was just malloc() activity,  
not anything to do with the I/O taking place.

The code is mostly ripped from the examples, but I couldn't find any  
uses where the Argument obtained survives beyond the scope of the  
local function.

There have been other bits of weirdness about Arguments, for example  
crashes or non-crashes depending on wether they had a name set or not  
(all combinations of these two parameters), but those seem to be  
quiescent at the time.  Any ideas?

Thanks,

Marcel


------- my weird code.m ------------
-argumentAtIndex:(int)argIndex
{
         Argument *ArgX;
         if ( argIndex < numArgs ) {
                 int i;
                 ArgX = ((Function*)function)->arg_begin();
                 for (i=0 ;i<argIndex;i++) {
                         ++ArgX;
                 }

                 [NSString stringWithFormat:@"get argument[%d/%d]= 
%x",argIndex,numArgs,ArgX];     //   with this in place, it doesn't  
crash
                 return [MPWLLVMValue  
llvmValueWithLLVMValue:ArgX];  // wrap the arg
         } else {
		//--- error handling, irrelevant here...
                 [NSException raise:@"IndexOutOfBounds"  
format:@"requesting argument %d when only %d  
available",argIndex,numArgs];
                 return nil;
         }
}

On Mon, 22 Jan 2007, Marcel Weiher wrote:
> I've been having somewhat semi-random crashes that seem to be related
> to my use of Argument objects, usually when I then try to use them for
> processing, for examples in a CallInst.
Your code looks pretty reasonable to me.  The only thing to be aware of is 
that varargs functions will have fewer Argument nodes than calls to the 
functions have (e.g. the values passed through the "..." won't
have a
corresponding Argument).  Other than that, I can't think of anything 
off-hand.

-Chris
> Do I need to copy or wrap the Argument if I want to use it as a
> Value?  Or can I just use the reference that I am getting (multiple
> times)?  I think there is probably something very fundamental about
> the ownership model / memory management or how Argument objects work
> that I am missing (or (e) all of the above).
>
> The code below is what I use to fetch arguments from the Function
> object in order to use them.  I wrap them up in an Objective-C object
> that just holds on to the pointer.  The really weird part is the line
> above the (non-exception) return statement.  It is obviously totally
> useless and should have no effect whatsoever.  However, without it I
> will crash sometime later, either when creating a CallInst that uses
> the Argument in question or when actually generating code for the
> CallInst slightly later.   (I used to have an NSLog() there that had
> the same effect, but my hunch was that it was just malloc() activity,
> not anything to do with the I/O taking place.
>
> The code is mostly ripped from the examples, but I couldn't find any
> uses where the Argument obtained survives beyond the scope of the
> local function.
>
> There have been other bits of weirdness about Arguments, for example
> crashes or non-crashes depending on wether they had a name set or not
> (all combinations of these two parameters), but those seem to be
> quiescent at the time.  Any ideas?
>
> Thanks,
>
> Marcel
>
>
> ------- my weird code.m ------------
> -argumentAtIndex:(int)argIndex
> {
>         Argument *ArgX;
>         if ( argIndex < numArgs ) {
>                 int i;
>                 ArgX = ((Function*)function)->arg_begin();
>                 for (i=0 ;i<argIndex;i++) {
>                         ++ArgX;
>                 }
>
>                 [NSString stringWithFormat:@"get argument[%d/%d]>
%x",argIndex,numArgs,ArgX];     //   with this in place, it doesn't
> crash
>                 return [MPWLLVMValue
> llvmValueWithLLVMValue:ArgX];  // wrap the arg
>         } else {
> 		//--- error handling, irrelevant here...
>                 [NSException raise:@"IndexOutOfBounds"
> format:@"requesting argument %d when only %d
> available",argIndex,numArgs];
>                 return nil;
>         }
> }
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Thanks to Chris, this is now working.  The problem was the way I had  
copied the sample code without fully understanding it and thus misused  
the automatic iterator->class-pointer conversion.  In the sample code,  
all the functions have only a single argument so the following code is  
perfectly OK:

	Argument *ArgX = FibF->arg_begin();

However, this actually does two things:  (1) gets the iterator and (2)  
obtains the Argument* pointer from the iterator.

In my original code, I actually do the conversion above and then start  
to "iterate" with the pointer instead of the iterator.  So in effect,
I end up just incrementing the pointer and ignoring the real next  
element the iterator would have yielded.  What I needed to do was  
separate out steps (1) and (2).  Not also that there is now a cast  
from Function::arg_iterator to Argument* when sending the message.

So the corrected code is:

-argumentAtIndex:(int)argIndex
{
         if ( argIndex < numArgs ) {
                 Function::arg_iterator ArgX;			//  get the iterator,  
not the Argument* converted from the iterator
                 int i;
                 ArgX = ((Function*)function)->arg_begin();
                 for (i=0 ;i<argIndex;i++) {
                         ++ArgX;

                 }
                 return [MPWLLVMValue llvmValueWithLLVMValue: 
(Argument*)ArgX];  //  get actual Argument pointer from iterator
         } else {
                 [NSException raise:@"IndexOutOfBounds"  
format:@"requesting argument %d when only %d available",arg
Index,numArgs];
                 return NULL;
         }
}


On Jan 23, 2007, at 11:33 , Chris Lattner wrote:
>
> Your code looks pretty reasonable to me.  The only thing to be aware  
> of is
> that varargs functions will have fewer Argument nodes than calls to  
> the
> functions have (e.g. the values passed through the "..."
won't have a
> corresponding Argument).  Other than that, I can't think of anything
> off-hand.
>
>> ------- my weird code.m ------------
>> -argumentAtIndex:(int)argIndex
>> {
>>         Argument *ArgX;
>>         if ( argIndex < numArgs ) {
>>                 int i;
>>                 ArgX = ((Function*)function)->arg_begin();
>>                 for (i=0 ;i<argIndex;i++) {
>>                         ++ArgX;
>>                 }
>>
>>                 [NSString stringWithFormat:@"get
argument[%d/%d]>> %x",argIndex,numArgs,ArgX];     //   with this in
place, it doesn't
>> crash
>>                 return [MPWLLVMValue
>> llvmValueWithLLVMValue:ArgX];  // wrap the arg
>>         } else {
>> 		//--- error handling, irrelevant here...
>>                 [NSException raise:@"IndexOutOfBounds"
>> format:@"requesting argument %d when only %d
>> available",argIndex,numArgs];
>>                 return nil;
>>         }
>> }