Re: gnats/133

Re: gnats/133

[Milan Zamazal]

[gnats-devel@: This is a problem with pending lock files in GNATS 3.113,
the original PR and my answer is at the end below.]

>>>>> "SP" == Sarang Padalkar <sarangp@catamarancom.com> writes:
 
    SP>  We seem to be running into the same problem frequently (once a
    SP> week).  Does anybody know what triggers this problem?

I don't and would be very interested in it.

Do you use Gnatsweb for accessing the affected databases?

    SP> Are there any known workarounds?  Is it ok for me to just delete
    SP> this file whenever I see it (being around for more than say 10
    SP> minutes)?

If Gnatsweb locks the database just for submitting the edited problem (I
don't know whether it works this way), then this should be a safe
workaround.

BTW, Yngve, you said it happens in *one* of your databases.  Is it
really so and if yes, is the database special in some aspect?

Regards,

Milan Zamazal

[The original report and my answer follows.]

>>>>> "ys" == yngve svendsen <yngve.svendsen@clustra.com> writes:

    ys> Gnats seems to forget about removing the gnats.lock file in the
    ys> gnats-adm directory. This has happened on a couple of occasions
    ys> in one of our Gnats databases. The symptoms are that people are
    ys> unable to make any edits to any of the PRs in the database, and
    ys> since it often takes some time before people report this, we
    ys> haven't been able to find out how to reproduce the problem.

I've observed a similar problem when we were using GNATS 3.113 in my
previous work.  However, I think it has never happen in the use of GNATS
3.113 in the company I work now.

I have the following hypotheses how this can happen:

- A web operation can finish for some reason (stopped browser operation
  or something like that) and the CGI script is stopped before it
  unlocks the database.  I don't know whether this can really happen,
  but it's the only explanation I had for the problems I experienced
  (the problems always happened during problem editing by some quite
  stupid users, they could do something weird).

- gnatsd crashes during Gnatsweb<->gnatsd communication.  When I was
  playing with gnatsd from GNATS 4, it stopped several times
  unexpectedly.  However, I don't know what Gnatsweb would do in such a
  case, maybe it reacts differently and this hypothesis is invalid.

Unfortunately, I don't know what to do with the lock problem, unless you
can find out more information about the problem.

Regards,

Milan Zamazal

Re: gnats/133

[Sarang Padalkar]

Please see my comments embedded below


>>>>> "M" == Milan Zamazal <pdm@zamazal.org> writes:

    M> [gnats-devel@: This is a problem with pending lock files in
    M> GNATS 3.113, the original PR and my answer is at the end
    M> below.]

>>>>> "SP" == Sarang Padalkar <sarangp@catamarancom.com> writes:
 
    SP> We seem to be running into the same problem frequently (once a
    SP> week).  Does anybody know what triggers this problem?

    M> I don't and would be very interested in it.

    M> Do you use Gnatsweb for accessing the affected databases?

Yes (2.7beta). In my case, there is always a core file (gnatsd) that
is left behind. My suspicion is that the lock file is not removed because
gnatsd crashes. 
-------------------------------------------------------------------------------
Sarang Padalkar              (sarang@catamarancom.com)             408.965.2554
Catamaran Communications                    2345 Harris Way, San Jose, CA 95131

Re: gnats/133

[Milan Zamazal]

>>>>> "SP" == Sarang Padalkar <sarangp@catamarancom.com> writes:

    SP> Yes (2.7beta). In my case, there is always a core file (gnatsd)
    SP> that is left behind. My suspicion is that the lock file is not
    SP> removed because gnatsd crashes.

This is very likely the cause of the problem!

Unfortunately, GNATS is not rock stable (applies to both 3.113 and 4).
Fortunately, most GNATS crashes are easy to spot (though not necessarily
easy to fix).  If you have got the core file and you compiled GNATS with
`-g', you can examine it in the following way:

  $ gdb /usr/local/bin/gnatsd core
  (gdb) where

This prints out the stack trace.  I'm interested in all crash traces
generated by recent GNATS CVS versions.

Milan Zamazal

-- 
http://www.zamazal.org

Re: gnats/133

[Sarang Padalkar]

>>>>> "M" == Milan Zamazal <pdm@zamazal.org> writes:

>>>>> "SP" == Sarang Padalkar <sarangp@catamarancom.com> writes:
    SP> Yes (2.7beta). In my case, there is always a core file
    SP> (gnatsd) that is left behind. My suspicion is that the lock
    SP> file is not removed because gnatsd crashes.

    M> This is very likely the cause of the problem!

    M> Unfortunately, GNATS is not rock stable (applies to both 3.113
    M> and 4).  Fortunately, most GNATS crashes are easy to spot
    M> (though not necessarily easy to fix).  If you have got the core
    M> file and you compiled GNATS with `-g', you can examine it in
    M> the following way:

    M>   $ gdb /usr/local/bin/gnatsd core (gdb) where

    M> This prints out the stack trace.  I'm interested in all crash
    M> traces generated by recent GNATS CVS versions.

I got a trace, but it turns out that the core is created by file-pr

Here is my gdb session. Let me know if I can provide any more info.

gdb /usr/local/libexec/file-pr

(gdb) core ~gnats/core
Core was generated by `file-pr -f gnatsU2aqr1 -d /home/gnats/gnats-db'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libmalloc.so.1...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libintl.so.1...warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 0x74
(no debugging symbols found)...done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...
(no debugging symbols found)...done.
#0  0xff351190 in free_unlocked ()
(gdb) where
#0  0xff351190 in free_unlocked ()
#1  0xff35105c in free ()
#2  0x1b790 in xfree ()
#3  0x15174 in check_if_reply ()
#4  0x151b4 in check_if_reply ()
#5  0x14610 in gnats ()
#6  0x13e28 in main ()

Re: gnats/133

[Milan Zamazal]

>>>>> "SP" == Sarang Padalkar <sarangp@catamarancom.com> writes:

    SP> I got a trace, but it turns out that the core is created by file-pr

    SP> Here is my gdb session. Let me know if I can provide any more info.

Thanks for the information.  Does the following patch fix it?

RE: gnats/133

[Dirk Bergstrom]

we had the same problem with 4.0a (which we've been using at juniper for the
last year or so).  there was a pernicious little bug that caused a segfault
during PR creation (unfortunately, i can't remember the exact
circumstances), and its side effect was to leave behind stale DB locks.

once i tracked it down, i had bob manson (then working at juniper) fix the
bug, and the problem went away.

here's bob's message about the fix:
-------------
2001-08-23
I believe I just checked in a fix, but at usual I haven't tested it
other than to verify that everything still builds.

There were two separate problems--one was that it wasn't regarding a
non-existent field as OK if the field didn't have a default value, and
the other was that it was trying to copy in the default value into an
invalid field even if the field didn't have a default value.

So this brings up a subtle point.  PRs can now have missing enum
fields, but only if the enum field in question doesn't have an
explicit default value.  (Otherwise, the field is added to the PR with
the default value.)  Further, it would be OK to remove an enum field
from a PR, but only if the field wasn't given a default value.  

I'm not sure if that's the right thing to do (and it's a subtle point)
but that's how it works right now.
						Bob
----------------
--
Dirk Bergstrom               dirk@juniper.net
_____________________________________________
Juniper Networks Inc.,   Engineering Web Guru
Tel: 408.745.3182           Fax: 408.745.8095
 

> -----Original Message-----
> From: Sarang Padalkar [ mailto:sarangp@catamarancom.com ]
> Sent: Monday, April 09, 2001 9:25 AM
> To: Milan Zamazal
> Cc: yngve.svendsen@clustra.com; GNATS Development
> Subject: Re: gnats/133
> 
> 
> Please see my comments embedded below
> 
> 
> >>>>> "M" == Milan Zamazal <pdm@zamazal.org> writes:
> 
>     M> [gnats-devel@: This is a problem with pending lock files in
>     M> GNATS 3.113, the original PR and my answer is at the end
>     M> below.]
> 
> >>>>> "SP" == Sarang Padalkar <sarangp@catamarancom.com> writes:
>  
>     SP> We seem to be running into the same problem frequently (once a
>     SP> week).  Does anybody know what triggers this problem?
> 
>     M> I don't and would be very interested in it.
> 
>     M> Do you use Gnatsweb for accessing the affected databases?
> 
> Yes (2.7beta). In my case, there is always a core file (gnatsd) that
> is left behind. My suspicion is that the lock file is not 
> removed because
> gnatsd crashes. 
> --------------------------------------------------------------
> -----------------
> Sarang Padalkar              (sarang@catamarancom.com)        
>      408.965.2554
> Catamaran Communications                    2345 Harris Way, 
> San Jose, CA 95131
> 
>