Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS gdb versus the command line

You mean things you've written to stdout show up when you run in gdb but not the command line? There are a range of things. One could be buffering, so you could flush stdout and see if that helps. There are other things, but they are more obscure (the size of the environment shifting things around on the heap causing issues, etc.).

-Lee
 
I was told that a \n in the format automatically flushes the buffer. I don' t think I've done anything to outlandish to this code. There is, of course, my continually shifting understanding of pointers, addresses and memory. I think I will settle for getting the program to run anywhere and then make sure it works on the command line.
Thanks
 
Apparently declaring more memory than you need is not always a good idea. I would take it if a routine asks for the number of points, it really wouldn't matter how much memory has been allocated.
 
farmerdoug said:
Apparently declaring more memory than you need is not always a good idea. I would take it if a routine asks for the number of points, it really wouldn't matter how much memory has been allocated.
Click to expand...

Please clarify. Be specific.

There's nothing inherently wrong or error-prone about any memory-resident object taking more memory than it intrinsically needs. The only time that can cause problems is if the number of objects (in the general sense, not the object-oriented sense) and amount of excess memory per object incurs large amounts of unused memory. Then you run out of memory sooner. Other than that, I can't think of any problems directly attributable to overlarge memory allocations.

For example, it's sometimes convenient to align memory addresses and allotments to exact intervals of 4 KB. For any object notably less than 4 KB, this amounts to significant wastage. But unless the aggregate memory consumption becomes a problem, i.e. the program as a whole approaches available memory limits, there is no harm whatsoever for aligning to 4 KB boundaries.
 
farmerdoug said:
warning
This error
float *f; *g;

gives an warning not an error.
Click to expand...

You have a semicolon between them. That makes them. Two. Separate statements. And your second statement doesn't have a type declaration. It's just an unadorned "*g". Which may be a valid statement. Depending on the context. Which you haven't posted.

I think you want a comma instead of a semicolon.

This code:
Code: 
#include <stdio.h>

int main()
{
	float *f; *g;

	printf( "Ohai \n" );
	return 0;
}

produces this error (not a warning):
Code: 
floaty.c: In function 'main':
floaty.c:5: error: 'g' undeclared (first use in this function)
floaty.c:5: error: (Each undeclared identifier is reported only once
floaty.c:5: error: for each function it appears in.)

Post your code.
 
1. The warning post was I think to myself mostly. I get in habit of ignoring warnings because usually I've declared something that I'm not using but sometimes you can get bitten. I think "*g;" rates an error.

2. The post about allocation too much memory was an observation. Maybe I changed two or too many things at once but reducing the allocated memory from 250 to 175 floats does not seem like much yet it seem to clear up a problem.

Time to go home. Code is working up to a point where I can pick up tomorrow.

doug
 
farmerdoug said:
1. The warning post was I think to myself mostly. I get in habit of ignoring warnings because usually I've declared something that I'm not using but sometimes you can get bitten. I think "*g;" rates an error.
Click to expand...

Add the option -Werror to your compiles. It causes all warnings to be treated as errors. This will force you to use a certain amount of discipline, and prevent you from ignoring warnings. I highly recommend this. It's pretty simple and basic code hygiene.

The person hurt most by ignoring warnings is you. The person who stands to benefit most by cleaning up warnings is you.


2. The post about allocation too much memory was an observation. Maybe I changed two or too many things at once but reducing the allocated memory from 250 to 175 floats does not seem like much yet it seem to clear up a problem.
Click to expand...

I can't think of any errors that would be fixed by reducing the size of an allocation like that. Other than improper use of memory.

Logic strongly suggests this is a red herring. Extra memory is allocated but unused. If nothing is using it, then it can't have any effect. The amount and location of unused memory should have no effect on a properly running program (except as noted above regarding overall memory consumption). If something is using the extra memory, then it's doing so erroneously.

At this point, however, I haven't seen any code, so there may be some proximal reason appearing in the actual code that doesn't appear in your description. Since you've done this before (significant disparity between code and description), I wouldn't exclude it as a hypothesis without seeing actual code.

The only kinds of errors that might be affected by a smaller allocation are ones involving memory stomping (improper pointers, improper sizes, buffer overruns, etc.). Not having seen code, that's where I'd place my bet.
 
I'll send you the appropriate code in the morning. I didn't post it because I didn't want or need anybody to go through it. I was just glad that it started working; Now I'm curious.

I usually comment out unused variables and fix other warnings. Should go back to that.
 
Chown. Here's the code. No it not complete; you couldn't compile it anyway.
And I'm not sufficiently interested to know why it started working to write additional test code. So nobody give me any crap. okay :)

I think when I reduced the size of allocated memory spline started working.

If you do see something please let me know.


Code: 
float *x1, *x2, **ys;
float *yy1, *ys1, *YS1, *cys1; 


void magnify1(float *image, int rows, int cols)
{
	float result;
	    
    float frow, fcol;
	int i, r, c;

//calloc for 1 D
	    
for (row = 0; row < rows; row++)
    x1[row] = (float) row;
    
    for (col = 0; col < cols; col++)
    {
        for (row = 0; row < rows; row++)
            yy1[row] = image[(row + 37)*lenslets_size + col + 37];		// for each row you have an array of the col number and an array of pixel value						
     
    spline( x1,yy1,rows,0,0, ys1);                   //make the ys1 array 
    memcpy(YS1+col*reduced_size, ys1, sizeof(float)*reduced_size);

    
    // printf("here \n");
    // for ( i = 0; i < 10; i ++)
     //           printf("here %f \n",  *(YS1+col*reduced_size + i) );
                
    }
             
//return (YS1);    
}

void getmemory(int rows, int cols)
{   
    if ((x1 = (float *)calloc(reduced_size,sizeof(float))) == NULL)
        {
            printf("no x1 memory\n");
            exit(0);
        }
	if ((yy1 = (float *)calloc(reduced_size,sizeof(float))) == NULL)
        {
            printf("no x2 memory\n");
            exit(0);
        }
    if ((ys1 = (float *)calloc(reduced_size ,sizeof(float))) == NULL)
        {
            printf("no ys1 memory\n");
            exit(0);
        }
    if ((YS1 = (float *)calloc(reduced_size *reduced_size ,sizeof(float))) == NULL)
        {
            printf("no YS1 memory\n");
            exit(0);
        }
    if ((cys1 = (float *)calloc(waves*reduced_size*reduced_size ,sizeof(float))) == NULL)
        {
            printf("no cys1 memory\n");
            exit(0);
        }
}
    
void spline(float x[], float y[], int n, float yp1, float ypn, float y2[])
{
	int i,k;
	float p,qn,sig,un,*u;

	if ( !( u = (float *)calloc (2*n,sizeof (float)) ))
		printf( "calloc failed\n");
	

	if (yp1 > 0.99e30) //The lower boundary condition is set either to be "natural"
		y2[0]=u[0]=0.0; 
	else {				//or else to have a specified first derivative.
		y2[0] = -0.5;
		u[0]=(3.0/(x[1]-x[0]))*((y[1]-y[0])/(x[1]-x[0])-yp1);
	}
	for (i=1;i<=n-2;i++) {		//This is the decomposition loop of the tridiagonal algorithm.	y2 and u are used for temporary
		//storage of the decomposed factors.
		sig=(x[i]-x[i-1])/(x[i+1]-x[i-1]);
		p=sig*y2[i-1]+2.0;
		y2[i]=(sig-1.0)/p;
		u[i]=(y[i+1]-y[i])/(x[i+1]-x[i]) - (y[i]-y[i-1])/(x[i]-x[i-1]);
		u[i]=(6.0*u[i]/(x[i+1]-x[i-1])-sig*u[i-1])/p;
	}


	n = n-1;
	if (ypn > 0.99e30)     //The upper boundary condition is set either to be "natural"
		qn=un=0.0;				//or else to have a specified first derivative.
	else {					
		
		qn=0.5;
		un=(3.0/(x[n]-x[n-1]))*(ypn-(y[n]-y[n-1])/(x[n]-x[n-1]));
	}
	y2[n]=(un-qn*u[n-1])/(qn*y2[n-1]+1.0);
	for (k=n;k>=0;k--)		//This is the backsubstitution loop of the tridiagonal algorithm.
		y2[k]=y2[k]*y2[k+1]+u[k]; 
	
//	printf("here\n");
	
	free (u);
	
	
}
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back