When creating a task via Gnatsweb, I recieve the following error: ---- Error Unparseable reply from gnatsd Thank you for your report. It will take a short while for your report to be processed. When it is, you will receive an automated message about it, containing the Problem Report number, and the developer who has been assigned to investigate the problem. ---- In my apache log: ---- [Mon Mar 14 14:00:21 2005] gnatsweb.pl: gnatsweb: unparseable gnatsd output: ; user=jcowgar, db=default; stacktrace: In: main::get_reply <= main::client_cmd <= main::submitnewpr <= main::main at /usr/lib/cgi-bin/gnatsweb.pl line 442, <SOCK> line 215., referer: http://localhost/cgi-bin/gnatsweb.pl?debug=&database=default&cmd=create ---- I use the emacs interface all day long and have no problems. This is the only information I can find about the problem. Does anyone have any ideas? I did go through and reformat quite a bit in the dbconfig to better suit our needs. Everything I did was remove items, I added no new ones, just removed those we did not need. I have been up and down the config file w/no luck in finding anything wrong. The gnatsweb edits bugs just fine, it just cannot create them. Send-pr and the emacs interface works great w/no problems. Thanks! Jeremy _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats
[-- Attachment #1.1: Type: text/plain, Size: 1147 bytes --] On Mon, Mar 14, 2005 at 02:04:38PM -0500, Jeremy Cowgar wrote: > I use the emacs interface all day long and have no problems. This is > the only information I can find about the problem. Does anyone have > any ideas? I did go through and reformat quite a bit in the dbconfig > to better suit our needs. Everything I did was remove items, I added > no new ones, just removed those we did not need. I have been up and > down the config file w/no luck in finding anything wrong. Make sure your "initial-entry" and "index" specs in dbconfig no longer contain the fields you don't need. Then, reindex the database with gen-index. I don't recall if gnatsweb requires certain fields to be present or not, but browse through the source code just to make certain. > The gnatsweb edits bugs just fine, it just cannot create them. Send-pr > and the emacs interface works great w/no problems. The emacs interface may not be making assumptions about which fields are available whereas gnatsweb may be. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats
On Mon, 2005-03-14 at 13:24 -0600, Chad Walstrom wrote: > Make sure your "initial-entry" and "index" specs in dbconfig no longer > contain the fields you don't need. Then, reindex the database with > gen-index. I don't recall if gnatsweb requires certain fields to be > present or not, but browse through the source code just to make certain. Initially, when making all the changes, we ran into problems like this, and that made me create a field mapping and ensure the removed fields no longer existed anywhere. I again verified this w/no problems found. I re-indexed to be safe as well. > The emacs interface may not be making assumptions about which fields are > available whereas gnatsweb may be. > I'm no perl programmer, but I did not see anything making me think there are fields required in gnatsweb.pl. I did, however, find some debug values that might be nice. Here is the results of the raw server reply: server_reply: 200 localhost.localdomain GNATS server 4.0 ready. server_reply: 301 List follows. server_reply: 210-Now accessing GNATS database 'default' server_reply: 210 User access level set to 'admin' server_reply: 301 List follows. server_reply: 350-Integer server_reply: 350-Enum server_reply: 350-Text server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Date server_reply: 350-Date server_reply: 350-Date server_reply: 350-Enum server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350 MultiText server_reply: 350-PR Number server_reply: 350-What area does this PR fall into? server_reply: 350-One-line summary of the PR server_reply: 350-How severe is the PR? server_reply: 350-How critical is it that the PR be fixed? server_reply: 350-The user responsible for the PR server_reply: 350-The current state of the PR server_reply: 350-Site-specific identification of the PR author server_reply: 350-Arrival date of the PR server_reply: 350-Date when the PR was closed server_reply: 350-Last modification date of the PR server_reply: 350-Release number or tag server_reply: 350-Precise description of the problem server_reply: 350-Code/input/activities to reproduce the problem server_reply: 350-How to correct or work around the problem, if known server_reply: 350- server_reply: 350-Log of specific changes to the PR server_reply: 350 Miscellaneous text that was not parsed properly server_reply: 350-readonly server_reply: 350-textsearch server_reply: 350-textsearch server_reply: 350-textsearch server_reply: 350-textsearch server_reply: 350-textsearch allowAnyValue requireChangeReason server_reply: 350-textsearch requireChangeReason server_reply: 350-textsearch server_reply: 350-readonly server_reply: 350-readonly server_reply: 350-readonly server_reply: 350-textsearch server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350 server_reply: 350--1 server_reply: 350-pending server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350-open server_reply: 350-unknown server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350-\nUnknown server_reply: 350- server_reply: 350- server_reply: 350 server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 211 Ok. server_reply: 210 PR text checked OK. server_reply: 211 Ok. server_reply: Then I changed the error message to include '---' surrounding the server reply message to see exactly what it was complaining about and here is the error message again: Error Unparseable reply from gnatsd: ------ So, it seems to me that the server is returning a blank line and gnatsweb.pl isn't liking it. I'm only guessing, as I have already said, I no perl programmer. Jeremy _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats
One reason that the reply is unparseable if it is blank is if the server dies unexpectedly. I have seen this happen with 4.0. Stuart -----Original Message----- From: help-gnats-bounces+stuart_stevens=sierralogic.com@gnu.org [mailto:help-gnats-bounces+stuart_stevens=sierralogic.com@gnu.org] On Behalf Of Jeremy Cowgar Sent: Monday, March 14, 2005 12:45 PM To: Chad Walstrom Cc: help-gnats@gnu.org Subject: Re: Gnatsweb: Unparseable reply from gnatsd On Mon, 2005-03-14 at 13:24 -0600, Chad Walstrom wrote: > Make sure your "initial-entry" and "index" specs in dbconfig no longer > contain the fields you don't need. Then, reindex the database with > gen-index. I don't recall if gnatsweb requires certain fields to be > present or not, but browse through the source code just to make certain. Initially, when making all the changes, we ran into problems like this, and that made me create a field mapping and ensure the removed fields no longer existed anywhere. I again verified this w/no problems found. I re-indexed to be safe as well. > The emacs interface may not be making assumptions about which fields are > available whereas gnatsweb may be. > I'm no perl programmer, but I did not see anything making me think there are fields required in gnatsweb.pl. I did, however, find some debug values that might be nice. Here is the results of the raw server reply: server_reply: 200 localhost.localdomain GNATS server 4.0 ready. server_reply: 301 List follows. server_reply: 210-Now accessing GNATS database 'default' server_reply: 210 User access level set to 'admin' server_reply: 301 List follows. server_reply: 350-Integer server_reply: 350-Enum server_reply: 350-Text server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Enum server_reply: 350-Date server_reply: 350-Date server_reply: 350-Date server_reply: 350-Enum server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350-MultiText server_reply: 350 MultiText server_reply: 350-PR Number server_reply: 350-What area does this PR fall into? server_reply: 350-One-line summary of the PR server_reply: 350-How severe is the PR? server_reply: 350-How critical is it that the PR be fixed? server_reply: 350-The user responsible for the PR server_reply: 350-The current state of the PR server_reply: 350-Site-specific identification of the PR author server_reply: 350-Arrival date of the PR server_reply: 350-Date when the PR was closed server_reply: 350-Last modification date of the PR server_reply: 350-Release number or tag server_reply: 350-Precise description of the problem server_reply: 350-Code/input/activities to reproduce the problem server_reply: 350-How to correct or work around the problem, if known server_reply: 350- server_reply: 350-Log of specific changes to the PR server_reply: 350 Miscellaneous text that was not parsed properly server_reply: 350-readonly server_reply: 350-textsearch server_reply: 350-textsearch server_reply: 350-textsearch server_reply: 350-textsearch server_reply: 350-textsearch allowAnyValue requireChangeReason server_reply: 350-textsearch requireChangeReason server_reply: 350-textsearch server_reply: 350-readonly server_reply: 350-readonly server_reply: 350-readonly server_reply: 350-textsearch server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350 server_reply: 350--1 server_reply: 350-pending server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350-open server_reply: 350-unknown server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350- server_reply: 350-\nUnknown server_reply: 350- server_reply: 350- server_reply: 350 server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 Valid values follow server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 301 List follows. server_reply: 211 Ok. server_reply: 210 PR text checked OK. server_reply: 211 Ok. server_reply: Then I changed the error message to include '---' surrounding the server reply message to see exactly what it was complaining about and here is the error message again: Error Unparseable reply from gnatsd: ------ So, it seems to me that the server is returning a blank line and gnatsweb.pl isn't liking it. I'm only guessing, as I have already said, I no perl programmer. Jeremy _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats
Quoting Stuart Stevens <stuart_stevens@sierralogic.com>: > One reason that the reply is unparseable if it is blank is if the server > dies unexpectedly. I have seen this happen with 4.0. Any ideas on how to tell why the server died? Jeremy Cowgar _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats
[-- Attachment #1.1: Type: text/plain, Size: 508 bytes --] On Tue, Mar 15, 2005 at 12:29:05PM -0500, Jeremy Cowgar wrote: > Quoting Stuart Stevens <stuart_stevens@sierralogic.com>: > > >One reason that the reply is unparseable if it is blank is if the server > >dies unexpectedly. I have seen this happen with 4.0. > > Any ideas on how to tell why the server died? Compile with debugging symbols and save the coredump? -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats
[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --] On Tue, Mar 15, 2005 at 11:34:52AM -0600, Chad Walstrom wrote: > Compile with debugging symbols and save the coredump? Some of the recent compiles of 4.0 had been problematic when compiled with optimizations. I believe it had something to do with the libiberty handling of memcpy and other wrapper functions. Libiberty has been removed in 4.1.0, which consequently is considered the new "stable" platform. Rather than spending a lot of time debugging 4.0, I would suggest upgrading if possible. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats