Issue Details (XML | Word | Printable)

Key: CORE-3175
Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Major Major
Assignee: Paul Beach
Reporter: haydie rodriguez
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

"error reading data from connection" before the gbak restore ends.

Created: 11/Oct/10 06:15 AM   Updated: 25/May/11 09:45 AM
Component/s: None
Affects Version/s: 2.5.0
Fix Version/s: None

Environment: OSX Snow Leopard (10.6) - Server Version, Xserve hardware, 6GB Ram, Firebird Database file size is 3GB. Using the 64-bit 2.5.0 Release version of Firebird (latest)


 Description  « Hide
backup works fine in OS X Snow Leopard but when restoring using gbak, an error message "error reading data from connection" appears at the end of the restore process. Tested on 3 Xserves and got the same result. I don't encounter the problem on ver 2.1, 2.0 and 1.5 on the same servers.

I tried in Windows and Linux and did not encounter such problem.

below is the last portion of gbak from OS X Terminal:

gbak: activating and creating deferred index LOOKUPOPCODESUNQ2
gbak: activating and creating deferred index LOOKUPREJTYPESUNQ
gbak: activating and creating deferred index LOOKUPREJTYPESUNQ2
gbak: committing metadata
gbak: ERROR:Error reading data from the connection.
gbak:Exiting before completion due to errors
gbak: ERROR:Error reading data from the connection.


I tried doing the same with other databases and also getting the same error.


The database seems to be created even with the errors. However, gstat shows the ff:

Attributes single-user maintenance

This is ok since I can still use gfix to put the database in multi-user mode. However, I am not sure if the database is created completely and without any error. Because of this doubt, I cannot bring the database in production mode


 All   Comments   Change History   Subversion Commits      Sort Order: Descending order - Click to sort in ascending order
Paul Beach added a comment - 25/May/11 09:30 AM
Since
a, The Xserve line was discontinued from Jan 31st, 2011 and
b, We cannot reproduce this bug using a debug build
I am closing it. If anybody else is having problems like this, please let me know.

haydie rodriguez added a comment - 13/Oct/10 04:24 AM
Yes, the XServes uses the Server Version of snow leopard (64-bit mode).
I tried in 4 Mac OSX Snow Leopard Desktops and all works fine.
It seems the problem happens on the Server Version and I was able to reproduce the problem on all my 3 newly delivered Xserves.
Right now, I can't think of any solution for you to access my Xserves, they're located inside the manufacturing plant where I'm working and it's firewalled.
I'll think of other way and will let you know.

Philippe Makowski added a comment - 12/Oct/10 11:16 AM
Xserve is using MacOsX Server version ?
unfortunatly we don't have acess to such box
try to provide use a reproductible test case under MacOsX "Desktop"

or do you have any solution so we can have access to a MacOsX Server edition ?

I don't see how it could be hardware related



Philippe Makowski added a comment - 12/Oct/10 06:55 AM
> I tried to install 2.5.0 CS in my Macbook Pro with Snow Leopard and did same backup and restore process and I did not encounter the same error I'm getting in Xserve

ok, I never did test in Xserve, that can be something to investigate


haydie rodriguez added a comment - 12/Oct/10 06:18 AM
Sorry, I mistakenly copied from a different server.

here's the gstat from the source database running in Linux, and Firebird 2.1 SS.

--------------------------------------------------
Database header page information:
Flags 0
Checksum 12345
Generation 7863369
Page size 4096
ODS version 11.1
Oldest transaction 4324292
Oldest active 4324293
Oldest snapshot 4324293
Next transaction 7863356
Bumped transaction 1
Sequence number 0
Next attachment ID 852688
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Jun 7, 2010 11:05:06
Attributes force write

    Variable header data:
Sweep interval: 0
*END*

--------------------------------------------------

I know about the dialect 1 as being old and not a good idea but can't switch right away to dialect 3 because we still have old windows apps that produces errors when doing queries with dialect 3 database. I'll switch dialect once those old apps are replaced.

About my issue, I'm still looking into the server on what's possibly causing it.

I tried to install 2.5.0 CS in my Macbook Pro with Snow Leopard and did same backup and restore process and I did not encounter the same error I'm getting in Xserve.
 

haydie rodriguez added a comment - 12/Oct/10 06:16 AM
Sorry, I mistakenly copied from a different server.

here's the gstat from the source database running in Linux, and Firebird 2.1 SS.

--------------------------------------------------
Database header page information:
Flags 0
Checksum 12345
Generation 18381659
Page size 4096
ODS version 11.1
Oldest transaction 15880050
Oldest active 15880051
Oldest snapshot 15880051
Next transaction 15880090
Bumped transaction 1
Sequence number 0
Next attachment ID 2501487
Implementation ID 31
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Sep 20, 2010 17:16:11

    Variable header data:
Sweep interval: 0
*END*
--------------------------------------------------

I know about the dialect 1 as being old and not a good idea but can't switch right away to dialect 3 because we still have old windows apps that produces errors when doing queries with dialect 3 database. I'll switch dialect once those old apps are replaced.

About my issue, I'm still looking into the server on what's possibly causing it.

I tried to install 2.5.0 CS in my Macbook Pro with Snow Leopard and did same backup and restore process and I did not encounter the same error I'm getting in Xserve.
 

Philippe Makowski added a comment - 11/Oct/10 01:46 PM - edited
Implementation ID 31
this database was created on a MacOsx x86_64, not on Linux


and sorry, I tested, I can't reproduce your case
seems that your database as something wrong

and why are you still using this old Dialect 1 ?
that is not a good idea


haydie rodriguez added a comment - 11/Oct/10 08:23 AM
Database header page information:
Flags 0
Checksum 12345
Generation 18381659
Page size 4096
ODS version 11.1
Oldest transaction 15880050
Oldest active 15880051
Oldest snapshot 15880051
Next transaction 15880090
Bumped transaction 1
Sequence number 0
Next attachment ID 2501487
Implementation ID 31
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Sep 20, 2010 17:16:11

    Variable header data:
Sweep interval: 0
*END*

Philippe Makowski added a comment - 11/Oct/10 07:07 AM
and what is the output of gstat -h on the Linux source database ?

haydie rodriguez added a comment - 11/Oct/10 07:02 AM
first I made a gbak inside the Snow Leopard Server and backing up data from another server. The server version is SuperClassic.

backup command:

./gbak -user sysdba -password masterkey 172.23.100.20:db1 /gbk/db1.gbk -V -G

the source database is in Linux and running Firebird 2.1 Classic

gbk file was created successfully without any error

now, inside the same Snow Leopard server, I restored using the ff command:

./gbak -user sysdba -password masterkey /gbk/db1.gbk localhost:db1 -V -C

the db1 alias is defined in aliases.conf

the restore will go with the normal restore messages but at the last section
"committing metadata", the error comes out.


Philippe Makowski added a comment - 11/Oct/10 06:35 AM
please give more details
exact command used
Classic, SuperCassic ou Superserver ?
backup came from wich version, ...