Skip to content

Memory leak in sap.ui.unified.Calendar specialDates #4167

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

Closed
jvanattedev opened this issue Nov 21, 2024 · 8 comments
Closed

Memory leak in sap.ui.unified.Calendar specialDates #4167

jvanattedev opened this issue Nov 21, 2024 · 8 comments
Assignees

Comments

@jvanattedev
Copy link

OpenUI5 version: 1.120.22 (SAPUI5)

Browser/version (+device/version): Chrome 1.130, Firefox 128.4.0

URL (minimal example if possible): I have a private repository on my github account. Ask me to add you (accountname) to the project.

Steps to reproduce the problem:

  1. Start the project
  2. Start clicking in the Calendar
  3. The memory usage keeps rising. The browser window eventually crashes.
  4. Initial interactions already take seconds to complete.

Any other information? (attach screenshot if possible)
memoryleak

It seems to be located when you add specialDates to the calendar.

@ivoplashkov ivoplashkov self-assigned this Nov 21, 2024
@ivoplashkov
Copy link
Member

Hello @azharnh,

Thank you for reporting this issue.

In order to help us identify and resolve the issue effectively, could you please provide an isolated example (e.g., a minimal reproducible scenario using tools like jsbin? This would allow us to determine whether the problem lies in the sap.ui.unified.Calendar implementation itself or if it is being influenced by the application.

Additionaly, since I’m not the only one who will be investigating this, we will need access for all involved parties, ideally without requiring account-specific additions.

Best regards,
Ivaylo

@ivoplashkov ivoplashkov removed their assignment Nov 22, 2024
@jvanattedev
Copy link
Author

I had to spend quite some time cleaning the data used. The repository is now public: https://github.com/jvanattedev/memleak. The cleaned data set is significantly smaller, hence the performance effect is less noticable. The memory usage keeps rising, though slower than before.

@jvanattedev
Copy link
Author

Are there any updates?

@flovogt
Copy link
Member

flovogt commented Dec 6, 2024

Thank you for sharing this finding. I've created an internal incident DINC0355517. The status of the issue will be updated here in GitHub.

@jvanattedev
Copy link
Author

Has there been any progress on this issue?

@flovogt
Copy link
Member

flovogt commented Apr 17, 2025

@unazko any news?

@unazko
Copy link
Contributor

unazko commented May 14, 2025

Hello @jvanattedev, @flovogt,

Apologies for the late response.
This is an issue with the unified.Calendar control also reproducible with the latest ui5 version.
The getSpecialDates method in the calendar and the corresponding getSpecialDates in the month control are getting called in a loop.
The interesting part is that the number of special dates provided doesn't affect the number of getter calls,
but the number of months does.
For example in the default scenario we'll have 42 getSpecialDates calls in the the calendar and the same number in the month control.
If we have 4 months then we have 147 calls. The number of getSpecialDates calls increases linearly for each month added.
Also on each press over a date in the calendar we'll have the same number of calls.

I'll be working over a fix. Depending on the fix complexity we'll aim to transport it into ui5 1.120.

Best regards,
Boyan

@unazko
Copy link
Contributor

unazko commented May 19, 2025

Hello @jvanattedev,

The issue is now fixed with the 1.137 ui5 version with expected release in the mid of June.
We've also triggered a fix transport for 1.120. I'll post an update about the patch number and expected delivery date,
once the transport gets merged.

Best regards,
Boyan

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

No branches or pull requests

4 participants