| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2004
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Image Support |
|---|
| Summary: | 2 fixes for img->release() in Fl_Help_View.cxx |
|---|
| Version: | 1.3-current |
|---|
| Created By: | markcw |
|---|
| Assigned To: | fabien |
|---|
| Fix Version: | 1.3-current (SVN: v6744) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | markcw
16:30 Jul 15, 2008 |
| A couple of checks added to Fl_Help_View.cxx not by me but by Sebastian Hollington. The checks fix crashes which occur when a broken image is freed. It is tested in Ubuntu but probably applies to all OS.
The fixes are shown below and the modified Fl_Help_View.cxx is attached.
// Line 890 in Fl_Help_View::draw()
if (img) {
img->draw(xx + x() - leftline_,
yy + y() - fl_height() + fl_descent() + 2);
//Seb was here - freeing broken_image causes an XServer XFreePixmap crash.
if((void*)img!=&broken_image) img->release();
}
// Line 2365 in Fl_Help_View::free_data()
if (get_attr(attrs, "SRC", attr, sizeof(attr))) {
// Release the image twice to free it from memory...
img = get_image(attr, width, height);
//Seb was here - freeing a broken_image causes an XFreePixmap crash.
if((void*)img!=&broken_image){
img->release();
if(img->refcount() > 0) img->release();
}
} | |
| |
| #2 | matt
08:32 Jul 18, 2008 |
| Should be applied to 1.3 because 1.1.9 is final. | |
| |
| #3 | fabien
08:16 Aug 26, 2008 |
| Fixed in Subversion repository.
Tested & Working on Mac OS X, WinXP, Linux.
Thanks Mark and Seb, for your feedback and suggestions. | |
| |
| #4 | matt
14:35 Apr 07, 2009 |
| Hmm, why is the code limited to X11 in one case and limited to X11 and WIN32 in the next? Maybe there is no crash on Apple, but I beleive that the problem exists in al instances, because it is simply wrong to free a statically created class, right? Or is there something I am no seeing? | |
| |
| #5 | AlbrechtS
14:54 Apr 07, 2009 |
| You're right, I did just fix this, but I did not (yet) update this STR. This was one of the reasons why I delayed fixing STR #2163.
The current svn r6744 should be okay (r6745 for FLTK 1.1).
I documented details in the code (see get_image). | |
| |
| #6 | matt
15:05 Apr 07, 2009 |
| Yes, thanks for ficing it in 1.1. In 1.3, Fabien put the "if broken_image"-code into an "#ifndef __APPLE__" and I was wondering why that is (that's what I get for jumping into bug fixing for a few hours: I have lost track of fixes ;-) | |
| |
| #7 | fabien
21:16 Apr 07, 2009 |
| I think I made it crash after the original patch, so I excluded it from osx as the fix did not seem to change anything on osx anyway. That said, I think that what crashed osx was a particular sequence of img->release() afair (it is old!) and of course I agree the static var. should not be released in any platform.
I think that the ref counting is ok now from what I saw (removal of unconditional weird img->release() sequences) so I'm confident with the recents mods :-) | |
| |
| #8 | AlbrechtS
00:18 Jul 03, 2009 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
