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

Unexpected error "arithmetic exception, numeric overflow, or string truncation" while evaluating SUBSTRING the second time [CORE2300] #2724

Closed
firebird-automations opened this issue Jan 30, 2009 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @dyemanov

Is related to QA384

Test case:

create procedure p
returns ( res varchar(10) )
as begin
res = null;
suspend;
res = '0123456789';
suspend;
end

commit;

select substring(res from 1 for 5) from p order by 1; -- success
select substring(res from 1 for 5) from p order by 1; -- error

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
string right truncation.

The problem seems to be caused by the fact that the DSC_null flag is analyzed at both prepare-time and runtime but descriptors can be persistent and thus keep the runtime value until the next time.

In this particular case, the first select call sets DSC_null for the procedure's output and the second select call checks this flag during prepare and describes the output as VARCHAR(1) instead of VARCHAR(10), then this short length is used to prepare the sort buffer and at runtime string truncation happens, because a CHAR(10) string cannot be assigned to a CHAR(1) buffer.

Commits: 0b2322d

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

I had to comment a line present since v1.5. It was setting DSC_null on the shared procedure format.

I tested with TCS and it didn't fail.

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

The fix is correct, you may remove that commented line ;)

I think proc_assignment() declaration must be changed by

static void proc_assignment(thread_db*, const dsc* const, const dsc* const, UCHAR*, const dsc* const, SSHORT, Record*);

i.e. use "const dsc* const" instead of "const dsc*" to explicitly disable change of descriptors.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Thanks for review.

About the const, I never understand the need for such usage. Not because I don't understand how it apply, but because I don't understand its benefit used in "some" places.

I mean, if we think the const apply in this place, there is no difference in think it apply for all the others parameters too:
static void proc_assignment(thread_db* const, const dsc* const, const dsc* const, UCHAR* const, const dsc* const, SSHORT const, Record* const);

It compiles ok, and has the same meaning of don't allow a local variable to change. And then we're adding consts to every variable.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA384 [ QA384 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pcisar

QA test added.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test => Done successfully

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment