When server gets unavailbale, client does not perform detach correctly [CORE3269] #3637
Assignees
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Modified by: @AlexPeshkoffVersion: 3.0 Initial [ 10301 ] summary: isc_detach_database => memory leaks => When server gets unavailbale, client does not delete objects correctly |
Modified by: @AlexPeshkoffsummary: When server gets unavailbale, client does not delete objects correctly => When server gets unavailbale, client does not perform detach correctly |
|
Commented by: @AlexPeshkoff What about 2.5 - I did not test ancient 2.5.0, but in current snapshots behavior is correct: in case of network error isc_detach_database() succeeds writing a record to the log file. Handle is set to 0. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Alpha 1 [ 10331 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Submitted by: vander clock stephane (arkadia)
if we call isc_detach_database and for exemple the firbird server was crashed before then isc_detach_database not free the resource used by the DBhandle
It's confirmed by Alex peshkoff :
"I confirm presence of a problem here.
Moreover, there is a small memory leak.
Please add bug to the tracker."
I also thing it's the same for the transaction ....
also i thing that it's little confusing than in case of exception that the DBhandle is not set to nil ...
leaving it to point to a not null value can mean it is not free ... (because what the purpose to
free it and to not set it to null in case of exception ?)
Commits: 445bd69
The text was updated successfully, but these errors were encountered: