Segmentation fault with lo_export

Edmund, has this been fixed?

Hello,

this problem appeared quite frequently in the last two years:
the libpq-function lo_export gives a segmentation fault.

This happend with the current snapshot (I don't remember the
date, it was begin of June, filesize: 3980592) on Linux-2.0.34.
It worked with Postgresql-6.3.2.

Edmund
--
Edmund Mergl mailto:E.Mergl@bawue.de
Im Haldenhau 9 http://www.bawue.de/~mergl
70565 Stuttgart fon: +49 711 747503
Germany

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Bruce Momjian wrote:

Edmund, has this been fixed?

Hello,

this problem appeared quite frequently in the last two years:
the libpq-function lo_export gives a segmentation fault.

This happend with the current snapshot (I don't remember the
date, it was begin of June, filesize: 3980592) on Linux-2.0.34.
It worked with Postgresql-6.3.2.

Edmund

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' ...

thanks
Edmund
--
Edmund Mergl mailto:E.Mergl@bawue.de
Im Haldenhau 9 http://www.bawue.de/~mergl
70565 Stuttgart fon: +49 711 747503
Germany

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().

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

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@candle.pha.pa.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)

Hello,

this problem appeared quite frequently in the last two years:
the libpq-function lo_export gives a segmentation fault.

This happend with the current snapshot (I don't remember the
date, it was begin of June, filesize: 3980592) on Linux-2.0.34.
It worked with Postgresql-6.3.2.

I suspect my large objects change have fix it.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)

Bruce Momjian wrote:

Edmund, has this been fixed?

Hello,

this problem appeared quite frequently in the last two years:
the libpq-function lo_export gives a segmentation fault.

This happend with the current snapshot (I don't remember the
date, it was begin of June, filesize: 3980592) on Linux-2.0.34.
It worked with Postgresql-6.3.2.

Edmund

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' ...

Extra null removed.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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)