gdb versus the command line

Discussion in 'Mac Programming' started by farmerdoug, Feb 24, 2010.

  1. farmerdoug macrumors 6502a

    Joined:
    Sep 16, 2008
    #1
    Why might I get an output from gdb but not the command line?
     
  2. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #2
    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
     
  3. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #3
    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
     
  4. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #4
    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.
     
  5. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #5
    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.
     
  6. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #6
    warning
    This error
    float *f; *g;

    gives an warning not an error.
     
  7. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #7
    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.
     
  8. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #8
    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
     
  9. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #9
    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.


    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.
     
  10. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #10
    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.
     
  11. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #11
    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);
    	
    	
    }
    
     

Share This Page