| Summary: | Segfaults when opening the image viewer [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Brad Hubbard <bhubbard> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, than |
| Priority: | NOR | ||
| Version: | 2.4.1 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 3.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
First alternative patch using isInitialized member variable
Second alternative patch using existing firstImage member variable |
||
Created attachment 67470 [details]
Second alternative patch using existing firstImage member variable
Official Kipi-plugins 2.6.0 release is out since few days now : http://www.digikam.org/drupal/node/656 Please, check if this entry still valid, or update report accordingly. Thanks in advance. Gilles Caulier Can't reproduce this with kipi-plugins-2.9.0-3 |
Created attachment 67469 [details] First alternative patch using isInitialized member variable Version: 2.4.1 (using KDE 4.7.4) OS: Linux Steps to Reproduce: 1.Open gwenview 2.Go to Plug-in 3.then tools 4.OpenGL image viewer Reproducible: Always Steps to Reproduce: See above Actual Results: segfault Expected Results: No segfault but not sure about exactly what should happen? I have created two possible solutions (patches) to this issue and will attach them. I can provide a core if required. That problem is caused by the fact that when the menu item is clicked with no image open a ViewerWidget is instantiated but ViewerWidget::initializeGL() never gets called and the tex member variable (GLuint[3]) is not initialized properly. When the destructor is invoked it calls glDeleteTextures(1,tex) and crashes when accessing the invalid tex. My first patch uses a dedicated variable (isInitialized) to represent the initialized state and is more intuitive IMHO. The second approach is more economical and uses an existing member variable (firstImage) to accomplish the same. This required moving some of the code in the constructor that should have no side effects but this approach is less intuitive and maybe prone to the problems of using one mechanism to accomplish multiple objectives?