Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bus error when working with DB_KEY on bigendian machines [CORE2550] #2960

Closed
firebird-issue-importer opened this issue Jul 8, 2009 · 10 comments
Closed

Comments

@firebird-issue-importer
Copy link

@firebird-issue-importer firebird-issue-importer commented Jul 8, 2009

Submitted by: @AlexPeshkoff

When working with DB_KEY in stored procedure, alignment error takes place. Tjhis happens due to badly aligned data in descriptor, storing DB_KEY as text, and direct reintepret_cast<>, applied to it in evl.cpp:

RecordNumber::Packed* numbers = reinterpret_castRecordNumber::Packed\*\(desc->dsc_address);

Commits: fe4aec8 43584fa

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 8, 2009

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 10, 2009

Commented by: @AlexPeshkoff

2.1 codebase has simplified fix, forcing alignment of descriptor data on bigendian machines.

In HEAD new descriptor type is added in engine, dtype_dbkey. It's never goes out of engine in 2.5 (even dsql knows nothing about it). In the future new type should be also added to XSQLDA and related places, helping void hacks in isql and other clients when displaying DB_KEY.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 10, 2009

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 RC1 [ 10300 ]

Fix Version: 2.1.4 [ 10361 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 10, 2009

Commented by: @AlexPeshkoff

Reopened to modify fix version - decided to have it in 2.1.3 RC2.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 10, 2009

Modified by: @AlexPeshkoff

status: Resolved [ 5 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 10, 2009

Modified by: @AlexPeshkoff

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1.3 [ 10302 ]

Fix Version: 2.1.4 [ 10361 ] =>

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 12, 2009

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 16, 2013

Commented by: @dyemanov

Just for the record, I disagree with the DBKEY being surfaced in XSQLDA as a separate datatype. The XSQLVAR types are needed just to map FB datatypes to the host language datatypes. If one can work with DBKEYs in PSQL using SQL datatypes, the same can be easily done in the host language using existing XSQLVAR datatypes. As for informing the user about some var being a DBKEY (for displaying purposes or whatever), other solutions are possible (e.g. some flag returned for the every described parameter).

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 18, 2016

Modified by: @pavel-zotov

QA Status: No test

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Aug 7, 2016

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants