| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3235
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Segmentation fault in Fl_Preferences |
Version: | 1.3-current |
Created By: | jjboia |
Assigned To: | matt |
Fix Version: | Will Not Fix |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | jjboia 12:59 Jun 23, 2015 |
| I traced a segmentation fault in my app to a problem with the Fl_Preferences::Node destructor ~Node() as well as its deleteAllChildren() method. The best way to handle destroying a linked list is to destroy the first item and have its destructor destroy the next one, and so on. Modified code for Fl_Preferences.cxx is supplied to demonstrate the fix which resolved my core dump. | |
|
#2 | AlbrechtS 10:33 Feb 12, 2019 |
| Assigned software version 1.3-current.
Given the time of the report this was likely 1.3.3, released Nov 03 2014.
@OP (jjboia): can you tell if this issue still exists in 1.3.5 (current release 1.3.5rc1) and/or in 1.4.0 (current development - you may download the latest snapshot and test).
If the bug is still present, can you provide a short, self-contained demo program that shows the issue? TIA. | |
|
#3 | AlbrechtS 10:35 Feb 12, 2019 |
| ... or can you provide instructions how to reproduce the fault? | |
|
#4 | jjboia 10:39 Feb 12, 2019 |
| I don't think I can supply a test case. The large program used the Python API and that was what exposed the memory error. I will check to see if the FL_Preferences class still contains the old cleanup code. | |
|
#5 | AlbrechtS 11:12 Feb 12, 2019 |
| Thanks, your report and your further help is very much appreciated. | |
|
#6 | jjboia 08:30 Nov 05, 2019 |
| I am attaching a git diff so you can patch the current version of Fl_Preferences.cxx. Please let me know if you have questions about it. | |
|
#7 | matt 08:18 Jan 18, 2022 |
| Even though this STR is very old:
I checked the deletion code and added a few security measures, but I can't see anything that is wrong in principle.
A node should not delete its next node recursively. Nodes are stored in the parent group, so the parent group must be the authority to decide if a single node is deleted, or all children.
This makes especially sense if we were ever to move to std::vectors to store a list of child nodes. | |
|
#8 | matt 08:20 Jan 18, 2022 |
| I can't find a bug in the code, and even with memory guards enabled, I do not get a crash in my test code. | |
[ Return to Bugs & Features ]
|
| |