Segmentation Fault

[pembed2012]

I am sure that I am missing something but I cannot get the following
code to work. It doesn't even make it to my test printf statement
before I get a segmentation fault. Does anyone have any ideas why I
can't get this to run?


void
srtn (int atm[10], int ctm[10])
{
int rng = 0;
int qu[15];
int wt[11];
int tarnd[11];
int i, j;
printf ("This is a test");
for(i = 0; i < 11; i++)
{
wt = 0;
tarnd = 0;
}
qu[0] = 0;
qu[1] = -1;
int size = 1;
i = 0;
while(qu != -1)
{
ctm[qu]--;
rng++;
for(j = i + 1; qu[j] != -1; j++)
wt[qu[j]]++;
for(j = 0; j < 10; j++)
if(atm[j] != -1)
if(atm[j] <= rng)
{
qu[size] = j;
qu[size + 1] = -1;
size++;
}
tarnd[qu]++;
if(ctm[qu] == 0);
atm[qu] = -1;
for(j = 0; j < size; j++)
if(atm[qu[j]] != -1)
if(ctm[qu[j]] < ctm[qu])
i = j;
}
for(i = 0; i < 10; i++)
tarnd += wt;
for(i = 0; i < 10; i++)
{
wt[10] += wt;
tarnd[10] += tarnd;
}
wt[10] = wt[10] / 10;
tarnd[10] = tarnd[10] / 10;

print_report (wt, tarnd);
}

 

[John Gordon]

I am sure that I am missing something but I cannot get the following
code to work. It doesn't even make it to my test printf statement
before I get a segmentation fault. Does anyone have any ideas why I
can't get this to run?

The print statement doesn't show up because it doesn't end in a newline.
Try adding a newline, like so:

printf ("This is a test\n");

 

[Fred K]

I am sure that I am missing something but I cannot get the following
code to work. It doesn't even make it to my test printf statement
before I get a segmentation fault. Does anyone have any ideas why I
can't get this to run?


void
srtn (int atm[10], int ctm[10])
{
int rng = 0;
int qu[15];
int wt[11];
int tarnd[11];
int i, j;
printf ("This is a test");
for(i = 0; i < 11; i++)
{
wt = 0;
tarnd = 0;
}
qu[0] = 0;
qu[1] = -1;
int size = 1;
i = 0;
while(qu != -1)
{
ctm[qu]--;
rng++;
for(j = i + 1; qu[j] != -1; j++)
wt[qu[j]]++;
for(j = 0; j < 10; j++)
if(atm[j] != -1)
if(atm[j] <= rng)
{
qu[size] = j;
qu[size + 1] = -1;
size++;
}
tarnd[qu]++;
if(ctm[qu] == 0);
atm[qu] = -1;
for(j = 0; j < size; j++)
if(atm[qu[j]] != -1)
if(ctm[qu[j]] < ctm[qu])
i = j;
}
for(i = 0; i < 10; i++)
tarnd += wt;
for(i = 0; i < 10; i++)
{
wt[10] += wt;
tarnd[10] += tarnd;
}
wt[10] = wt[10] / 10;
tarnd[10] = tarnd[10] / 10;

print_report (wt, tarnd);
}

The problem seems to be in the code you didn't show us.

 

[James Kuyper]

I am sure that I am missing something but I cannot get the following
code to work. It doesn't even make it to my test printf statement
before I get a segmentation fault. Does anyone have any ideas why I
can't get this to run?

The reason why the test printf() produces no visible effects before the
segmentation fault has already been provided by John Gordon. For such
debugging printouts, I generally prefer fprintf(stderr, format,
arguments) over printf(format, arguments), to avoid such problems.

There might be some fairly obvious reason why the segfault is occurring
(I've only taken a quick glance at it) but without knowing the context,
it could be very difficult to locate the problem. It would make things a
lot easier for those interested in helping you, if you could provide a
complete, simple program demonstrating the problem. That program should
set atm and ctm to point at appropriately initialized arrays. It would
also be helpful to know precisely which compiler you're using, and with
what options turned on.

 

[Fred K]

I am sure that I am missing something but I cannot get the following
code to work. It doesn't even make it to my test printf statement
before I get a segmentation fault. Does anyone have any ideas why I
can't get this to run?


void
srtn (int atm[10], int ctm[10])
{
int rng = 0;
int qu[15];
int wt[11];
int tarnd[11];
int i, j;
printf ("This is a test");
for(i = 0; i < 11; i++)
{
wt = 0;
tarnd = 0;
}
qu[0] = 0;
qu[1] = -1;
int size = 1;
i = 0;
while(qu != -1)
{
ctm[qu]--;
rng++;
for(j = i + 1; qu[j] != -1; j++)
wt[qu[j]]++;
for(j = 0; j < 10; j++)
if(atm[j] != -1)
if(atm[j] <= rng)
{
qu[size] = j;

You have no protection here for what happens
if 'size' ever gets larger than 13. If it
does, then this next statement overwrites the
bounds of qu.

qu[size + 1] = -1;
size++;
}
tarnd[qu]++;
if(ctm[qu] == 0);
atm[qu] = -1;
for(j = 0; j < size; j++)
if(atm[qu[j]] != -1)
if(ctm[qu[j]] < ctm[qu])
i = j;

With the above nested for/if/if you would
do well to use braces to delimit the loop
and 'if' tests. Note that you can keep
replacing i here - is that what you want?
Or do you want to exit the loop as soon as
you set i ? (I did not try to follow your
algorithm, but if you really want to use
the last j that fits, why not start with
size and work backwards, exiting on the first
set of i ?)

}

for(i = 0; i < 10; i++)
tarnd += wt;
for(i = 0; i < 10; i++)
{
wt[10] += wt;
tarnd[10] += tarnd;
}
wt[10] = wt[10] / 10;
tarnd[10] = tarnd[10] / 10;

print_report (wt, tarnd);
}

 

[Keith Thompson]

The print statement doesn't show up because it doesn't end in a newline.
Try adding a newline, like so:

printf ("This is a test\n");

And it couldn't hurt to add

fflush(stdout);

as well.

 

[pembed2012]

The reason why the test printf() produces no visible effects before the
segmentation fault has already been provided by John Gordon. For such
debugging printouts, I generally prefer fprintf(stderr, format,
arguments) over printf(format, arguments), to avoid such problems.

There might be some fairly obvious reason why the segfault is occurring
(I've only taken a quick glance at it) but without knowing the context,
it could be very difficult to locate the problem. It would make things a
lot easier for those interested in helping you, if you could provide a
complete, simple program demonstrating the problem. That program should
set atm and ctm to point at appropriately initialized arrays. It would
also be helpful to know precisely which compiler you're using, and with
what options turned on.

Thanks everyone, you are right. Putting \n means the printf fires, so the
segmentation fault happens later.

Greatful if anyone is able to do a full debugging of this function.
Basically it's a kind of queue finding waiting and turnaround times. I
don't know exactly how it's working.

Compiler is G++, version 3.2.2, default options.

Thanks

 

[Edward Rutherford]

And it couldn't hurt to add

fflush(stdout);

as well.

It couldn't hurt but it wouldn't help either, since stdout gets flushed
automatically at a new-line!

//EPR

 

[John Gordon]

It couldn't hurt but it wouldn't help either, since stdout gets flushed
automatically at a new-line!

Only if the output is going to a terminal. If it's going to a file,
the output could get buffered and then lost upon segfault.

 

[BartC]

void
srtn (int atm[10], int ctm[10])
{
int rng = 0;
int qu[15];

qu[size] = j;
qu[size + 1] = -1;

'size' gets to 16 at this point; the upper bound of qu is 14.

At least, when called with both atm[] and ctm[] set to all zeros. Does it
depend on these having sensible data for it to work? In that case you might
post some expected input.

 

[James Kuyper]

Greatful if anyone is able to do a full debugging of this function.

In order for anyone else to debug your code, you'll need to embed it in
a complete program, as I mentioned in the paragraph quoted above. That
program needs to set up the required initial values of the arrays that
are passed to srtn(). We don't know how they should be set. If you don't
know how those initial values should be set, either, then that's the
source of your problem, and no further explanation is needed.

Basically it's a kind of queue finding waiting and turnaround times. I
don't know exactly how it's working.

That makes it sound like it's someone else's code. If that's the case,
the best place to look for information is the source of the code. Can
you identify a person or an organization responsible for the code, and
ask your questions of them?

If it were your own code, "I don't know exactly how it's working" would
be, in itself, all of explanation that would be needed for why it isn't
working.

 

[John Gordon]

Greatful if anyone is able to do a full debugging of this function.
Basically it's a kind of queue finding waiting and turnaround times. I
don't know exactly how it's working.

I did some quick and dirty debugging, and after a few iterations of the
main loop, the segfault is triggered in this section of code:

for(j = i + 1; qu[j] != -1; j++)
wt[qu[j]]++;

j ends up with values greater than 14, which makes it run off the end of
the qu array and eventually you end up trying to access a random element
of wt, whiuch causes a segfault.

This is happening because there isn't a -1 in the qu array where you
expected there to be.

I don't know why *that* is happening, but I figured I'd leave something
for you to solve.

 

[John Gordon]

I did some quick and dirty debugging, and after a few iterations of the
main loop, the segfault is triggered in this section of code:

for(j = i + 1; qu[j] != -1; j++)
wt[qu[j]]++;

This is with the atm and ctm arguments set to all zeroes. However,
after reading BartC's reply, I tried it with those two arrays set to
all -1's and did not see a seg fault.

If the behavior of your code depends on certain input, it would be
very helpful to provide that input.

 

[pembed2012]

Greatful if anyone is able to do a full debugging of this function.
Basically it's a kind of queue finding waiting and turnaround times. I
don't know exactly how it's working.

I did some quick and dirty debugging, and after a few iterations of the
main loop, the segfault is triggered in this section of code:

for(j = i + 1; qu[j] != -1; j++)
wt[qu[j]]++;

j ends up with values greater than 14, which makes it run off the end of
the qu array and eventually you end up trying to access a random element
of wt, whiuch causes a segfault.

This is happening because there isn't a -1 in the qu array where you
expected there to be.

I don't know why *that* is happening, but I figured I'd leave something
for you to solve.

Thanks but I think I will need more help here with a full debugging.

The code was by a "genius programmer" who has gone away, his code was
superefficient but maybe the variable names were not helpful and the
documentation was minimal

What conditions do I need on atm and ctm when they get passed into ensure
no segfaults? Basically the function should be doing a kind of job queue,
I think qu=queue, wt=wait, tarnd=turn-around, wt=wait etc.

Thanks

 

[BartC]

The code was by a "genius programmer" who has gone away, his code was
superefficient but maybe the variable names were not helpful and the
documentation was minimal

What conditions do I need on atm and ctm when they get passed into ensure
no segfaults? Basically the function should be doing a kind of job queue,
I think qu=queue, wt=wait, tarnd=turn-around, wt=wait etc.

In that case just rewrite it. That will be more reliable in the long term.
And you can take the opportunity to add some comments.

But you will need a specification, or know how it fits into the bigger
picture. Those hard-coded array bounds are a bit worrying, and confusing too
with one set of arrays having a length of 11, and an upper bound of 10, and
another set having a length of 10, and an upper bound of 9...

 

[John Gordon]

What conditions do I need on atm and ctm when they get passed into ensure
no segfaults? Basically the function should be doing a kind of job queue,
I think qu=queue, wt=wait, tarnd=turn-around, wt=wait etc.

I ran a test with atm and ctm set to all -1's, and did not get a segfault.
But I have no idea if those values represent useful data.

 

[James Kuyper]

On 05/15/2012 03:27 PM, pembed2012 wrote:
....

The code was by a "genius programmer" who has gone away, his code was
superefficient but maybe the variable names were not helpful and the
documentation was minimal

Don't give the original author more credit than he deserves. A truly
professional programmer chooses variable names that are helpful, and
creates documentation that is more than minimal, and would use
appropriately named macro(s) rather than hard-coded numbers like 9, 10,
and 11. If his code is as super-efficient as you say, it's likely to be
due to an algorithm developed by someone else that he was aware of,
rather than his own original work.

You described the documentation as "minimal" rather than "non-existent".
If there is documentation, posting a copy of that documentation would
make it a lot easier for us to give you helpful responses.

 

[Kaz Kylheku]

The code was by a "genius programmer" who has gone away, his code was
superefficient but maybe the variable names were not helpful and the
documentation was minimal

If the code crashes, how do you conclude that it is superefficient?

 

[lawrence.jones]

If the code crashes, how do you conclude that it is superefficient?

It crashes really quickly without using much memory or CPU time?

 

[James Kuyper]

It crashes really quickly without using much memory or CPU time?

Keep in mind that the OP doesn't know how to correctly initialize the
input data. The function could be superefficient when used as intended,
and crash when used in a way that it was not intended to be used.