Issue Details (XML | Word | Printable)

Key: CORE-1057
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 0

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

GSEC hiding error - CryptAcquireContext

Created: 17/Dec/06 03:45 AM   Updated: 19/Jan/16 05:11 AM
Component/s: GSEC
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1

Environment: Windows XP

QA Status: No test

 Description  « Hide
By some unknown reason for me, in guid.cpp the call to
CryptAcquireContext(..., CRYPT_NEWKEYSET) generates a error, in a WinXP

The error is hidden, I see nothing from gsec console, that's the bug.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 17/Dec/06 03:55 AM
It was pretty easy to fix this error in HEAD.

Unfortunately, there is no special LongJump class in 2.0. And I want to ask for other peolple opinions - what is better: backport this class to 2.0 (good backport requies multiple changes in the tree) or create gsec specific flag, notifying that gsec_exit() was called?

Dmitry Yemanov added a comment - 17/Dec/06 04:30 AM
What about catching Firebird::status_exception and checking for *ex.value() to distingiush between "long jump" usage and a status-based one?

Alexander Peshkov added a comment - 17/Dec/06 08:45 AM
Currently gsec_exit() in 2.0 throws std::exception(). And knows absolutely nothing about Firebird::status_exception.
Should we change it to become empty status_exception? In that case your suggestion will sooner work then not due to the fact that isc_arg_end is zero and we may use stuff_exception() with empty status_exception.

The dark side here is that when good status_vector, received in an old manner, is passed to stuff_exception(), vector's content may be destroyed in it. In head it's fixed with empty virtual LongJump::stuff_exception() and missing empty raise But in 2.0 loosing status_vector is quite possible - we do not test for empty status_exception before changing first element of status_vector.

Should it be fixed too?

Dmitry Yemanov added a comment - 17/Dec/06 09:47 PM
Consider calling Firebird::status_exception::raise() in gsec_exit() -- as we do in alice.cpp -- and then catchig the exception like this:

catch (const Firebird::status_exception& e) {
int exit_code = tdsec->tsec_exit_code;
if (e.value()) {
// Real exceptions are coming here
Firebird::CircularStringsBuffer<4096> localStrings;
e.stuff_exception(status, &localStrings);
GSEC_print_status(status, false);
exit_code = 127;

return exit_code;

I don't see how it could lose status vector data.

Alexander Peshkov added a comment - 18/Dec/06 01:23 AM
In this way it can loose non-Firebird exceptions, like std::bad_alloc. But appears there is a way to catch it too, using stuff_exception.

Alexander Peshkov added a comment - 18/Dec/06 02:33 AM
A bit ugly, but now it works in any case.