Обсуждение: SIGBUS in AllocSetAlloc & jdbc
Peter, I hope this long and boring message can shed some light on my
difficulties getting jdbc & postgres6.5b1(current snapshot) to work
with blobs. I have NO problem with text, numeric, etc. Just blobs &
the LO interface.
I feel that it is a 64 vs 32 bit memory management problem.
My system:
uname -a
SunOS vlad 5.7 Generic_106541-03 sun4u sparc SUNW,Ultra-5_10
postgreSQL:
[PostgreSQL 6.5.0 on sparc-sun-solaris2.7, compiled by cc ]
cc -V
cc: WorkShop Compilers 5.0 98/12/15 C 5.0
The database & tables:
mini_stores=> select * from item;
item_num|item_picture|item_descr
|ship_unit |unit_price|stock
--------+------------+--------------------------------------------------------------+----------+----------+-----
1| 18602|Maximum protection for high-mileage
runners |pair |$75.50 | 1000 2| 18617|Customize your mountain bike with
extra-durable
crankset |each |$20.00 | 500 3| 18634|Long drive golf balls -fluorescent
yellow |pack of 12|$50.00 | 200 4| 18652|Your first season's baseball
glove |pair |$25.00 | 250 5| 18668|Minimum chin contact, feather-light,
maximum
protection helmet|each |$35.50 | 50
(5 rows)
Now the java code that reads the item table and tries to display the
image & data. This is "borrowed" from an example from informix &
their store7/mini_stores jdbc examples.
-----BEGIN---
/***************************************************************************
** Title: demo4.java** Description: To use the fetch_buf_size connection parameter to*
optimizethe query and retrieve large byte data in
the* form of an image** An example of running the program:** java demo4 jdbc:postgresql:mini_stores
<userid><password>****************************************************************************
*/
import java.awt.*;
import java.awt.image.*;
import java.awt.event.*;
import java.sql.*;
public class demo4 extends Frame { static String connURL; // the URL to be used for establishing the
JDBCstatic String usr; // the user id to connect with.static String pwd; // the pasword of the user id.
Connection conn; // the database connection ResultSet queryResults; // the ResultSet containing the rows
returned by
// The GUI controls Label itemNumLabel; TextField itemNumField; Label itemDescrLabel; TextArea
itemDescrArea; Label shipUnitLabel; TextField shipUnitField; Label unitPriceLabel; TextField unitPriceField;
LabelstockLabel; TextField stockField; Label itemPictureLabel; ImgCanvas itemPictureCanvas; Button nextRowBtn;
public static void main(String args[]) { if (args.length != 0) { connURL = args[0]; usr = args[1]; pwd = args[2];
demo4 thisDemo = new demo4(); } else { System.out.println("Missing input!! Please specify the connection
URL"); System.out.println("Usage...java demo4 <jdbc_conn_url>"); } }
public demo4() { super(); createControls(); connectToDBServer(); executeQuery(); }
private void createControls() { setLayout(null); setSize(700,500); setVisible(true); setTitle("Item Table Data");
// Adding label & text-field for item_num column itemNumLabel = new Label("Item Num");
itemNumLabel.setBounds(12,24,60,24);add(itemNumLabel); itemNumField = new TextField();
itemNumField.setBounds(84,24,50,38);add(itemNumField);
// Adding label and text-area for item_descr column itemDescrLabel = new Label("Item Description");
itemDescrLabel.setBounds(12,72,96,24);add(itemDescrLabel); itemDescrArea = new TextArea();
itemDescrArea.setBounds(12,108,194,168);add(itemDescrArea);
// Adding label & text-field for ship_unit column shipUnitLabel = new Label("Ship Unit");
shipUnitLabel.setBounds(24,288,60,38);add(shipUnitLabel); shipUnitField = new TextField();
shipUnitField.setBounds(84,288,84,38);add(shipUnitField);
// Adding label & text-field for unit_price column unitPriceLabel = new Label("Unit Price");
unitPriceLabel.setBounds(24,336,60,38);add(unitPriceLabel); unitPriceField = new TextField();
unitPriceField.setBounds(84,336,84,38);add(unitPriceField);
// Adding label & text-field for stock column stockLabel = new Label("Stock"); stockLabel.setBounds(36,384,36,38);
add(stockLabel);stockField = new TextField(); stockField.setBounds(84,384,84,38); add(stockField);
// Adding label & ImgCanvas for item_picture column itemPictureLabel = new Label("Item Picture");
itemPictureLabel.setBounds(216,24,72,24);add(itemPictureLabel); itemPictureCanvas = new ImgCanvas();
itemPictureCanvas.setBounds(216,60,480,432);add(itemPictureCanvas);
// Adding Next Row button nextRowBtn = new Button("Next Row"); nextRowBtn.setBounds(60,432,84,48); add(nextRowBtn);
// Adding actionListener for button action events nextRowBtn.addActionListener((ActionListener) new
nextRowBtnActionListener());
// Adding WindowListener for the main frame to process window events addWindowListener((WindowListener) new
demo4WindowAdapter()); }
private void connectToDBServer() { try { String psqlDriver = "postgresql.Driver";
// Register the POSTGRESQL-JDBC driver Driver PgsqlDrv = (Driver) Class.forName(psqlDriver).newInstance();
// Get a connection to the database server conn = DriverManager.getConnection(connURL, usr, pwd);
System.out.println("Driver loaded...and connection established"); } catch (Exception e) { System.out.println("Could
notconnect to database server...."); System.out.println(e.getMessage()); } }
private void executeQuery() { // The select statement to be used for querying the item table String selectStmt =
"SELECT* FROM item";
try { // Create a Statement object and use it to execute the query Statement stmt = conn.createStatement();
queryResults= stmt.executeQuery(selectStmt);
System.out.println("Query executed..."); } catch (Exception e) { System.out.println("Could not execute query....");
System.out.println(e.getMessage());} }
// Private inner class extending java.awt.Canvas // Will be used for displaying the item_picture image private
classImgCanvas extends Canvas { Image myImage;
private ImgCanvas() { super(); myImage = null; }
private void setImage(Image img) { myImage = img; }
public void paint(Graphics g) { if(myImage == null) return; else g.drawImage(myImage, 0, 0, this); } }
// Private inner class implementing the ActionListener interface // for the 'Next Row' button private class
nextRowBtnActionListenerimplements ActionListener { // This is the code that will be executed whenever the 'Next Row'
//button is pressed // Here, we get the values of all the columns of the current row // and display them public void
actionPerformed(ActionEventevt) { try { if (queryResults.next()) { // Getting the values of the item_num,
ship_unit // unit_price, item_descr & stock columns and displaying them
itemNumField.setText(queryResults.getString(1)); itemDescrArea.setText(queryResults.getString(3));
shipUnitField.setText(queryResults.getString(4)); unitPriceField.setText(queryResults.getString(5));
stockField.setText(queryResults.getString(6));
// Getting the value of the item_picture column and // displaying it System.err.println("Got oid
"+queryResults.getInt(2)); byte itemPictureArray [] = queryResults.getBytes(2); if (itemPictureArray != null) {
Image img =
Toolkit.getDefaultToolkit().createImage(itemPictureArray); itemPictureCanvas.setImage(img);
itemPictureCanvas.repaint(); } } else { System.out.println("No more rows!!"); } } catch (Exception e) {
System.out.println("Couldnot display next row..."); System.out.println(e.getMessage()); } } }
// Private inner class implementing the WindowAdapter interface // for the main frame window private class
demo4WindowAdapterextends WindowAdapter { // This is the code that will be executed whenever the frame // window is
closedusing the button in its upper-right corner public void windowClosing(WindowEvent evt) { setVisible(false); //
hidethe main frame dispose(); // free the system resources System.exit(0); // close the application } }
}
------END----
Now I start it & attach to the backend with gdb. After the frame is
up, I can select the next row (the first). It works as it should.
When I select next (for the second), then I get the following back
trace:
vlad: ps -ef | grep po root 272 1 0 Apr 27 ? 0:00 /usr/lib/power/powerd bpm 771 1 0
10:45:48pts/2 0:00 /opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -S 16384 -i -p 5 bpm 796 771 1 10:53:49 pts/2 0:00
/opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -S 16384 -i -p 5 bpm 798 1153 0 10:53:53 pts/10 0:00 grep po
vlad: gdb /opt/pgsql/bin/postmaster 796
GNU gdb 4.17
Copyright 1998 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 "sparc-sun-solaris2.7"...
(no debugging symbols found)...
/home/bpm/development/perl_ext/DBD-Pg-0.91/796: No such file or
directory.
Attaching to program `/opt/pgsql/bin/postmaster', process 796
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libcrypt_i.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/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.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-5_10/lib/libc_psr.so.1...
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)...done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
Symbols already loaded for /usr/lib/libgen.so.1
Symbols already loaded for /usr/lib/libcrypt_i.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libcurses.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/nss_files.so.1
0xff19311c in _so_recv ()
(gdb) bt
#0 0xff19311c in _so_recv ()
#1 0xbb4d4 in pq_recvbuf ()
#2 0xbb710 in pq_getbytes ()
#3 0x13e020 in SocketBackend ()
#4 0x13e124 in ReadCommand ()
#5 0x140434 in PostgresMain ()
#6 0x11161c in DoBackend ()
#7 0x110e78 in BackendStartup ()
#8 0x10fd98 in ServerLoop ()
#9 0x10f6e0 in PostmasterMain ()
#10 0xbca58 in main ()
(gdb) c
Continuing.
Program received signal SIGBUS, Bus error.
0x19f180 in AllocSetAlloc ()
(gdb) bt
#0 0x19f180 in AllocSetAlloc ()
#1 0x19fa2c in GlobalMemoryAlloc ()
#2 0x19f7b8 in MemoryContextAlloc ()
#3 0x19fc58 in pstrdup ()
#4 0x1331c4 in inv_open ()
#5 0xb3e18 in lo_open ()
#6 0x199e38 in fmgr_c ()
#7 0x19a46c in fmgr ()
#8 0x13dc44 in HandleFunctionRequest ()
#9 0x14048c in PostgresMain ()
#10 0x11161c in DoBackend ()
#11 0x110e78 in BackendStartup ()
#12 0x10fd98 in ServerLoop ()
#13 0x10f6e0 in PostmasterMain ()
#14 0xbca58 in main ()
######## NEXT EXAMPLE ###############
I stopped/started the postmaster as:
/opt/pgsql/bin/postmaster -o "-d 3 -F -o ${PGSQLHOME}/logs/backend.log
-W 30 -S 16384" \ -i -d 3 -p 5432 -D ${PGDATA} >
${PGSQLHOME}/logs/error.log 2>&1 &
Now I ran the examples/blobtest, attached to the backend & got the
following:
vlad: ps -ef | grep po root 272 1 0 Apr 27 ? 0:00 /usr/lib/power/powerd bpm 815 1 0
11:00:58pts/2 0:00 /opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 - bpm 830 815 0 11:01:37 pts/2 0:00
/opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 - bpm 833 1153 0 11:01:45 pts/10 0:00 grep po
vlad: gdb /opt/pgsql/bin/postmaster 830
GNU gdb 4.17
Copyright 1998 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 "sparc-sun-solaris2.7"...
(no debugging symbols found)...
/opt/pgsql/logs/830: No such file or directory.
Attaching to program `/opt/pgsql/bin/postmaster', process 830
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libcrypt_i.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/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.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-5_10/lib/libc_psr.so.1...
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)...done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
Symbols already loaded for /usr/lib/libgen.so.1
Symbols already loaded for /usr/lib/libcrypt_i.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libcurses.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/nss_files.so.1
0xff195d88 in _sigsuspend ()
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x19f180 in AllocSetAlloc ()
(gdb) bt
#0 0x19f180 in AllocSetAlloc ()
#1 0x19fa2c in GlobalMemoryAlloc ()
#2 0x19f7b8 in MemoryContextAlloc ()
#3 0x5b69c in btrescan ()
#4 0x199e60 in fmgr_c ()
#5 0x19a46c in fmgr ()
#6 0x4d3a0 in index_rescan ()
#7 0x4cc70 in RelationGetIndexScan ()
#8 0x5b4d0 in btbeginscan ()
#9 0x199e8c in fmgr_c ()
#10 0x19a46c in fmgr ()
#11 0x4d2e4 in index_beginscan ()
#12 0x133624 in inv_seek ()
#13 0xb4070 in lo_lseek ()
#14 0x199e60 in fmgr_c ()
#15 0x19a46c in fmgr ()
#16 0x13dc44 in HandleFunctionRequest ()
#17 0x14048c in PostgresMain ()
#18 0x11161c in DoBackend ()
#19 0x110e78 in BackendStartup ()
#20 0x10fd98 in ServerLoop ()
#21 0x10f6e0 in PostmasterMain ()
#22 0xbca58 in main ()
I looked at src/backend/utils/mmgr/aset.c to see what was going on in
AllocSetAlloc, but I am but a mere mortal.
Thanks.
--
Brian Millett
Enterprise Consulting Group "Heaven can not exist,
(314) 205-9030 If the family is not eternal"
bpm@ec-group.com F. Ballard Washburn
On Thu, 29 Apr 1999, Brian P Millett wrote:
> Peter, I hope this long and boring message can shed some light on my
> difficulties getting jdbc & postgres6.5b1(current snapshot) to work
> with blobs. I have NO problem with text, numeric, etc. Just blobs &
> the LO interface.
>
> I feel that it is a 64 vs 32 bit memory management problem.
At first glance, the JDBC code looks ok. In fact it is similar to the
ImageViewer example that's included with the source.
Do you get the same problem when using ImageViewer?
> // Getting the value of the item_picture column and
> // displaying it
> System.err.println("Got oid "+queryResults.getInt(2));
> byte itemPictureArray [] = queryResults.getBytes(2);
> if (itemPictureArray != null) {
> Image img =
> Toolkit.getDefaultToolkit().createImage(itemPictureArray);
> itemPictureCanvas.setImage(img);
> itemPictureCanvas.repaint();
> }
Using an array is perfectly valid, and the driver does support this method
of getting an Image from a BLOB.
Tip: The JDBC spec says you should only read a field once. However, with
our driver, this is ok.
I'm not sure about the backend, but the JDBC side looks fine.
Peter
-- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf
Peter T Mount wrote: > On Thu, 29 Apr 1999, Brian P Millett wrote: > > > Peter, I hope this long and boring message can shed some light on my > > difficulties getting jdbc & postgres6.5b1(current snapshot) to work > > with blobs. I have NO problem with text, numeric, etc. Just blobs & > > the LO interface. > > > > I feel that it is a 64 vs 32 bit memory management problem. > > At first glance, the JDBC code looks ok. In fact it is similar to the > ImageViewer example that's included with the source. > > Do you get the same problem when using ImageViewer? No, and yes. The ImageViewer will give an error that the backend has lost connection after importing the second image. The first goes in just fine, it is the second that causes the problem. If I stop & restart the ImageViewer, then I can import a second image. BUT I can only view one. When I try to view the second, I get an error. The back trace of that error is at the bottom. It IS the same as the backtrace for the example I sent you. Again, the first time I run ImageViewer, I can import only one image. When I import a second image, I get the backtrace (1). After I stop & start the ImageViewer, there is one image in the database. I can import a new image, but when I try to view the first image, I get backtrace (2). BACKTRACE (1): here is the bt: vlad: ps -ef | grep po root 272 1 0 Apr 27 ? 0:00 /usr/lib/power/powerd bpm 815 1 0 11:00:58pts/2 0:00 /opt/pgsql/bin/postmaster -o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 - bpm 965 1153 0 13:41:54 pts/10 0:00 grep po bpm 961 815 0 13:41:49 pts/2 0:00 /opt/pgsql/bin/postmaster -o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 - vlad: gdb /opt/pgsql/bin/postmaster 961 GNU gdb 4.17 Copyright 1998 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 "sparc-sun-solaris2.7"... (no debugging symbols found)... /home/bpm/compile_area/cvs_pgsql/pgsql.snapshot/961: No such file or directory. Attaching to program `/opt/pgsql/bin/postmaster', process 961 Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libcrypt_i.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/libdl.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libc.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-5_10/lib/libc_psr.so.1... ---Type <return> to continue, or q <return> to quit--- (no debugging symbols found)...done. Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols found)... done. Symbols already loaded for /usr/lib/libgen.so.1 Symbols already loaded for /usr/lib/libcrypt_i.so.1 Symbols already loaded for /usr/lib/libnsl.so.1 Symbols already loaded for /usr/lib/libsocket.so.1 Symbols already loaded for /usr/lib/libdl.so.1 Symbols already loaded for /usr/lib/libm.so.1 Symbols already loaded for /usr/lib/libcurses.so.1 Symbols already loaded for /usr/lib/libc.so.1 Symbols already loaded for /usr/lib/libmp.so.2 Symbols already loaded for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Symbols already loaded for /usr/lib/nss_files.so.1 0xff195d88 in _sigsuspend () (gdb) c Continuing. Program received signal SIGBUS, Bus error. 0xff145d70 in t_delete () (gdb) bt #0 0xff145d70 in t_delete () #1 0xff145490 in _malloc_unlocked () #2 0xff145314 in malloc () #3 0x19f3a8 in AllocSetAlloc () #4 0x19fe48 in PortalHeapMemoryAlloc () #5 0x19f7b8 in MemoryContextAlloc () #6 0xb28c0 in initStringInfo () #7 0x13d4cc in SendFunctionResult () #8 0x13dcd4 in HandleFunctionRequest () #9 0x14048c in PostgresMain () #10 0x11161c in DoBackend () #11 0x110e78 in BackendStartup () #12 0x10fd98 in ServerLoop () #13 0x10f6e0 in PostmasterMain () #14 0xbca58 in main () BACKTRACE (2): vlad: ps -ef | grep po root 272 1 0 Apr 27 ? 0:00 /usr/lib/power/powerd bpm 815 1 0 11:00:58pts/2 0:00 /opt/pgsql/bin/postmaster -o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 - bpm 983 1153 0 14:08:13 pts/10 0:00 grep po bpm 981 815 0 14:08:09 pts/2 0:00 /opt/pgsql/bin/postmaster -o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 - vlad: gdb /opt/pgsql/bin/postmaster 981 GNU gdb 4.17 Copyright 1998 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 "sparc-sun-solaris2.7"... (no debugging symbols found)... /home/bpm/compile_area/cvs_pgsql/pgsql.snapshot/981: No such file or directory. Attaching to program `/opt/pgsql/bin/postmaster', process 981 Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libcrypt_i.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/libdl.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libc.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-5_10/lib/libc_psr.so.1... ---Type <return> to continue, or q <return> to quit--- (no debugging symbols found)...done. Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols found)... done. Symbols already loaded for /usr/lib/libgen.so.1 Symbols already loaded for /usr/lib/libcrypt_i.so.1 Symbols already loaded for /usr/lib/libnsl.so.1 Symbols already loaded for /usr/lib/libsocket.so.1 Symbols already loaded for /usr/lib/libdl.so.1 Symbols already loaded for /usr/lib/libm.so.1 Symbols already loaded for /usr/lib/libcurses.so.1 Symbols already loaded for /usr/lib/libc.so.1 Symbols already loaded for /usr/lib/libmp.so.2 Symbols already loaded for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Symbols already loaded for /usr/lib/nss_files.so.1 0xff195d88 in _sigsuspend () (gdb) c Continuing. Program received signal SIGBUS, Bus error. 0x19f180 in AllocSetAlloc () (gdb) bt #0 0x19f180 in AllocSetAlloc () #1 0x19fa2c in GlobalMemoryAlloc () #2 0x19f7b8 in MemoryContextAlloc () #3 0x4cc44 in RelationGetIndexScan () #4 0x5b4d0 in btbeginscan () #5 0x199e8c in fmgr_c () #6 0x19a46c in fmgr () #7 0x4d2e4 in index_beginscan () #8 0x133624 in inv_seek () #9 0x133514 in inv_seek () #10 0xb4070 in lo_lseek () #11 0x199e60 in fmgr_c () #12 0x19a46c in fmgr () #13 0x13dc44 in HandleFunctionRequest () #14 0x14048c in PostgresMain () #15 0x11161c in DoBackend () #16 0x110e78 in BackendStartup () #17 0x10fd98 in ServerLoop () #18 0x10f6e0 in PostmasterMain () #19 0xbca58 in main () -- Brian Millett Enterprise Consulting Group "Heaven can not exist, (314) 205-9030 If the family is not eternal" bpm@ec-group.com F. Ballard Washburn
> On Thu, 29 Apr 1999, Brian P Millett wrote:
>
> > Peter, I hope this long and boring message can shed some light on my
> > difficulties getting jdbc & postgres6.5b1(current snapshot) to work
> > with blobs. I have NO problem with text, numeric, etc. Just blobs &
> > the LO interface.
> >
> > I feel that it is a 64 vs 32 bit memory management problem.
>
> At first glance, the JDBC code looks ok. In fact it is similar to the
> ImageViewer example that's included with the source.
>
> Do you get the same problem when using ImageViewer?
>
> > // Getting the value of the item_picture column and
> > // displaying it
> > System.err.println("Got oid "+queryResults.getInt(2));
> > byte itemPictureArray [] = queryResults.getBytes(2);
> > if (itemPictureArray != null) {
> > Image img =
> > Toolkit.getDefaultToolkit().createImage(itemPictureArray);
> > itemPictureCanvas.setImage(img);
> > itemPictureCanvas.repaint();
> > }
>
> Using an array is perfectly valid, and the driver does support this method
> of getting an Image from a BLOB.
This morning I started to look into this. First, JDBC driver coming
with 6.5b did not compile. The reason was my JDK (JDK 1.1.7 v1 on
LinuxPPC) returns version string as "root:10/14/98-13:50" and
makeVersion expected it started with "1.1". This was easy to fix. So I
went on and tried the ImageViewer sample. It gave me SQL an exception:
java example.ImageViewer jdbc:postgresql:test t-ishii ""
Connecting to Database URL = jdbc:postgresql:test
Exception caught.
java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try rebuilding.
Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try rebuilding.
Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connectionat postgresql.Driver.connect(Compiled
Code)atjava.sql.DriverManager.getConnection(Compiled Code)at java.sql.DriverManager.getConnection(Compiled Code)at
example.ImageViewer.<init>(CompiledCode)at example.ImageViewer.main(Compiled Code)
I had no idea how to fix this. I gave up to use the 6.5 JDBC driver. I
had to get back to the 6.4 JDBC driver. This time ImageViewer seemed
to work. I imported 3 images. Worked fine. Then I tried to take a
glance at the first image. I got SIGSEGV on the backend! It happened in
AllocSetAlloc () and seems in the same place as Brian P Millett
mentioned. Next I switched the backend to 6.4.2(+ large object fixes
basically same as 6.5). Worked great!
In summary:
(1) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.5 backend failed
(2) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.4.2 backend worked
So I suspect there is something wrong with the 6.5 backend. I'll look
into this more.
P.S. Peter, do you have any suggestion to make JDBC driver under JDK
1.1.7?
---
Tatsuo Ishii
> This morning I started to look into this. First, JDBC driver coming
> with 6.5b did not compile. The reason was my JDK (JDK 1.1.7 v1 on
> LinuxPPC) returns version string as "root:10/14/98-13:50" and
> makeVersion expected it started with "1.1". This was easy to fix. So I
> went on and tried the ImageViewer sample. It gave me SQL an exception:
>
> java example.ImageViewer jdbc:postgresql:test t-ishii ""
> Connecting to Database URL = jdbc:postgresql:test
> Exception caught.
> java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try
rebuilding.
> Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
> java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try
rebuilding.
> Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
> at postgresql.Driver.connect(Compiled Code)
> at java.sql.DriverManager.getConnection(Compiled Code)
> at java.sql.DriverManager.getConnection(Compiled Code)
> at example.ImageViewer.<init>(Compiled Code)
> at example.ImageViewer.main(Compiled Code)
>
> I had no idea how to fix this. I gave up to use the 6.5 JDBC driver. I
> had to get back to the 6.4 JDBC driver. This time ImageViewer seemed
> to work. I imported 3 images. Worked fine. Then I tried to take a
> glance at the first image. I got SIGSEGV on the backend! It happened in
> AllocSetAlloc () and seems in the same place as Brian P Millett
> mentioned. Next I switched the backend to 6.4.2(+ large object fixes
> basically same as 6.5). Worked great!
>
> In summary:
>
> (1) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.5 backend failed
> (2) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.4.2 backend worked
>
> So I suspect there is something wrong with the 6.5 backend. I'll look
> into this more.
>
> P.S. Peter, do you have any suggestion to make JDBC driver under JDK
> 1.1.7?
So far I couldn't find nothing special with the backend by now. Going
back to the ImageViewer, I think I found possible problem with it. In
my understanding, every lo call should be in single transaction block.
But ImageViwer seems does not give any "begin" or "end" SQL commands.
I made a small modifications(see below patches) to the ImageViewer and
now it starts to work again with 6.5 backend! I suspect that
difference of palloc() code between 6.4.2 and 6.5 made the problem
opened up.
---
Tatsuo Ishii
*** ImageViewer.java~ Mon Oct 12 11:45:45 1998
--- ImageViewer.java Sun May 2 23:16:27 1999
***************
*** 390,395 ****
--- 390,396 ---- { try { System.out.println("Selecting oid for "+name);
+ stat.executeUpdate("begin"); ResultSet rs = stat.executeQuery("select imgoid from images where
imgname='"+name+"'"); if(rs!=null) { // Even though there should only be one image, we still have to
***************
*** 402,407 ****
--- 403,409 ---- } } rs.close();
+ stat.executeUpdate("end"); } catch(SQLException ex) { label.setText(ex.toString()); }
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> So far I couldn't find nothing special with the backend by now. Going
> back to the ImageViewer, I think I found possible problem with it. In
> my understanding, every lo call should be in single transaction block.
> But ImageViwer seems does not give any "begin" or "end" SQL commands.
> I made a small modifications(see below patches) to the ImageViewer and
> now it starts to work again with 6.5 backend!
Hmm. The documentation does say somewhere that LO object handles are
only good within a transaction ... so it's amazing this worked reliably
under 6.4.x.
Is there any way we could improve the backend's LO functions to defend
against this sort of misuse, rather than blindly accepting a stale
filehandle?
regards, tom lane
On Sun, 2 May 1999, Tatsuo Ishii wrote:
> So far I couldn't find nothing special with the backend by now. Going
> back to the ImageViewer, I think I found possible problem with it. In
> my understanding, every lo call should be in single transaction block.
> But ImageViwer seems does not give any "begin" or "end" SQL commands.
> I made a small modifications(see below patches) to the ImageViewer and
> now it starts to work again with 6.5 backend! I suspect that
> difference of palloc() code between 6.4.2 and 6.5 made the problem
> opened up.
This is true, and is probably why it was opened up.
However, with JDBC, you should never issue begin and end statements, as
this can cause the driver to become confused.
The reason is autoCommit. In jdbc, to start a transaction, you should call
the setAutoCommit() method in Connection to say if you want autocommit
(true), or transactions (false). The standard default is true.
> ---
> Tatsuo Ishii
>
> *** ImageViewer.java~ Mon Oct 12 11:45:45 1998
> --- ImageViewer.java Sun May 2 23:16:27 1999
> ***************
> *** 390,395 ****
> --- 390,396 ----
> {
> try {
> System.out.println("Selecting oid for "+name);
> + stat.executeUpdate("begin");
> ResultSet rs = stat.executeQuery("select imgoid from images where imgname='"+name+"'");
> if(rs!=null) {
> // Even though there should only be one image, we still have to
> ***************
> *** 402,407 ****
> --- 403,409 ----
> }
> }
> rs.close();
> + stat.executeUpdate("end");
> } catch(SQLException ex) {
> label.setText(ex.toString());
> }
>
-- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf
[ I'm cc'ing this to java-linux as this seems to be a problem with the Linux PPC port - peter ] On Sun, 2 May 1999, Tatsuo Ishii wrote: [snip] > This morning I started to look into this. First, JDBC driver coming > with 6.5b did not compile. The reason was my JDK (JDK 1.1.7 v1 on > LinuxPPC) returns version string as "root:10/14/98-13:50" and > makeVersion expected it started with "1.1". This was easy to fix. So I > went on and tried the ImageViewer sample. It gave me SQL an exception: [snip] > P.S. Peter, do you have any suggestion to make JDBC driver under JDK > 1.1.7? Ah, the first problem I've seen with the JVM version detection. the postgresql.Driver class does the same thing as makeVersion, and checks the version string, and when it sees that it starts with 1.1 it sets the base package to postgresql.j1 otherwise it sets it to postgresql.j2. The exceptions you are seeing is the JVM complaining it cannot find the JDK1.2 classes. As how to fix this, this is tricky. It seems that the version string isn't that helpful. The JDK documentation says it returns the version of the JVM, but there seems to be no set format for this. ie, with your version, it seems to give a date and time that VM was built. Java-Linux: Is there a way to ensure that the version string is similar to the ones that Sun produces? At least having the JVM version first, then reform after that? The PostgreSQL JDBC driver is developed and tested under Linux (intel) using 1.1.6 and 1.2b1 JVM's (both blackdown). I use Sun's Win32 1.2 JVM for testing. The current driver works fine on all three JVM's, so it seems to be the PPC port that has this problem. Peter -- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf
> Hmm. The documentation does say somewhere that LO object handles are
> only good within a transaction ... so it's amazing this worked reliably
> under 6.4.x.
>
> Is there any way we could improve the backend's LO functions to defend
> against this sort of misuse, rather than blindly accepting a stale
> filehandle?
It should not be very difficult. We could explicitly close LO
filehandles on commits.
But I'm now not confident on this. From comments in be-fsstubs.c:
>Builtin functions for open/close/read/write operations on large objects.
>These functions operate in the current portal variable context, which
>means the large object descriptors hang around between transactions and
>are not deallocated until explicitly closed, or until the portal is
>closed.
If above is true, LO filehandles should be able to survive between
transactions.
Following data are included in them. My question is: Can these data
survive between transactions? I guess not.
typedef struct LargeObjectDesc
{Relation heap_r; /* heap relation */Relation index_r; /* index relation on seqno attribute
*/IndexScanDesciscan; /* index scan we're using */TupleDesc hdesc; /* heap relation tuple desc
*/TupleDesc idesc; /* index relation tuple desc */
[snip]
> > Hmm. The documentation does say somewhere that LO object handles are
> > only good within a transaction ... so it's amazing this worked reliably
> > under 6.4.x.
> >
> > Is there any way we could improve the backend's LO functions to defend
> > against this sort of misuse, rather than blindly accepting a stale
> > filehandle?
>
> It should not be very difficult. We could explicitly close LO
> filehandles on commits.
>
> But I'm now not confident on this. From comments in be-fsstubs.c:
>
> >Builtin functions for open/close/read/write operations on large objects.
> >These functions operate in the current portal variable context, which
> >means the large object descriptors hang around between transactions and
> >are not deallocated until explicitly closed, or until the portal is
> >closed.
>
> If above is true, LO filehandles should be able to survive between
> transactions.
>
> Following data are included in them. My question is: Can these data
> survive between transactions? I guess not.
>
> typedef struct LargeObjectDesc
> {
> Relation heap_r; /* heap relation */
> Relation index_r; /* index relation on seqno attribute */
> IndexScanDesc iscan; /* index scan we're using */
> TupleDesc hdesc; /* heap relation tuple desc */
> TupleDesc idesc; /* index relation tuple desc */
>
> [snip]
The answer was yes. Since these data are allocated in
GlobalMemoryContext, they could survive after commit. So next question
is why the backend crashes if LO calls are not in a transaction?
At the commit time _lo_commit() is called under GlobalMemoryContext to
destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be
created under GlobalMemoryContext. But actually lo_read/lo_write,
they might create IndexScanDesc also, may not be called under the
context since no context switching is made with them(I don't know why
since other LO calls make context switching). As a result it's
possible that IndexScanDesc might be freed under a wrong context. Too
bad.
This would not happen if lo_seek is done (it's executed under
GlobalMemoryContext) then lo_read/lo_write gets called(they reuse
IndexScanDesc created by inv_seek) *AND* no committing is done before
lo_read/lo_write. This is why we do not observe the backend crash with
ImageViewer running in a transaction.
But I must say other apps may not be as lucky as ImageViewer since
it's not always the case that lo_seek is called prior to
lo_read/lo_write.
[ BTW, ImageViewer seems to make calls to following set of LOs *twice*
to display an image. Why?
lo_open
lo_tell
lo_lseek
lo_lseek
lo_read
lo_close
]
Possible solutions might be:
(1) do a context switching in lo_read/lo_write
(2) ask apps not to make LO calls between transactions
(3) close LOs fd at commit
(2) is the current situation but not very confortable for us. Also for
a certain app this is not a solution as I mentioned above. (3) seems
reasonable but people might be surprised to find their existing apps
won't run any more. Moreover, changings might not be trivial and it
make me nervous since we don't have enough time before 6.5 is
out. With (1) modifications would be minimum, and we can keep the
backward compatibility for apps. So my conclusion is that (1) is the
best. If there's no objection, I will commit the change for (1).
---
Tatsuo Ishii
> The answer was yes. Since these data are allocated in > GlobalMemoryContext, they could survive after commit. So next question > is why the backend crashes if LO calls are not in a transaction? > > At the commit time _lo_commit() is called under GlobalMemoryContext to > destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be > created under GlobalMemoryContext. But actually lo_read/lo_write, > they might create IndexScanDesc also, may not be called under the > context since no context switching is made with them(I don't know why > since other LO calls make context switching). As a result it's > possible that IndexScanDesc might be freed under a wrong context. Too > bad. > > This would not happen if lo_seek is done (it's executed under > GlobalMemoryContext) then lo_read/lo_write gets called(they reuse > IndexScanDesc created by inv_seek) *AND* no committing is done before > lo_read/lo_write. This is why we do not observe the backend crash with > ImageViewer running in a transaction. > > But I must say other apps may not be as lucky as ImageViewer since > it's not always the case that lo_seek is called prior to > lo_read/lo_write. > > [ BTW, ImageViewer seems to make calls to following set of LOs *twice* > to display an image. Why? > > lo_open > lo_tell > lo_lseek > lo_lseek > lo_read > lo_close > ] > > Possible solutions might be: > > (1) do a context switching in lo_read/lo_write > > (2) ask apps not to make LO calls between transactions > > (3) close LOs fd at commit > > (2) is the current situation but not very confortable for us. Also for > a certain app this is not a solution as I mentioned above. (3) seems > reasonable but people might be surprised to find their existing apps > won't run any more. Moreover, changings might not be trivial and it > make me nervous since we don't have enough time before 6.5 is > out. With (1) modifications would be minimum, and we can keep the > backward compatibility for apps. So my conclusion is that (1) is the > best. If there's no objection, I will commit the change for (1). This is all clearly part of the large object mess that we were in before you fixed large objects. Do whatever you think is best for the long term. Large objects were so terribly fragile in previous releases, we might as well advertise them again as now working 100% of the time. If the new behaviour changes existing apps, that is OK if the new behaviour is superior. They will be thrilled to change their apps if the large object system now works better. It would be different if the old system worked properly. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> At the commit time _lo_commit() is called under GlobalMemoryContext to
> destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be
> created under GlobalMemoryContext. But actually lo_read/lo_write,
> they might create IndexScanDesc also, may not be called under the
> context since no context switching is made with them(I don't know why
> since other LO calls make context switching).
I was noticing that yesterday (I modified be-fsstubs.c to use properly
allocated filehandles in lo_import and lo_export, and added extra
checking for a valid LO handle --- the old code would coredump if
handed a -1 handle, which is not too cool considering that's what it
would get if an app didn't bother to check for lo_open failure...).
It seemed odd that lo_read and lo_write didn't switch contexts like the
other entry points did. But I didn't know enough to risk changing it.
> Possible solutions might be:
> (1) do a context switching in lo_read/lo_write
I agree with this, but I worry a little bit about memory leakage,
because anything allocated in GlobalMemoryContext is not going to get
cleaned up automatically. If lo_read/lo_write call any code that is
sloppy about pfree'ing everything it palloc's, then you'd have a
long-term leakage that would eventually make the backend run out of
memory. But it'd be easy enough to test for that, if you have a test
app that can run the backend through a lot of LO calls.
regards, tom lane
> > Possible solutions might be: > > (1) do a context switching in lo_read/lo_write > > I agree with this, but I worry a little bit about memory leakage, > because anything allocated in GlobalMemoryContext is not going to get > cleaned up automatically. If lo_read/lo_write call any code that is > sloppy about pfree'ing everything it palloc's, then you'd have a > long-term leakage that would eventually make the backend run out of > memory. But it'd be easy enough to test for that, if you have a test > app that can run the backend through a lot of LO calls. Yes, I thought about that too. Maybe we could destroy the GlobalMemoryContext in lo_close() if no LO descriptor exists any more. Of course this would not prevent the memory leakage if a user forget to call lo_close, but it's of the user's responsibility anyway. --- Tatsuo Ishii
> This is all clearly part of the large object mess that we were in before > you fixed large objects. > > Do whatever you think is best for the long term. Large objects were so > terribly fragile in previous releases, we might as well advertise them > again as now working 100% of the time. If the new behaviour changes > existing apps, that is OK if the new behaviour is superior. They will > be thrilled to change their apps if the large object system now works > better. > > It would be different if the old system worked properly. I have changed lo_read/lo_write so that they run under same memory context as other LO calls. --- Tatsuo Ishii
Tatsuo Ishii wrote: > > This is all clearly part of the large object mess that we were in before > > you fixed large objects. > > > > Do whatever you think is best for the long term. Large objects were so > > terribly fragile in previous releases, we might as well advertise them > > again as now working 100% of the time. If the new behaviour changes > > existing apps, that is OK if the new behaviour is superior. They will > > be thrilled to change their apps if the large object system now works > > better. > > > > It would be different if the old system worked properly. > > I have changed lo_read/lo_write so that they run under same memory > context as other LO calls. Well, for the first time (for me) the blobtest.java now works correctly. That would be Solaris 2.7, cvs checkout 19990511, jdk1.2.1_02. Thank you all for the great work. -- Brian Millett Enterprise Consulting Group "Heaven can not exist, (314) 205-9030 If the family is not eternal" bpm@ec-group.com F. Ballard Washburn