cvs-nserver-devel

pserver ends with SEGV during checkout

[Michael K. <ka...@fi...>]

Hi.

$ gdb -c core.pserver /usr/local/cvs-nserver/bin/cvs

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
Core was generated by `/usr/local/cvs-nserver/bin/cvs pserver'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x400dd17d in chunk_free () from /lib/libc.so.6
(gdb) bt
#0  0x400dd17d in chunk_free () from /lib/libc.so.6
#1  0x400dd064 in free () from /lib/libc.so.6
#2  0x805970d in Entnode_Destroy (ent=0x820e7b8) at entries.c:74
#3  0x805a2a5 in Entries_delproc (node=0x81b4c38) at entries.c:598
#4  0x805f217 in freenode_mem (p=0x81b4c38) at hash.c:188
#5  0x805f273 in freenode (p=0x81b4c38) at hash.c:210
#6  0x805f1ee in delnode (p=0x81b4c38) at hash.c:177
#7  0x805f0f4 in dellist (listp=0xbffff434) at hash.c:93
#8  0x805a284 in Entries_Close (list=0x80eb310) at entries.c:582
#9  0x8080e32 in do_recursion (frame=0xbffff4f4) at recurse.c:768
#10 0x808162b in do_dir_proc (p=0x80ec678, closure=0xbffff590)
    at recurse.c:1091
#11 0x805f4fd in walklist (list=0x80ebac8, proc=0x8081000 <do_dir_proc>, 
    closure=0xbffff590) at hash.c:370
#12 0x8080e0c in do_recursion (frame=0xbffff614) at recurse.c:758
#13 0x808162b in do_dir_proc (p=0x80da800, closure=0xbffff6b0)
    at recurse.c:1091
#14 0x805f4fd in walklist (list=0x80eb008, proc=0x8081000 <do_dir_proc>, 
    closure=0xbffff6b0) at hash.c:370
#15 0x8080e0c in do_recursion (frame=0xbffff744) at recurse.c:758
#16 0x8080901 in start_recursion (fileproc=0x80908c0 <update_fileproc>, 
    filesdoneproc=0x8090e40 <update_filesdone_proc>, 
    direntproc=0x8090f40 <update_dirent_proc>, 
    dirleaveproc=0x80912d0 <update_dirleave_proc>, callerdat=0x0, argc=0, 
    argv=0x80da648, local=0, which=3, aflag=0, readlock=1, 
    update_preload=0x80dac58 "cvs-nserver", dosrcs=1) at recurse.c:355
#17 0x809088a in do_update (argc=0, argv=0x0, xoptions=0x0, xtag=0x0, 
    xdate=0x0, xforce=1, local=0, xbuild=1, xaflag=0, xprune=0, xpipeout=0, 
    which=3, xjoin_rev1=0x0, xjoin_rev2=0x0, 
    preload_update_dir=0x80dac58 "cvs-nserver", xdotemplate=1) at update.c:515
#18 0x8051e35 in checkout_proc (argc=1, argv=0x80daff0, where_orig=0x0, 
    mwhere=0x0, mfile=0x0, shorten=0, local_specified=0, 
    omodule=0x80daae8 "cvs-nserver", msg=0x80b5417 "Updating")
    at checkout.c:1075
#19 0x806f273 in do_module (db=0x80da7b8, mname=0x80daae8 "cvs-nserver", 
    m_type=CHECKOUT, msg=0x80b5417 "Updating", 
    callback_proc=0x8050e10 <checkout_proc>, where=0x0, shorten=0, 
    local_specified=0, run_module_prog=1, build_dirs=1, extra_arg=0x0)
    at modules.c:299
#20 0x8050b82 in checkout (argc=1, argv=0x80da630) at checkout.c:373
#21 0x8088925 in do_cvs_command (cmd_name=0x80cb599 "checkout", 
    command=0x8050450 <checkout>) at server.c:2782
#22 0x808a462 in serve_co (arg=0x80daafa "") at server.c:3738
#23 0x808c12f in server (argc=1, argv=0xbffffc78) at server.c:5104
#24 0x806dab7 in main (argc=1, argv=0xbffffc78) at main.c:1122
#25 0x40085c6f in __libc_start_main () from /lib/libc.so.6
(gdb) 

$ uname -rs
Linux 2.2.19

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
gcc version 2.95.3 20010315 (SuSE)

$ rpm -q glibc
glibc-2.2.2-38

-- 
WBR, Michael Kazakov.

Re: pserver ends with SEGV during checkout

[Alexey M. <mo...@no...>]

=F7 =F7=D3=CB, 14.04.2002, =D7 18:34, Michael Kazakov wrote:
Hmm, could you tell how did you try to start the server when it
sigsegv'ed. I suspect, you tried to run it with totally wrong arguments.
Could you tell the [x]inetd line etc etc etc?...

I also noticed that you're using 'cvs' w/ core file from cvs-pserver
:-).

BTW, in the attachment you may find a [hopefully] correct example (at
least it works for me:-)) how to set up an ncvs-pserver in xinetd
environment. inetd line should be constructed in similar way :-).=20

In a really near future (hopefully a day or two) I will provide a set of
tools for creating repositories, starting projects etc... In fact
there's a draft of doc (in texinfo) :-)).

And finally, Alex will fix cvs-admin-guide.texi so we'll have a proper
and much more accurate documentation :-)

> $ gdb -c core.pserver /usr/local/cvs-nserver/bin/cvs
>=20
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you =
are
> welcome to change it and/or distribute copies of it under certain conditi=
ons.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for detail=
s.
> This GDB was configured as "i386-suse-linux"...
> Core was generated by `/usr/local/cvs-nserver/bin/cvs pserver'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libcrypt.so.1...done.
> Loaded symbols for /lib/libcrypt.so.1
> Reading symbols from /lib/libz.so.1...done.
> Loaded symbols for /lib/libz.so.1
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0  0x400dd17d in chunk_free () from /lib/libc.so.6
> (gdb) bt
> #0  0x400dd17d in chunk_free () from /lib/libc.so.6
> #1  0x400dd064 in free () from /lib/libc.so.6
> #2  0x805970d in Entnode_Destroy (ent=3D0x820e7b8) at entries.c:74
> #3  0x805a2a5 in Entries_delproc (node=3D0x81b4c38) at entries.c:598
> #4  0x805f217 in freenode_mem (p=3D0x81b4c38) at hash.c:188
> #5  0x805f273 in freenode (p=3D0x81b4c38) at hash.c:210
> #6  0x805f1ee in delnode (p=3D0x81b4c38) at hash.c:177
> #7  0x805f0f4 in dellist (listp=3D0xbffff434) at hash.c:93
> #8  0x805a284 in Entries_Close (list=3D0x80eb310) at entries.c:582
> #9  0x8080e32 in do_recursion (frame=3D0xbffff4f4) at recurse.c:768
> #10 0x808162b in do_dir_proc (p=3D0x80ec678, closure=3D0xbffff590)
>     at recurse.c:1091
> #11 0x805f4fd in walklist (list=3D0x80ebac8, proc=3D0x8081000 <do_dir_pro=
c>,=20
>     closure=3D0xbffff590) at hash.c:370
> #12 0x8080e0c in do_recursion (frame=3D0xbffff614) at recurse.c:758
> #13 0x808162b in do_dir_proc (p=3D0x80da800, closure=3D0xbffff6b0)
>     at recurse.c:1091
> #14 0x805f4fd in walklist (list=3D0x80eb008, proc=3D0x8081000 <do_dir_pro=
c>,=20
>     closure=3D0xbffff6b0) at hash.c:370
> #15 0x8080e0c in do_recursion (frame=3D0xbffff744) at recurse.c:758
> #16 0x8080901 in start_recursion (fileproc=3D0x80908c0 <update_fileproc>,=
=20
>     filesdoneproc=3D0x8090e40 <update_filesdone_proc>,=20
>     direntproc=3D0x8090f40 <update_dirent_proc>,=20
>     dirleaveproc=3D0x80912d0 <update_dirleave_proc>, callerdat=3D0x0, arg=
c=3D0,=20
>     argv=3D0x80da648, local=3D0, which=3D3, aflag=3D0, readlock=3D1,=20
>     update_preload=3D0x80dac58 "cvs-nserver", dosrcs=3D1) at recurse.c:35=
5
> #17 0x809088a in do_update (argc=3D0, argv=3D0x0, xoptions=3D0x0, xtag=3D=
0x0,=20
>     xdate=3D0x0, xforce=3D1, local=3D0, xbuild=3D1, xaflag=3D0, xprune=3D=
0, xpipeout=3D0,=20
>     which=3D3, xjoin_rev1=3D0x0, xjoin_rev2=3D0x0,=20
>     preload_update_dir=3D0x80dac58 "cvs-nserver", xdotemplate=3D1) at upd=
ate.c:515
> #18 0x8051e35 in checkout_proc (argc=3D1, argv=3D0x80daff0, where_orig=3D=
0x0,=20
>     mwhere=3D0x0, mfile=3D0x0, shorten=3D0, local_specified=3D0,=20
>     omodule=3D0x80daae8 "cvs-nserver", msg=3D0x80b5417 "Updating")
>     at checkout.c:1075
> #19 0x806f273 in do_module (db=3D0x80da7b8, mname=3D0x80daae8 "cvs-nserve=
r",=20
>     m_type=3DCHECKOUT, msg=3D0x80b5417 "Updating",=20
>     callback_proc=3D0x8050e10 <checkout_proc>, where=3D0x0, shorten=3D0,=20
>     local_specified=3D0, run_module_prog=3D1, build_dirs=3D1, extra_arg=
=3D0x0)
>     at modules.c:299
> #20 0x8050b82 in checkout (argc=3D1, argv=3D0x80da630) at checkout.c:373
> #21 0x8088925 in do_cvs_command (cmd_name=3D0x80cb599 "checkout",=20
>     command=3D0x8050450 <checkout>) at server.c:2782
> #22 0x808a462 in serve_co (arg=3D0x80daafa "") at server.c:3738
> #23 0x808c12f in server (argc=3D1, argv=3D0xbffffc78) at server.c:5104
> #24 0x806dab7 in main (argc=3D1, argv=3D0xbffffc78) at main.c:1122
> #25 0x40085c6f in __libc_start_main () from /lib/libc.so.6
> (gdb)=20
>=20
> $ uname -rs
> Linux 2.2.19
>=20
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
> gcc version 2.95.3 20010315 (SuSE)
>=20
> $ rpm -q glibc
> glibc-2.2.2-38
>=20
> --=20
> WBR, Michael Kazakov.
>=20
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> https://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel

Re: pserver ends with SEGV during checkout

[Michael K. <ka...@fi...>]

Hi.

>>>>> Alexey Morozov <mo...@no...> writes:

 AM> =F7 =F7=D3=CB, 14.04.2002, =D7 18:34, Michael Kazakov wrote: Hmm, co=
uld you
 AM> tell how did you try to start the server when it sigsegv'ed. I
 AM> suspect, you tried to run it with totally wrong arguments.  Could
 AM> you tell the [x]inetd line etc etc etc?...

$ grep pserver /etc/inetd.conf

2401  stream  tcp  nowait  root /usr/local/cvs-nserver/bin/repos1pserver =
cvs-pserver

$ cat /usr/local/cvs-nserver/bin/repos1pserver=20

#!/bin/sh
ulimit -c unlimited
CVSPASSWD=3D/usr/local/cvs-nserver/bin/cvspasswd \
exec /usr/local/cvs-nserver/bin/cvs-pserver /home/Kazakov/heap/CVSROOT --=
 \
/usr/local/cvs-nserver/bin/cvschkpw /usr/local/cvs-nserver/bin/cvs pserve=
r

$ ls -l /home/Kazakov/heap/CVSROOT
=C9=D4=CF=C7=CF 3
drwxrwsr-x   17 cvsadmin cvs          1471 =E1=D0=D2 10 18:51 cvs-nserver
drwxr-xr-x    3 cvsadmin cvsadmin      973 =E1=D0=D2 10 17:46 CVSROOT

$ sudo find /tmp/cvs-serv19280/ -name core -ls
Password:
  6065 2135 -rw-------   1 cvsadmin cvsadmin  2723840 =E1=D0=D2 10 18:51 =
/tmp/cvs-serv19280/cvs-nserver/windows-NT/core

With this settings I tried import and checkout from directory what contai=
ns
cvs-nserver. At first time it falls with SIGSEGV, but second try ends
successfully.

--=20
WBR, Michael Kazakov.

gnu m4

[Alberto D. <al...@ur...>]

Hello, I'm doing some work to make cvs-nserver full OpenBSD
compliant :-)

Basically there are three things to do to successfully build
cvs-nserver on OpenBSD:

1) Cut out the line below from src/server.c :
#define _POSIX_SOURCE 1

(server.c includes <sys/socket.h> which has some non posix
declarations, and also uses FD_SETSIZE which is declared
in sys/types.h only when _POSIX_SOURCE is not declared)


2) Install gnu-m4 which is not supported by OpenBSD (gnu m4
is not even present in to the ports tree of release 3.0).
It seems that OpenBSD's m4 can substitute gnu m4 in almost every
situation , but the following autoconf rule which checks
for gnu m4 fails:

AC_PROG_GNU_M4

(it fails checking for frozen files support)

3) Compile with GNU Make.


Now, point (1) is a suggestion to patch source code.
Point (3) is no problem. About point (2) is not clear to me if the
AC_PROG_GNU_M4 rule was inserted in configure.in by some automatic tool
like autoscan or was manually inserted by cvs-nserver coders , and why it
was inserted.
Do you think it is strictly needed ?


Also in the next days I hope to send you patches to integrate
OpenBSD changes made to cvs into cvs-nserver.
Actually I have made a single patch yet and I tested it. But I want to
separate it in single patches for each bugfix/feature made by
the OpenBSD team, before submitting them to you.

Greets,
					Alberto.

-------------------------------------------------------------------
Alberto Dainotti
URIZEN - Internetworking & Digital Security
al...@ur...
http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5
-------------------------------------------------------------------

Re: gnu m4

[Alexey M. <al...@hs...>]

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Hello, I'm doing some work to make cvs-nserver full OpenBSD compliant
 AD> :-)

It's nice to hear! 

 AD> Basically there are three things to do to successfully build
 AD> cvs-nserver on OpenBSD:

 AD> 1) Cut out the line below from src/server.c : #define _POSIX_SOURCE 1

Ok, this whole idea with _*_SOURCE was not that brilliant.  Removed. 

 AD> (server.c includes <sys/socket.h> which has some non posix
 AD> declarations, and also uses FD_SETSIZE which is declared in
 AD> sys/types.h only when _POSIX_SOURCE is not declared)

Actually, I think that eventually those headers and the appropriate code
would be removed from cvs-nserver altogether, and moved to one of the
*-client.c (hopefully more cleanly).

Also, I don't think that FD_SETSIZE usage is that critical.  I think it
could be removed too (select() will return appropriate error, if this
number is too high for it).

But that's orthogonal to a current question. 



 AD> 2) Install gnu-m4 which is not supported by OpenBSD (gnu m4 is not
 AD> even present in to the ports tree of release 3.0).  It seems that
 AD> OpenBSD's m4 can substitute gnu m4 in almost every situation , but the
 AD> following autoconf rule which checks for gnu m4 fails:

 AD> AC_PROG_GNU_M4

 AD> (it fails checking for frozen files support)

I believe that this should be directed towards Autoconf guys.  Could you
please write a message to aut...@gn... with the description of failure?
We'll catch up when the corresponding Autoconf release will be out. 


 AD> 3) Compile with GNU Make.

I believe that *BSD people are already used to type 'gmake' right after
'./configure' :) 


 AD> Now, point (1) is a suggestion to patch source code.  Point (3) is no
 AD> problem. About point (2) is not clear to me if the AC_PROG_GNU_M4 rule
 AD> was inserted in configure.in by some automatic tool like autoscan or
 AD> was manually inserted by cvs-nserver coders , and why it was inserted.
 AD> Do you think it is strictly needed ?

I think that it is needed for the Autotest stuff.  I've looked at the
M4-related stuff in configure.in, and I think I'll try to remove it and see
if it's still works.  I think that's remnants from the days of Autoconf
2.52 betas.


 AD> Also in the next days I hope to send you patches to integrate OpenBSD
 AD> changes made to cvs into cvs-nserver.  Actually I have made a single
 AD> patch yet and I tested it. But I want to separate it in single patches
 AD> for each bugfix/feature made by the OpenBSD team, before submitting
 AD> them to you.

Wonderful!  Btw, why don't you simply submit those patches to a stock CVS?
That way we'll catch them up automatically on next CVS release.  Although,
sure, if you think that those patches are needed for nserver -- I agree.


Thanks, 

--alexm

Re: gnu m4

[Alberto D. <al...@ur...>]

On Wed, 17 Apr 2002, Alexey Mahotkin wrote:

>  AD> Also in the next days I hope to send you patches to integrate OpenBSD
>  AD> changes made to cvs into cvs-nserver.  Actually I have made a single
>  AD> patch yet and I tested it. But I want to separate it in single patches
>  AD> for each bugfix/feature made by the OpenBSD team, before submitting
>  AD> them to you.
>
> Wonderful!  Btw, why don't you simply submit those patches to a stock CVS?
> That way we'll catch them up automatically on next CVS release.  Although,
> sure, if you think that those patches are needed for nserver -- I agree.

My impression is that cvs development is too slow, and that they
are reclutant to add patches/improvements. Wasn't this one of the
reasons the cvs-nserver project was started ?
For example look at:
http://www.cvshome.org/cyclic/cvs/dev-keywords.txt
The improvement to add an optional custom "Id"-like RCS identifier
was proposed years ago. It is used by *BSD guys since years.
Right in the link above you can read that development team judged
it a good thing, but nothing has been done.
Also I'm not the original author of these improvements, and my guess
is that patches have been sent to cvs/Cyclic by OpenBSD team , as this is
the usual behaviour when making ports.
I like the idea of cvs-nserver, and I think it can be improved and
may be it could be distributed with OpenBSD in the future. The
network code rewriting and the ssl support could be two major points
for it to be approved by OpenBSD [note that I'm not currently connected
in any way to the OpenBSD team, so these are my guesses] .

Greets,
					Alberto.


-------------------------------------------------------------------
Alberto Dainotti
URIZEN - Internetworking & Digital Security
al...@ur...
http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5
-------------------------------------------------------------------

OpenBSD patches

[Alberto D. <al...@ur...>]

Here are the patches taken from modifications of OpenBSD team to cvs.
All code was taken from OpenBSD except for two lines of code that I
added to make the new "-t" option work also in pserver mode.

Explantions follow:

fixes.patch:            Minor fixes/improvements

localid.patch:          This patch allows to specify a custom RCS
			identifier string to be used like the "Id"
			identifier.
                        It can be specified by command line on
			checkout/update/export or in CVSROOT/config file.
                        The explanation in the new manpage is:

------------------------------------------------------------------------------
-t id  Expand  the RCS identifier specified by the id argument in addi-
       tion to the default ``Id'' identifier.  -t is available with the
       checkout,  export,  and update commands.  If the identifier name
       is  specified  as  ``-'',  no  additional  identifiers  will be
       expanded.
------------------------------------------------------------------------------

readonly.patch:         Allows to set the cvs repository as readonly using
			the new "-R" global option.

newhostname.patch:      permit [] hostname formats in CVSROOT, for IPv6.

config.patch:           Allows to force cvs umask and resource limits from
                        CVSROOT/config file.


Bye,
						Alberto.

-------------------------------------------------------------------
Alberto Dainotti
URIZEN - Internetworking & Digital Security
al...@ur...
http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5
-------------------------------------------------------------------

Re: OpenBSD patches

[Alexey M. <al...@hs...>]

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Here are the patches taken from modifications of OpenBSD team to cvs.
 AD> All code was taken from OpenBSD except for two lines of code that I
 AD> added to make the new "-t" option work also in pserver mode.

Thanks!

I think I'll commit most (or all) of it rather soon (somewhere in the
beginning of May).

 AD> Explantions follow:

 AD> fixes.patch: Minor fixes/improvements

"16" vs "16+1" is ultra-cool. :)

--alexm

Re: pserver ends with SEGV during checkout

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

 AM> В Вск, 14.04.2002, в 18:34, Michael Kazakov wrote: Hmm, could you tell
 AM> how did you try to start the server when it sigsegv'ed. I suspect, you
 AM> tried to run it with totally wrong arguments.  Could you tell the
 AM> [x]inetd line etc etc etc?...

 AM> I also noticed that you're using 'cvs' w/ core file from cvs-pserver
 AM> :-).

No, that's ok: 

 >> This GDB was configured as "i386-suse-linux"...  Core was generated by
 >> `/usr/local/cvs-nserver/bin/cvs pserver'.


Given that the segfault is in free(), I don't think that would be easy to
debug remotely...

I'll try to re-run the test...

--alexm

Re: pserver ends with SEGV during checkout

[Alexey M. <mo...@no...>]

=F7 =F0=CE=C4, 15.04.2002, =D7 01:54, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
>=20
> No, that's ok:=20
>=20
>  >> This GDB was configured as "i386-suse-linux"...  Core was generated b=
y
>  >> `/usr/local/cvs-nserver/bin/cvs pserver'.
Oh, that's my fault...
>=20

> Given that the segfault is in free(), I don't think that would be easy to
> debug remotely...
Hmm, well we really need the proper logging facility.
BTW, Alex, did you consider smth I call multilevel logging as it's done
in repcheck utility? I.e. when server logs every little step it does but
w/ different logging level. At first look there could be 'fatal',
'security', 'normal', 'debug' levels and there would be a filter that
specify how much information should go into logs. I think this would
ease the
setup, maintaince and incidents recovery processes.

> I'll try to re-run the test...
Hmm... I also will, as soon as I complete maintainance utilities...

Re: pserver ends with SEGV during checkout

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

 >> Given that the segfault is in free(), I don't think that would be easy
 >> to debug remotely...
 AM> Hmm, well we really need the proper logging facility.  BTW, Alex, did
 AM> you consider smth I call multilevel logging as it's done in repcheck
 AM> utility? I.e. when server logs every little step it does but w/
 AM> different logging level. At first look there could be 'fatal',
 AM> 'security', 'normal', 'debug' levels and there would be a filter that
 AM> specify how much information should go into logs. I think this would
 AM> ease the setup, maintaince and incidents recovery processes.

Maybe simply add GreatCircle Talkback support, a-la Netscape/Mozilla? ;) 

 >> I'll try to re-run the test...
 AM> Hmm... I also will, as soon as I complete maintainance utilities...

--alexm

Re: pserver ends with SEGV during checkout

[Alexey M. <mo...@no...>]

=F7 =F3=C2=D4, 20.04.2002, =D7 22:45, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
>  AM> 'security', 'normal', 'debug' levels and there would be a filter tha=
t
>  AM> specify how much information should go into logs. I think this would
>  AM> ease the setup, maintaince and incidents recovery processes.
> Maybe simply add GreatCircle Talkback support, a-la Netscape/Mozilla? ;)=20
"Who's the f**king Alice?". Shame on me, but I just heard about these
technologies and don't know much about all its goals, pros and cons...