Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #89738 > unrolled thread

Long Question: What might cause the seg fault?

Back to article view | Back to comp.lang.c

Contents

  Long Question: What might cause the seg fault? bilsch <king621@comcast.net> - 2016-06-21 15:04 -0700
    Re: Long Question: What might cause the seg fault? BartC <bc@freeuk.com> - 2016-06-21 23:51 +0100
      Re: Long Question: What might cause the seg fault? BartC <bc@freeuk.com> - 2016-06-21 23:53 +0100
        Re: Long Question: What might cause the seg fault? bilsch <king621@comcast.net> - 2016-06-22 01:55 -0700
      Re: Long Question: What might cause the seg fault? John Gordon <gordon@panix.com> - 2016-06-22 00:25 +0000
    Re: Long Question: What might cause the seg fault? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-21 19:22 -0400
      Re: Long Question: What might cause the seg fault? John Gordon <gordon@panix.com> - 2016-06-22 00:17 +0000
    Re: Long Question: What might cause the seg fault? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-21 19:35 -0400
      Re: Long Question: What might cause the seg fault? bilsch <king621@comcast.net> - 2016-06-22 03:36 -0700
    Re: Long Question: What might cause the seg fault? John Gordon <gordon@panix.com> - 2016-06-22 00:29 +0000
      Re: Long Question: What might cause the seg fault? bilsch <king621@comcast.net> - 2016-06-22 03:38 -0700
    Re: Long Question: What might cause the seg fault? Barry Schwarz <schwarzb@dqel.com> - 2016-06-21 21:20 -0700

#89738 — Long Question: What might cause the seg fault?

Please see code samples #1 and #2 below.  Code sample #1 works fine. The 
output from sample #1 is shown below.

Code sample #2 below, is part of a much larger program.  I think sample 
#2 is equivalent to function fdmode() in code sample #1.  Sample #2 gets 
segmentation fault during the second iteration of function fdmode(). The 
output from sample #2 is also shown below. The seg fault occurs the 
second time fdmode() in sample #2 is called.  The seg fault happens 
after the following lines:

fdsel=quorem.rem;	
printf("fdsel = %i\n",fdsel);

QUESTION: I don't think code sample #2 contains the underlying cause of 
the seg. fault.  There is something wrong in the larger program of which 
sample #2 is a small part.  What might this be?
Note: there is no other dynamic memory allocation than that shown.
    Thanks.  Bill S.

************* output of sample #1  (works fine)   *************

fdsel = 1
w1=0.001000 w2=8.521000 w3=0.251593 nfgraf=2
fdsel = 0
w1=9.411000 w2=3.141593 w3=8.438000 nfgraf=2
fdflag = 0

****************   output of sample#2   ***********************

9.411, 1.937, 8.438, 0.001, 4, 7, 550, 325, 200, 200, 10, 6000},
7.388, 3.212, 4.428, 0.001, 3, 12, 650, 75, 350, 200, 15, 9900},
5.064, 2.101, 3.429, 0.001, 5, 1, 600, 300, 200, 125, 10, 6000},
37.500, 8.508, 0.001, 0.001, 5, 8, 600, 325, 200, 150, 20, 2400},
0.074, 6.224, 0.043, 0.010, 8, 5, 300, 300, 200, 200, 20, 2400},
0.537, 0.188, 5.493, 0.001, 6, 11, 600, 50, 200, 200, 0, 6000},
4.853, 3.434, 9.815, 0.001, 5, 1, 600, 350, 200, 200, 15, 6000},
1.861, 0.054, 0.981, 0.007, 11, 4, 400, 400, 200, 150, 0, 8000},
3.051, 7.751, 0.798, 0.001, 10, 4, 175, 400, 150, 150, 0, 8000},
0.066, 0.490, 9.919, 0.001, 10, 3, 600, 300, 200, 125, 0, 6000},
0.915, 0.573, 6.685, 0.010, 1, 7, 600, 300, 200, 200, 47, 5000},
3.300, 0.084, 0.810, 0.010, 6, 7, 650, 325, 200, 200, 6, 8000},
6.988, 0.035, 6.775, 0.001, 7, 3, 600, 300, 200, 200, 0, 8000},
6.306, 0.720, 0.058, 0.001, 9, 10, 150, 175, 150, 150, 6, 2400},
0.612, 0.517, 7.163, 0.001, 10, 6, 150, 350, 150, 150, 6, 8000},
8.130, 0.036, 0.325, 0.010, 1, 5, 600, 300, 200, 200, 0, 5000},

fdsel = 14
nfgraf=16
fdsel = 5
Segmentation fault (core dumped)

[code]
******************   code sample #1   **********************

int i=0, nfgraf=0, nx=0, n1=0, n2=0, rnum, fdflag=1, fdsel;	



float w1=0.5, w2=2.0, w3=0.14159;

float *fw1,*fw2,*fw3;

char ch;

div_t quorem;	// a structure

FILE *fp1;



int fdmode(void);



int main(int argc, char **argv){



srand(time(0));		//  current time is seed for random gen

if ((fp1 = fopen("adata", "r"))== NULL)

{	printf("error opening file named 'adata'\n");

	fclose(fp1);

	goto end;
}


i=0;

while (ch != EOF)

{       if ((ch=fgetc(fp1)) == ' ')  //  ascii 0x20 between numbers

	i++;

}

quorem=div(i,3);   // 3 numbers in each record.

nfgraf=quorem.quot;



if (quorem.rem != 0 || quorem.quot == 0)

{	printf("file named 'adata' is not evenly divisible by 3\n");

	fclose(fp1);

	goto end;
}


rewind(fp1);



while (fdflag != 0)

{

fdflag=1;
fdmode();

}

return 0;
    // end of main()
}



int fdmode(void)
{



if (nx==0)   //  nx was init. to 0

{

if ((fw1 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");

if ((fw2 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");

if ((fw3 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");



for (n1=0;n1<nfgraf;n1++)		//  nfgraf starts at 1

{

	fscanf(fp1,"%f %f %f",&fw1[n1],&fw2[n1],&fw3[n1]);

	printf("%2.3f, %2.3f, %2.3f\n\n",fw1[n1],fw2[n1],fw3[n1]);

}

fclose(fp1);

}	//  end of if (nx==0)	



rnum = rand();	//  this part random selects data record

quorem = div(rnum,nfgraf);

fdsel=quorem.rem;		//  fdsel is zero based

printf("fdsel = %i\n",fdsel);



w1 = fw1[fdsel];

w2 = fw2[fdsel];

w3 = fw3[fdsel];



printf("w1=%f  w2=%f   w3=%f   nfgraf=%i\n",w1,w2,w3,nfgraf);



nx++;



if (nx == nfgraf)

{

free(fw1);

free(fw2);

free(fw3);

fdflag=0;
	//  fdflag=1 when fdmode is called
printf("fdflag = 0\n");

}

return 0;

}

******************   code sample #2   **********************
int fdmode(void){

int fdsel,i;

float *fw1,*fw2,*fw3,*fk1;

int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;



if (nx==0)	//  nx was init. to 0

{

if ((fw1 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");

if ((fw2 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");

if ((fw3 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");

if ((fk1 = malloc(nfgraf * sizeof(float))) == NULL)

	printf("malloc error\n");

if ((fxf = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fyf = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fxof = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fyof = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fxm = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fym = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fdelay = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");

if ((fglen = malloc(nfgraf * sizeof(int))) == NULL)

	printf("malloc error\n");



for (i=0;i<nfgraf;i++)		//  nfgraf starts at 1

{

	fscanf(fp1,"%f %f %f %f %i %i %i %i %i %i %i %i "

,&fw1[i],&fw2[i],&fw3[i],&fk1[i],&fxf[i],&fyf[i],&fxof[i],&fyof[i],&fxm[i],&fym[i],&fdelay[i],&fglen[i]);

	printf("%2.3f, %2.3f, %2.3f, %2.3f, %i, %i, %i, %i, %i, %i, %i, %i},\n"
 
,fw1[i],fw2[i],fw3[i],fk1[i],fxf[i],fyf[i],fxof[i],fyof[i],fxm[i],fym[i],fdelay[i],fglen[i]);

}

fclose(fp1);

}



rnum = rand();
quorem = div(rnum,nfgraf);

fdsel=quorem.rem;	//  fdsel is zero based

printf("fdsel = %i\n",fdsel);



w1 = fw1[fdsel];

w2 = fw2[fdsel];

w3 = fw3[fdsel];

k1 = fk1[fdsel];

xf = fxf[fdsel];

yf = fyf[fdsel];

xof = fxof[fdsel];

yof = fyof[fdsel];

xm = fxm[fdsel];

ym = fym[fdsel];

delay = fdelay[fdsel];

glen = fglen[fdsel];

printf("nfgraf=%i\n",nfgraf);



nx++;

if (nx == nfgraf)

{

free(fw1);

free(fw2);

free(fw3);

free(fk1);

free(fxf);

free(fyf);

free(fxof);

free(fyof);

free(fxm);

free(fym);

free(fdelay);

free(fglen);



fdflag=0;

printf("fdflag=0\n");

}

return 0;

}

[/code]

[toc] | [next] | [standalone]

#89739

On 21/06/2016 23:04, bilsch wrote:
> Please see code samples #1 and #2 below.  Code sample #1 works fine. The
> output from sample #1 is shown below.
>
> Code sample #2 below, is part of a much larger program.  I think sample
> #2 is equivalent to function fdmode() in code sample #1.  Sample #2 gets
> segmentation fault during the second iteration of function fdmode(). The
> output from sample #2 is also shown below. The seg fault occurs the
> second time fdmode() in sample #2 is called.  The seg fault happens
> after the following lines:

> fdsel = 14
> nfgraf=16
> fdsel = 5
> Segmentation fault (core dumped)

> ******************   code sample #2   **********************
> int fdmode(void){
>
> int fdsel,i;
>
> float *fw1,*fw2,*fw3,*fk1;
>
> int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;
>

> if (nx==0)    //  nx was init. to 0
>
> {
>
> if ((fw1 = malloc(nfgraf * sizeof(float))) == NULL)
>
>     printf("malloc error\n");

>
> if (nx == nfgraf)
>
> {
>
> free(fw1);

So fdmode is called with different values of nx?

It seems those pointers (fxm etc) are only initialised when nx is 0; 
next time, nx is 1 (?), but the pointers will not retain their previous 
values. Try this:

static int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89740

On 21/06/2016 23:51, BartC wrote:
> On 21/06/2016 23:04, bilsch wrote:

> values. Try this:
>
> static int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;
>

You need 'static' in front of the float pointer declarations too of course.

With static, variables in a function keep their value for the next call 
of the function.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89750

On 06/21/2016 03:53 PM, BartC wrote:
> On 21/06/2016 23:51, BartC wrote:
>> On 21/06/2016 23:04, bilsch wrote:
>
>> values. Try this:
>>
>> static int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;
>>
>
> You need 'static' in front of the float pointer declarations too of course.
>
> With static, variables in a function keep their value for the next call
> of the function.
>

Thanks.  That solved the problem.

[toc] | [prev] | [next] | [standalone]

#89746

In <nkcgea$776$1@dont-email.me> BartC <bc@freeuk.com> writes:

> > float *fw1,*fw2,*fw3,*fk1;
> > int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;
> > if (nx==0)    //  nx was init. to 0
> > {
> > if ((fw1 = malloc(nfgraf * sizeof(float))) == NULL)
> >     printf("malloc error\n");

> It seems those pointers (fxm etc) are only initialised when nx is 0; 
> next time, nx is 1 (?), but the pointers will not retain their previous 
> values. Try this:

> static int *fxf,*fyf,*fxof,*fyof,*fxm,*fym,*fdelay,*fglen;

This explains a lot.  I wondered why the heck the mallocs were gated
behind the if...

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#89741

On 6/21/2016 6:04 PM, bilsch wrote:
> Please see code samples #1 and #2 below.  Code sample #1 works fine. The
> output from sample #1 is shown below.
> 
> Code sample #2 below, is part of a much larger program.  I think sample
> #2 is equivalent to function fdmode() in code sample #1.  Sample #2 gets
> segmentation fault during the second iteration of function fdmode(). The
> output from sample #2 is also shown below. The seg fault occurs the
> second time fdmode() in sample #2 is called.  The seg fault happens
> after the following lines:
> 
> fdsel=quorem.rem;   
> printf("fdsel = %i\n",fdsel);
> 
> QUESTION: I don't think code sample #2 contains the underlying cause of
> the seg. fault.  There is something wrong in the larger program of which
> sample #2 is a small part.  What might this be?
> Note: there is no other dynamic memory allocation than that shown.
>    Thanks.  Bill S.
> 
<snip>

fw1[i] <-- This points at fw1[1] (the second element of an array) the
second time through, but you only allocated enough room for one value.
The same with the other pointers in your program.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#89745

In <nkci72$c06$1@jstuckle.eternal-september.org> Jerry Stuckle <jstucklex@attglobal.net> writes:

> fw1[i] <-- This points at fw1[1] (the second element of an array) the
> second time through, but you only allocated enough room for one value.
> The same with the other pointers in your program.

That's what I thought at first too, but the malloc calls look like this:

    if ((fw1 = malloc(nfgraf * sizeof(float))) == NULL)
        printf("malloc error\n");

According to the output nfgraf is 16, so he's allocating enough space
for 16 floats.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#89742

On 06/21/2016 06:04 PM, bilsch wrote:
> Please see code samples #1 and #2 below.  Code sample #1 works fine. The 
> output from sample #1 is shown below.
> 
> Code sample #2 below, is part of a much larger program.  I think sample 
> #2 is equivalent to function fdmode() in code sample #1.  Sample #2 gets 
> segmentation fault during the second iteration of function fdmode(). The 
> output from sample #2 is also shown below. The seg fault occurs the 
> second time fdmode() in sample #2 is called.  The seg fault happens 
> after the following lines:
> 
> fdsel=quorem.rem;	
> printf("fdsel = %i\n",fdsel);
> 
> QUESTION: I don't think code sample #2 contains the underlying cause of 
> the seg. fault.  There is something wrong in the larger program of which 
> sample #2 is a small part.  What might this be?
> Note: there is no other dynamic memory allocation than that shown.
>     Thanks.  Bill S.
...

I'm going to give you advice that is, in many cases, probably completely
unrelated to the cause of your problems. That's because this advice is
easier to give then tracking down that cause. It's also because
following this advice might make it easier to track down that cause.

As displayed by my news reader, your code contains huge numbers of
blanks lines that make it hard to read. It also has almost no
indentation, certainly not in a lot of places where it conventionally
should have been indented, which also makes it hard to read. I've seen
news reading software mangle code in similar ways, however your code
does have some indentation, which wouldn't happen if you were using such
software. Also, you tend not to insert spaces between arguments of a
function, which also makes your code hard to read, and that's not the
kind of thing that you can blame on your news reader. Your message
headers indicate that you're using mozilla thunderbird, the same
software that I use, which suggests that these features are in your
actual code. In that case, I'd strongly suggest inserting white space in
your code in a more conventional way.

Secondly - the behavior of your program depends upon the values returned
by rand(). That may be a necessity for your actual code, but the lack of
repeatability makes debugging unnecessarily difficult. I recommend
changing your code to print out the seed value that it uses, and then
finding a seed value that makes your code fail. Then change your your
code (only for debugging purposes) to always call srand() with that
particular seed value, to guarantee that you get the same sequence of
random numbers each time your code executes.

When you post your code to comp.lang.c, you can't guarantee that rand()
will produce the same sequence of numbers on other people's systems that
it does on yours. The solution is to record the values returned by
rand(), and then put that list of values in your code as an array.
Replace calls to rand() with code that retrieves consecutive values from
the array: random_number[rand_index++]. After making this change,
confirm that your code still fails the same way it did when calling
rand(). If it does, you're ready to post your code to comp.lang.c.

I strongly recommend simplifying your code by replacing such things as

     float *fw1,*fw2,*fw3;

with
     float *fw[3];

and replacing fw1 with fw[0], fw2 with fw[1], etc.
Then you can allocate and deallocate them using loops:

     for(i=0; i<3; i++)
         free(fw[i]);

which would improve the readability of your code.
I also recommend using the following idiom for allocating those pointers:

     for(i=0; i<3; i++)
     {
          fw[i] = malloc(nfgraf * sizeof *fw[i]);

That makes it clear, just by looking at that single line, that the
correct amount of space has been allocated. When you use sizeof(float),
you can only be sure whether it's the correct amount of space by looking
back at the declaration for fw. If, in a later version of the code, you
decide to change from float to double, you'll have to change all of
those sizeof(float) expressions to sizeof(double). With my suggested
replacement code, the only place where you would need to change float to
double is in the declaration of fw itself.

I notice that your program checks for the possibility that malloc()
might return a null pointer, but that the only thing it does about the
fact is print out an error message. It then goes ahead and attempts to
dereference that null pointer. You should not write code which tries to
dereference such pointers - the behavior is undefined, which means that
in principle, it might cause something to happen which is much worse
than simply terminating with a segmentation fault.

When asking people to help with debug your code, you should present them
with a complete compilable program that actually demonstrates your
program. Sample 1 is not compilable because it's missing several
standard headers, and it has no label named 'end'. I added those headers
and inserted such a label - hopefully in the right location. You should
identify where that label is located.

Sample 2 is uncompilable for the same reasons, but also because it
refers to many things it doesn't actually contain. If I treat it as a
replacement for fdmode() from sample 1, that resolves many of the
problems, but it still refers to many undeclared variables: k1, xf, yf,
xof, yof, xm, ym, delay, and glen. All of those variables are set to a
value, but that value is never used, so I just removed them.

Your program requires an input file, which you have not provided. It's
possible to investigate this problem without such a file, but it's
unnecessarily difficult, so I'm going to wait until you provide such a
file before investigating further.

[toc] | [prev] | [next] | [standalone]

#89751

On 06/21/2016 04:35 PM, James R. Kuyper wrote:
> On 06/21/2016 06:04 PM, bilsch wrote:
>> Please see code samples #1 and #2 below.  Code sample #1 works fine. The
>> output from sample #1 is shown below.
>>
>> Code sample #2 below, is part of a much larger program.  I think sample
>> #2 is equivalent to function fdmode() in code sample #1.  Sample #2 gets
>> segmentation fault during the second iteration of function fdmode(). The
>> output from sample #2 is also shown below. The seg fault occurs the
>> second time fdmode() in sample #2 is called.  The seg fault happens
>> after the following lines:
>>
>> fdsel=quorem.rem;	
>> printf("fdsel = %i\n",fdsel);
>>
>> QUESTION: I don't think code sample #2 contains the underlying cause of
>> the seg. fault.  There is something wrong in the larger program of which
>> sample #2 is a small part.  What might this be?
>> Note: there is no other dynamic memory allocation than that shown.
>>      Thanks.  Bill S.
> ...
>
> I'm going to give you advice that is, in many cases, probably completely
> unrelated to the cause of your problems. That's because this advice is
> easier to give then tracking down that cause. It's also because
> following this advice might make it easier to track down that cause.
>
> As displayed by my news reader, your code contains huge numbers of
> blanks lines that make it hard to read. It also has almost no
> indentation, certainly not in a lot of places where it conventionally
> should have been indented, which also makes it hard to read. I've seen
> news reading software mangle code in similar ways, however your code
> does have some indentation, which wouldn't happen if you were using such
> software. Also, you tend not to insert spaces between arguments of a
> function, which also makes your code hard to read, and that's not the
> kind of thing that you can blame on your news reader. Your message
> headers indicate that you're using mozilla thunderbird, the same
> software that I use, which suggests that these features are in your
> actual code. In that case, I'd strongly suggest inserting white space in
> your code in a more conventional way.
>
> Secondly - the behavior of your program depends upon the values returned
> by rand(). That may be a necessity for your actual code, but the lack of
> repeatability makes debugging unnecessarily difficult. I recommend
> changing your code to print out the seed value that it uses, and then
> finding a seed value that makes your code fail. Then change your your
> code (only for debugging purposes) to always call srand() with that
> particular seed value, to guarantee that you get the same sequence of
> random numbers each time your code executes.
>
> When you post your code to comp.lang.c, you can't guarantee that rand()
> will produce the same sequence of numbers on other people's systems that
> it does on yours. The solution is to record the values returned by
> rand(), and then put that list of values in your code as an array.
> Replace calls to rand() with code that retrieves consecutive values from
> the array: random_number[rand_index++]. After making this change,
> confirm that your code still fails the same way it did when calling
> rand(). If it does, you're ready to post your code to comp.lang.c.
>
> I strongly recommend simplifying your code by replacing such things as
>
>       float *fw1,*fw2,*fw3;
>
> with
>       float *fw[3];
>
> and replacing fw1 with fw[0], fw2 with fw[1], etc.
> Then you can allocate and deallocate them using loops:
>
>       for(i=0; i<3; i++)
>           free(fw[i]);
>
> which would improve the readability of your code.
> I also recommend using the following idiom for allocating those pointers:
>
>       for(i=0; i<3; i++)
>       {
>            fw[i] = malloc(nfgraf * sizeof *fw[i]);
>
> That makes it clear, just by looking at that single line, that the
> correct amount of space has been allocated. When you use sizeof(float),
> you can only be sure whether it's the correct amount of space by looking
> back at the declaration for fw. If, in a later version of the code, you
> decide to change from float to double, you'll have to change all of
> those sizeof(float) expressions to sizeof(double). With my suggested
> replacement code, the only place where you would need to change float to
> double is in the declaration of fw itself.
>
> I notice that your program checks for the possibility that malloc()
> might return a null pointer, but that the only thing it does about the
> fact is print out an error message. It then goes ahead and attempts to
> dereference that null pointer. You should not write code which tries to
> dereference such pointers - the behavior is undefined, which means that
> in principle, it might cause something to happen which is much worse
> than simply terminating with a segmentation fault.
>
> When asking people to help with debug your code, you should present them
> with a complete compilable program that actually demonstrates your
> program. Sample 1 is not compilable because it's missing several
> standard headers, and it has no label named 'end'. I added those headers
> and inserted such a label - hopefully in the right location. You should
> identify where that label is located.
>
> Sample 2 is uncompilable for the same reasons, but also because it
> refers to many things it doesn't actually contain. If I treat it as a
> replacement for fdmode() from sample 1, that resolves many of the
> problems, but it still refers to many undeclared variables: k1, xf, yf,
> xof, yof, xm, ym, delay, and glen. All of those variables are set to a
> value, but that value is never used, so I just removed them.
>
> Your program requires an input file, which you have not provided. It's
> possible to investigate this problem without such a file, but it's
> unnecessarily difficult, so I'm going to wait until you provide such a
> file before investigating further.
>

T hanks for the comments.

[toc] | [prev] | [next] | [standalone]

#89748

In <nkcdmc$usf$1@dont-email.me> bilsch <king621@comcast.net> writes:

> QUESTION: I don't think code sample #2 contains the underlying cause of 
> the seg. fault.  There is something wrong in the larger program of which 
> sample #2 is a small part.  What might this be?

These kinds of errors are caused by writing beyond the end of a buffer,
calling free() on a value that was not returned from malloc, or calling
free() twice on the same value.

It's as simple, and as complicated, as that.  Your code is doing this
somewhere.  The trick is finding where.

> Note: there is no other dynamic memory allocation than that shown.

This is no guarantee that the error is somewhere in the code you've
shown us; writing past the end of a non-dynamic buffer can cause the
problem as well.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#89752

On 06/21/2016 05:29 PM, John Gordon wrote:
> In <nkcdmc$usf$1@dont-email.me> bilsch <king621@comcast.net> writes:
>
>> QUESTION: I don't think code sample #2 contains the underlying cause of
>> the seg. fault.  There is something wrong in the larger program of which
>> sample #2 is a small part.  What might this be?
>
> These kinds of errors are caused by writing beyond the end of a buffer,
> calling free() on a value that was not returned from malloc, or calling
> free() twice on the same value.
>
> It's as simple, and as complicated, as that.  Your code is doing this
> somewhere.  The trick is finding where.
>
>> Note: there is no other dynamic memory allocation than that shown.
>
> This is no guarantee that the error is somewhere in the code you've
> shown us; writing past the end of a non-dynamic buffer can cause the
> problem as well.
>
  Thanks for the info.

[toc] | [prev] | [next] | [standalone]

#89749

On Tue, 21 Jun 2016 15:04:58 -0700, bilsch <king621@comcast.net>
wrote:

>Please see code samples #1 and #2 below.  Code sample #1 works fine. The 
>output from sample #1 is shown below.

Code sample 1 does not compile.  main contains goto statements that
reference a non-existent label.

Code sample 2 does not compile.  It attempts to assign values to
several variables that have not been defined.

-- 
Remove del for email

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web