Обсуждение: backend debug information

Hello All,

I am working on writing up my "C" extensions but am having a problem with the
backend having a problem and no real useful information is being returned.

I am getting this:
-----------------------------------------------------------------------------

Welcome to psql, the PostgreSQL interactive terminal.
Type:  \copyright for distribution terms      \h for help with SQL commands      \? for help on internal slash commands
    \g or terminate with semicolon to execute query      \q to quit
 
trdata=# select desdecrypt('a','b');
pqReadData() -- backend closed the channel unexpectedly.       This probably means the backend terminated abnormally
  before or while processing the request.
 
The connection to the server was lost. Attempting reset: Failed.
!# \q  
------------------------------------------------------------------------------

This function is part of a library set that I am using and I know that it works
in regular C++ and have already implemented the encryption side with no
problems.

Is there some place that I can get the debug information when this system
crashes out so that I can look for the problem?

Cheers,
Lonnie 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Take it easy, Lonnie! I am still working on your earlier question :)

> I am getting this:

> trdata=# select desdecrypt('a','b');
> pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally
>         before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !# \q  

You've probably got a segv. There's very little else that can happen
in your code. That in turn could be caused by writing at an overflown
pointer or by returning the wrong type. 

As far as debugging, short of being able to run a postgres under gdb
while connecting clients to it (I wish I knew whether that was at all
possible), your options are:

1. (preferred) -- fprintf(stderr, ,) from within your code; then watch
the logs or simply start your postmaster from a shell without
detaching it and see the output.

2. Make a wrapper that walks like a postgres and talks like a postgres
but does nothing except it calls your function and checks the return
value; then run that stuff in gdb.

As a general rule,

3. Slow down. Proceed in small increments. Start with a blank function
and make sure you can pass the desired arguments to it. Return
nothing. Check the values you pass with fprintf. Then add a return
statement and see if you can get away with it. Check it on the outside
with a SELECT. After that, keep adding the code in small logical
units. If it breaks, insert fprintf's to see where. Fprintfs are
almost as good as debugger breakpoints.

I'll be back with more stuff regarding the datatypes shortly.

--Gene

selkovjr@mcs.anl.gov writes:
> As far as debugging, short of being able to run a postgres under gdb
> while connecting clients to it (I wish I knew whether that was at all
> possible),

It's easy to attach gdb to a running backend process; I do that all the
time.  Usual procedure is:
1. Fire up psql in another window2. Determine PID of backend attached to your psql3. gdb /path/to/postgres/executable4.
"attachPID"5. Set breakpoint at desired location(s), continue6. Execute problem query in psql
 

On some platforms you don't have to mention the executable file, as
gdb can figure it out by looking at the process you attach to.  On
others you need to give it.

Setting breakpoints in dynamically loaded shared libraries (ie, user
datatype code) may be easy, painful, or impossible depending on your
platform.  However, you usually can catch a SEGV in such code in any
case; just let the failure happen while gdb is attached.

Don't forget to build your datatype code with -g, and the backend too,
or you'll not be able to learn much.
        regards, tom lane

Hello Selkovjr and Tom,

Thanks for the assistance in helping me to get into the PostgreSQL development
of my "C" extension functions.

Actually I am moving slowly Selkovjr, as I have entered the "learning-curve" of
PostgreSQL and writing these extension functions but it is always necessary to
slow down as we learn new implementations and familiarizations.

I am actually "multitasking" my work on an entire set of classes that we will
be using in our project and it would be nice to have these functions availiable
in the PostgreSQL command set.

The classes are the "crypto4.0" libraries that feature MANY MANY MANY
encryption/decryption methods such as DES, Blowfish, the RSA suite to include
RC5 and RC6, etc....

It is not that we will actually use all of these in our project but it would be
very nice for PostgreSQL to have all of them availiable I think.

I currently have multiple questions running on the forum right now and am
working to solve them both.

I have gotten the "unixcrypt()" working along with the "DES-Encrypt" functions
to work as well, and am trying to tackle the DES-Decrypt" which should be
working just fine as well because the implementation is very similar to the
Encryption method.

The other set of functions (methods) that I am working on are the RSA
encryption/decryption methods. These should also be very easily implemented,
but it is the "key generation" function that I am having a little trouble with
as it needs a "user data type" similar to the "complex" type but using two
"text" fields instead.

This "RSA key generation" function should allow the user to call the function
from the "psql command interpreter" with something like:

GenerateRSAkey(key_length,seed) 

and should return the public and private keys in the user datatype.

The user could then access each field of the datatype to get the actual public
key or private key as needed.

sounds pretty easy, but I am also learning how things work with PostgreSQL as I
go such that things are moving a little slower than I normally do.

I will look over the information that you have sent and look forward to you
future replies to these messages.

Thanks again for all of the help,
Lonnie   
--- selkovjr@mcs.anl.gov wrote:
> 
> Take it easy, Lonnie! I am still working on your earlier question :)
> 
> > I am getting this:
> 
> > trdata=# select desdecrypt('a','b');
> > pqReadData() -- backend closed the channel unexpectedly.
> >         This probably means the backend terminated abnormally
> >         before or while processing the request.
> > The connection to the server was lost. Attempting reset: Failed.
> > !# \q  
> 
> You've probably got a segv. There's very little else that can happen
> in your code. That in turn could be caused by writing at an overflown
> pointer or by returning the wrong type. 
> 
> As far as debugging, short of being able to run a postgres under gdb
> while connecting clients to it (I wish I knew whether that was at all
> possible), your options are:
> 
> 1. (preferred) -- fprintf(stderr, ,) from within your code; then watch
> the logs or simply start your postmaster from a shell without
> detaching it and see the output.
> 
> 2. Make a wrapper that walks like a postgres and talks like a postgres
> but does nothing except it calls your function and checks the return
> value; then run that stuff in gdb.
> 
> As a general rule,
> 
> 3. Slow down. Proceed in small increments. Start with a blank function
> and make sure you can pass the desired arguments to it. Return
> nothing. Check the values you pass with fprintf. Then add a return
> statement and see if you can get away with it. Check it on the outside
> with a SELECT. After that, keep adding the code in small logical
> units. If it breaks, insert fprintf's to see where. Fprintfs are
> almost as good as debugger breakpoints.
> 
> I'll be back with more stuff regarding the datatypes shortly.
> 
> --Gene
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/