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[i] = 0;
tarnd[i] = 0;
}
qu[0] = 0;
qu[1] = -1;
int size = 1;
i = 0;
while(qu[i] != -1)
{
ctm[qu[i]]--;
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[i]]++;
if(ctm[qu[i]] == 0);
atm[qu[i]] = -1;
for(j = 0; j < size; j++)
if(atm[qu[j]] != -1)
if(ctm[qu[j]] < ctm[qu[i]])
i = j;
}
for(i = 0; i < 10; i++)
tarnd[i] += wt[i];
for(i = 0; i < 10; i++)
{
wt[10] += wt[i];
tarnd[10] += tarnd[i];
}
wt[10] = wt[10] / 10;
tarnd[10] = tarnd[10] / 10;

print_report (wt, tarnd);
}

[John Gordon]

In <jorcqt$72h$1...@speranza.aioe.org> pembed2012 <on...@was.enough.invalid> writes:

> 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");

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

[Fred K]

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

[James Kuyper]

On 05/14/2012 12:45 PM, pembed2012 wrote:
> 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]

On Monday, May 14, 2012 9:45:17 AM UTC-7, pembed2012 wrote:

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[i]]++;
> if(ctm[qu[i]] == 0);
> atm[qu[i]] = -1;
> for(j = 0; j < size; j++)
> if(atm[qu[j]] != -1)
> if(ctm[qu[j]] < ctm[qu[i]])
> 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 ?)

[Keith Thompson]

John Gordon <gor...@panix.com> writes:
> In <jorcqt$72h$1...@speranza.aioe.org> pembed2012 <on...@was.enough.invalid> writes:
>> 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");

And it couldn't hurt to add

fflush(stdout);

as well.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pembed2012]

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]

Keith Thompson wrote:

> John Gordon <gor...@panix.com> writes:
>> In <jorcqt$72h$1...@speranza.aioe.org> pembed2012
>> <on...@was.enough.invalid> writes:
>>> 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");
>
> 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]

In <jors6a$ind$1...@speranza.aioe.org> Edward Rutherford <edward.p.r...@REMOVETHIS.gmail.com> writes:

> 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]

"pembed2012" <on...@was.enough.invalid> wrote in message
news:jorcqt$72h$1...@speranza.aioe.org...

> 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.

--
Bartc

[James Kuyper]

On 05/14/2012 05:00 PM, pembed2012 wrote:
> On Mon, 14 May 2012 13:25:58 -0400, James Kuyper wrote:

...

>> 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.

> 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]

In <jorrpp$hrp$1...@speranza.aioe.org> pembed2012 <on...@was.enough.invalid> writes:

> 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]

In <jort5t$cuo$1...@reader1.panix.com> John Gordon <gor...@panix.com> writes:

> 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]

On Mon, 14 May 2012 21:24:14 +0000, John Gordon wrote:

> In <jorrpp$hrp$1...@speranza.aioe.org> pembed2012 <on...@was.enough.invalid>
> writes:
>
>> 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]

"pembed2012" <on...@was.enough.invalid> wrote in message

news:jouanj$jhq$1...@speranza.aioe.org...

> 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...

--
Bartc

[John Gordon]

In <jouanj$jhq$1...@speranza.aioe.org> pembed2012 <on...@was.enough.invalid> writes:

> 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]

On 2012-05-15, pembed2012 <on...@was.enough.invalid> 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 :-)

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

[lawrenc...@siemens.com]

It crashes really quickly without using much memory or CPU time? :-)
--
Larry Jones

I like maxims that don't encourage behavior modification. -- Calvin

[James Kuyper]

On 05/15/2012 05:43 PM, lawrenc...@siemens.com wrote:
> Kaz Kylheku <k...@kylheku.com> wrote:
>> On 2012-05-15, pembed2012 <on...@was.enough.invalid> 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 :-)
>>
>> If the code crashes, how do you conclude that it is superefficient?
>
> 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.

[pembed2012]

I will do this if someone can explain me in simple terms what this
function is doing. The documentation just say it implements a work queue,
11 is the max wait.

Also John Gordon is correct that -1 is considered a sentinal value.
However I would like to know exactly what input arrays are acceptable and
lead to no segfault.

Thanks for you're interest.

[James Kuyper]

On 05/16/2012 03:56 PM, pembed2012 wrote:
...
> I will do this if someone can explain me in simple terms what this
> function is doing. The documentation just say it implements a work queue,
> 11 is the max wait.

You're asking in the wrong place. To get that explanation, you need to
contact someone familiar with this particular function. The person who
wrote the latest version of that function would be best. However, if you
can't reach such a person, then look for somebody who's written code
that calls the routine.

If you replaced the body of the function with { return;}, who would know
that it wasn't working properly? If there's no one who would know, then
you might as well perform the replacement - at least it doesn't
segfault. If there is someone who can tell you that such a replacement
wasn't working properly, that person can also tell you something
important about what "working properly" means for this particular
function. Find that person and ask.

[Ike Naar]

On 2012-05-14, pembed2012 <on...@was.enough.invalid> wrote:
> if(ctm[qu[i]] == 0);

This statement is redundant (it's an if statement with an
empty body). Elsethread, you say that the code was written
by a "genius programmer" and is super efficient.
Including a redundant statement is not what one would
expect from such a programmer. Is the code that you posted
the real, unmodified code?

[James Kuyper]

On 05/16/2012 03:56 PM, pembed2012 wrote:
...

> I will do this if someone can explain me in simple terms what this
> function is doing. The documentation just say it implements a work queue,
> 11 is the max wait.

[nick_keigh...@hotmail.com]

people sometimes mistake "hard to understand and sort of works" for "genius". I used to think every project needed a "hacker" who could produce write-only code astonishingly quickly. If you changed the requirement (or insisted on robustness or deterministic behaviour or something) then he'd throw all his code away and write a new version from scratch, astonishingly quickly.

Then a Real programmer has to take this... stuff ...and turn it into a usable library.

[Ike Naar]

The if statement quoted above has an un-hacker-ish smell.
It's not tricky; it's a plain no-op; it wastes cpu time; hackers hate that.
On the other hand it looks very much like an editing error.
That's why I asked if pembed2012 posted the real, unmodified code.

[pembed2012]

The only thing I can think of is, maybe the condition is being evaluated
for its side effects.

Of course it may be a bug. How does the behavior of the code change if
you delete the ; ?

I don't feel like I've had a clear answer yet about what this function is
doing and how it works!

[James Kuyper]

On 05/17/2012 03:50 PM, pembed2012 wrote:
> On Wed, 16 May 2012 20:17:22 +0000, Ike Naar wrote:
>
>> On 2012-05-14, pembed2012 <on...@was.enough.invalid> wrote:
>>> if(ctm[qu[i]] == 0);
>>
>> This statement is redundant (it's an if statement with an empty body).
>> Elsethread, you say that the code was written by a "genius programmer"
>> and is super efficient. Including a redundant statement is not what one
>> would expect from such a programmer. Is the code that you posted the
>> real, unmodified code?
>
> The only thing I can think of is, maybe the condition is being evaluated
> for its side effects.

Side effects can only result from ++, --, assignment expressions,
certain function calls, or accessing a volatile object. None of those
things happen in this code, so that can't be the reason.

> Of course it may be a bug. How does the behavior of the code change if
> you delete the ; ?

In the original code, it said:

if(ctm[qu[i]] == 0);

atm[qu[i]] = -1;

That's exactly equivalent to

atm[qu[i]] = -1;

Removing the semicolon would change the code so that it was equivalent to

if(ctm[qu[i]] == 0)

{

atm[qu[i]] = -1;
}

which is very different.

> I don't feel like I've had a clear answer yet about what this function is
> doing and how it works!

You haven't, because you've been asking the wrong people. Is there
anyone who's ever written code that uses this function that you can talk to?

[Jorgen Grahn]

On Tue, 2012-05-15, James Kuyper wrote:
> 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.

Agree. A hack who spends months and a lot of effort solving a fairly
easy problem in a complicated way, can to the untrained eye look much
like a genius hacker solving a difficult problem in an acceptable way.

> 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.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ike Naar]

On 2012-05-17, pembed2012 <on...@was.enough.invalid> wrote:
> I don't feel like I've had a clear answer yet about what this function is
> doing and how it works!

I would guess that:
- it's a job scheduler using the "shortest remaining time next" algorithm,
- the input arrays atm and ctm are arrival times and completion times
- the code, as posted, has never worked

If you expect people to spend time to help you, it would be nice if you'd
share all information that you have.
So far, you seem to have been reluctant to do so.

Can you show an example of a call to srtn() ?
Can you post the body of print_report ?
Is the code, as posted, the original code, or have you made
modifications ?

[Gordon Burditt]

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

If the code does not have to work correctly, it can be done in 0 machine
cycles with 0 bytes.