# Request for Bug Confirmation in Issues **URL:** \ **Category:** Library Questions\ **Tags:** questions\ **Created:** [April 28, 2023, 2:45pm UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502 "2023-04-28T14:45:27Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![ailanxier](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@ailanxier](https://openfhe.discourse.group/u/ailanxier)\ **Post date:** [April 28, 2023, 2:45pm UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502/1 "2023-04-28T14:45:28Z")
Hello, I hope this message finds you well. During the past two weeks, I have raised several issues on GitHub as follows, but I have not received any response. - [Openfhe\_error failed to catch an not\_available\_error while attempting to call EvalRotate() on an uninitialized index](https://github.com/openfheorg/openfhe-development/issues/362) - [Manual Configuration of SetRingDim() Causes Subsequent Crash](https://github.com/openfheorg/openfhe-development/issues/363) - [Setting a Larger Value in SetScalingModSize() Leads to Incorrect Results and Crash](https://github.com/openfheorg/openfhe-development/issues/364) - [Simultaneous SetKeySwitchTechnique(BV) and SetEncryptionTechnique(EXTENDED) Causing Crashes in BGV/CKKS](https://github.com/openfheorg/openfhe-development/issues/366) - [Heap-buffer-overflow caused by out-of-bounds vector access when using SetScalingTechnique(FIXEDAUTO) in BGV](https://github.com/openfheorg/openfhe-development/issues/374) - [Setting Lower MultiplicativeDepth, FirstModSize or BatchSize Results in Incorrect EvalMult Output](https://github.com/openfheorg/openfhe-development/issues/376) I understand that you may be busy, but I wanted to kindly inquire if there has been any progress or if there is any additional information needed from my end to confirm the bugs. It is relatively easy to reproduce these bugs using the examples provided by OpenFHE. Due to the imminent submission of the preliminary draft of my graduation thesis, I need bug confirmations to validate effectiveness of my work in software testing. Thanks for your attention to this matter and the contributions you have made to OpenFHE. 😀 ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [April 28, 2023, 9:57pm UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502/2 "2023-04-28T21:57:07Z")
Hi @ailanxier Thank you for submitting the issues. We are more active in the OpenFHE discourse forum and typically create issues ourselves when the bugs are confirmed. Moreover, the past week has been crazier than usual. I saw your issues yesterday and am planning to look at them (and assign them to the next bugfix version v1.0.4 if needed) in the next few days. ---
**Author:** ![ailanxier](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@ailanxier](https://openfhe.discourse.group/u/ailanxier)\ **Post date:** [April 29, 2023, 1:23am UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502/3 "2023-04-29T01:23:17Z")
I see. Thank you for your response and your diligent contribution! 👍 ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [April 29, 2023, 10:41pm UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502/4 "2023-04-29T22:41:07Z")
Hi @ailanxier I’ve examined all issues and assigned 5 of them to the next bugfix release (v1.0.4). I closed one of them as it is already covered by another issue for v1.0.4. ---
**Author:** ![ailanxier](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@ailanxier](https://openfhe.discourse.group/u/ailanxier)\ **Post date:** [May 2, 2023, 2:25pm UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502/5 "2023-05-02T14:25:47Z")
Hi @ypolyakov Thanks for your quick confirmation. I still have some points of confusion in [issue#364](https://github.com/openfheorg/openfhe-development/issues/364). Could I understand that, in the CKKS scheme, even if the decryption process can be completed without any error messages, there is no universal method to verify whether the results are correct within a certain margin of error? I have met the same issue in the BGV scheme as well, where evident errors occur in the results under certain unreasonable parameter settings, yet the decryption process is still successful. Initially, I had expected an exception to be thrown indicating decryption failure. But due to the limitation of “the underlying messages are encrypted”, is it currently not possible to capture such exceptions? ---
**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\ **Post date:** [May 2, 2023, 9:12pm UTC](https://openfhe.discourse.group/t/request-for-bug-confirmation-in-issues/502/6 "2023-05-02T21:12:06Z")
Any checks like this would have to be written by the application developer, e.g., using a reference implementation in the clear. These logical checks require understanding the context of the application, acceptable margin of error, etc. For instance, the user can select a plaintext modulus in BGV that is not large enough. When integers are added, an overflow can occur, resulting in incorrect results. The library does not know that this result is incorrect.