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

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

Segmentation Fault

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

Contents

  Segmentation Fault pembed2012 <once@was.enough.invalid> - 2012-05-14 16:45 +0000
    Re: Segmentation Fault John Gordon <gordon@panix.com> - 2012-05-14 17:00 +0000
      Re: Segmentation Fault Keith Thompson <kst-u@mib.org> - 2012-05-14 13:44 -0700
        Re: Segmentation Fault Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-05-14 21:07 +0000
          Re: Segmentation Fault John Gordon <gordon@panix.com> - 2012-05-14 21:10 +0000
    Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-14 13:25 -0400
      Re: Segmentation Fault pembed2012 <once@was.enough.invalid> - 2012-05-14 21:00 +0000
        Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-14 17:21 -0400
        Re: Segmentation Fault John Gordon <gordon@panix.com> - 2012-05-14 21:24 +0000
          Re: Segmentation Fault John Gordon <gordon@panix.com> - 2012-05-14 21:35 +0000
          Re: Segmentation Fault pembed2012 <once@was.enough.invalid> - 2012-05-15 19:27 +0000
            Re: Segmentation Fault "BartC" <bc@freeuk.com> - 2012-05-15 20:38 +0100
              Re: Segmentation Fault pembed2012 <once@was.enough.invalid> - 2012-05-16 19:56 +0000
                Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-16 16:17 -0400
                Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-16 16:17 -0400
            Re: Segmentation Fault John Gordon <gordon@panix.com> - 2012-05-15 19:56 +0000
            Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-15 15:58 -0400
              Re: Segmentation Fault Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-18 01:02 +0000
            Re: Segmentation Fault Kaz Kylheku <kaz@kylheku.com> - 2012-05-15 20:10 +0000
              Re: Segmentation Fault lawrence.jones@siemens.com - 2012-05-15 17:43 -0400
                Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-15 18:27 -0400
              Re: Segmentation Fault gordonb.dxbbb@burditt.org (Gordon Burditt) - 2012-05-19 02:37 -0500
    Re: Segmentation Fault "BartC" <bc@freeuk.com> - 2012-05-14 22:17 +0100
    Re: Segmentation Fault Fred K <fred.l.kleinschmidt@gmail.com> - 2012-05-14 10:02 -0700
    Re: Segmentation Fault Fred K <fred.l.kleinschmidt@gmail.com> - 2012-05-14 11:33 -0700
    Re: Segmentation Fault Ike Naar <ike@sverige.freeshell.org> - 2012-05-16 20:17 +0000
      Re: Segmentation Fault nick_keighley_nospam@hotmail.com - 2012-05-17 03:05 -0700
        Re: Segmentation Fault Ike Naar <ike@iceland.freeshell.org> - 2012-05-17 11:07 +0000
      Re: Segmentation Fault pembed2012 <once@was.enough.invalid> - 2012-05-17 19:50 +0000
        Re: Segmentation Fault James Kuyper <jameskuyper@verizon.net> - 2012-05-17 16:59 -0400
        Re: Segmentation Fault Ike Naar <ike@sverige.freeshell.org> - 2012-05-18 07:22 +0000

Page 1 of 2  [1] 2  Next page →

#20704 — Segmentation Fault

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

[toc] | [next] | [standalone]

#20707

In <jorcqt$72h$1@speranza.aioe.org> pembed2012 <once@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
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#20718

John Gordon <gordon@panix.com> writes:
> In <jorcqt$72h$1@speranza.aioe.org> pembed2012 <once@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) kst-u@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"

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

#20723

Keith Thompson wrote:

> John Gordon <gordon@panix.com> writes:
>> In <jorcqt$72h$1@speranza.aioe.org> pembed2012
>> <once@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

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

#20724

In <jors6a$ind$1@speranza.aioe.org> Edward Rutherford <edward.p.rutherford79@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.

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

#20710

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.

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

#20719

On Mon, 14 May 2012 13:25:58 -0400, James Kuyper wrote:

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

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

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

#20726

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.

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

#20727

In <jorrpp$hrp$1@speranza.aioe.org> pembed2012 <once@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                   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]

#20728

In <jort5t$cuo$1@reader1.panix.com> John Gordon <gordon@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.

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

#20813

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

> In <jorrpp$hrp$1@speranza.aioe.org> pembed2012 <once@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

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

#20814

"pembed2012" <once@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 

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

#20862

On Tue, 15 May 2012 20:38:05 +0100, BartC wrote:

> "pembed2012" <once@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...

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.

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

#20863

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.

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

#20865

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.

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

#20815

In <jouanj$jhq$1@speranza.aioe.org> pembed2012 <once@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.

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

#20816

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.

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

#20964

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   .

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

#20820

On 2012-05-15, pembed2012 <once@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?

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

#20832

Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2012-05-15, pembed2012 <once@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?  :-)
-- 
Larry Jones

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web