Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Segmentation fault with lo_export

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: E(dot)Mergl(at)bawue(dot)de, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Segmentation fault with lo_export
Date: 1998-08-29 02:13:16
Message-ID: 199808290213.WAA26381@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> > Hi Bruce,
> > 
> > it looks like the last time I tested lo_export it worked
> > just by chance.
> > 
> > The bug seems to be in interfaces/libpq/fe-lobj.c line 424.
> > The two functions lo_import and lo_export are somehow
> > similar when exchanging the read/write for Unix file
> > and inv file. But whereas read() reads exactly BUFSIZ
> > bytes, lo_read() appends a '\0' after having read
> > BUFSIZ bytes. So line 424 should be:
> > 
> >   	char		buf[LO_BUFSIZE+1];
> > 
> > instead of:
> > 
> > 	char		buf[LO_BUFSIZE];
> > 
> > Could you please apply this bug-fix ?
> > Also the code example in the man page for
> > large-objects needs to be corrected. 
> > 
> > I can't do it by myself because I am on 
> > vacation on a Greek island, and the only 
> > message I'm seeing frequently is 
> > 'modem hangup, no CARRIER' ...
> 
> I am going to fix lo_read().  I see no reason not to have it function
> like read().

OK.  It was actually libpq that was placing the NULL, through PQfn() and
pqGetnchar().  Shouldn't have.

Fixed now.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-08-29 02:17:54
Subject: Re: [HACKERS] Segmentation fault with lo_export
Previous:From: Bruce MomjianDate: 1998-08-28 23:25:28
Subject: Re: strange path through code (initdb problem)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group