Re: Error Code 431

Hi Prashanth,

> I have tried what Mel had suggested me to do and i get
> a "210 PR added" message. Im
> pasting the output below:
> 200 gnatsdserver GNATS server 4.0 ready.

>   >Unformatted:
> .
> 210 PR added.
> 
> This is really confusing. If there is a problem with
> gnatsweb.pl and if its sending bogus to gnatsd that it
> cant handle, then i dont understand why there is no
> error with the test database. From this little test
> that Mel suggested i feel gnatsd shuld be ok. Any
> ideas?

Thanks for posting that output.

I'm not sure I have the details of the problem right, so I will repeat
the key things:

- When someone submits a PR via Gnatsweb the gnats.lock file in
  $GNATSROOT/database/gnats-adm is created but is not deleted.  The PR
  is created but Gnatsweb reports "Error : unparseable reply from
  server".

- This happens with all four "real" databases.

- You can create a PR in the "real" databases by using send-pr and by
  running gnatsd from the command line and entering the PR manually
  (as suggested by Mel).  In this case no error is generated and the
  gnats.lock file is deleted as expected.

- When you create a test database that does not have any categories
  except for the default ones, you can submit a PR via Gnatsweb and
  the gnats.lock file is deleted as expected.

Is the above correct?  Have I missed anything you think is important?

>From this it appears that something about your "real" configurations
is triggering a problem in the interaction between Gnatsweb and
gnatsd.  That would explain there being no error when submitting a PR
to the test database via Gnatsweb.  In other words, it is not simply a
problem with gnatsweb.pl sending the wrong thing.  The test with
running gnatsd from the command line (as Mel suggested) indicates that
gantsd can handle PR submissions for the "real" databases in some
circumstances, but apparently something is different in what Gnatsweb
does.

Some things you could try:

- Adding to the test configuration to make it like one of the "real"
  databases until the problem occurs.  I understand this is a tedious
  process, but it might be effective.

- Looking for gnatd core files.  If gnatsd is crashing, as Yngve
  suggested, then it may be leaving a core file, as Mel indicated.  I
  do not know where the core file would be created, I guess the
  directory where the gnatsd executable lives, that is
  /usr/local/libexec/gnats be default.  If there is no core file there
  you could try triggering the problem then searching the complete
  file system for core files generated in the last 10 minutes:

  find / -mmin -10 -name core -print

  The stack trace from a core file would be very useful in finding the
  cause of the problem.

-- 
Andrew J. Gray
GNU GNATS Maintainer