| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3028
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 2 - Specific to an operating system |
Subsystem: | Core Library |
Summary: | SIGSEGV, Segmentation fault when flush() before show() |
Version: | 1.3.2 |
Created By: | andy1978 |
Assigned To: | AlbrechtS |
Fix Version: | 1.3.3 (SVN: v10095) |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | andy1978 05:43 Jan 11, 2014 |
| Attached you find my debug session and sample code
#include <FL/Fl.H> #include <FL/Fl_Double_Window.H>
class img_win : public Fl_Double_Window { private:
public: img_win(int x, int y, int w, int h); };
img_win::img_win(int x, int y, int w, int h) :Fl_Double_Window(x, y, w, h, "flush test") { Fl::visual(FL_RGB); flush(); }
int main() { img_win *tmp = new img_win(5,5,200,150); tmp->show(); Fl::run(); delete(tmp); return EXIT_SUCCESS; }
/* $md5sum fltk-1.3.2-source.tar.gz 9f7e707d4fb7a5a76f0f9b73ff70623d fltk-1.3.2-source.tar.gz
./configure --enable-debug fltk-config --compile main.cc gdb ./main
(gdb) run Starting program: /home/andy/src/octave-forge/octave-image-acquisition/fltk_flush_bug/main [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault. 0x0000000000423839 in Fl_Window::make_current (this=0x67f010) at Fl_x.cxx:2147 2147 if (!gc) gc = XCreateGC(fl_display, i->xid, 0, 0); (gdb) bt #0 0x0000000000423839 in Fl_Window::make_current (this=0x67f010) at Fl_x.cxx:2147 #1 0x0000000000409184 in Fl_Double_Window::flush (this=0x67f010, eraseoverlay=0) at Fl_Double_Window.cxx:372 #2 0x000000000040915f in Fl_Double_Window::flush (this=0x67f010) at Fl_Double_Window.cxx:361 #3 0x00000000004054f8 in img_win::img_win (this=0x67f010, x=5, y=5, w=200, h=150) at main.cc:16 #4 0x0000000000405550 in main () at main.cc:21 (gdb) list 2142 GC fl_gc; 2143 2144 // make X drawing go into this window (called by subclass flush() impl.) 2145 void Fl_Window::make_current() { 2146 static GC gc; // the GC used by all X windows 2147 if (!gc) gc = XCreateGC(fl_display, i->xid, 0, 0); 2148 fl_window = i->xid; 2149 fl_gc = gc; 2150 current_ = this; 2151 fl_clip_region(0); (gdb) print gc $1 = (GC) 0x0 (gdb) print fl_display $2 = (Display *) 0x68e8b0 (gdb) print i->xid Cannot access memory at address 0x0 */
Debian GNU/Linux 7.3 (wheezy) Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux | |
|
#2 | AlbrechtS 14:40 Jan 14, 2014 |
| It is definitely a programming error to call Fl_Window::flush() (or any subclass's flush method) in the c'tor of the window object, because it is not yet shown and there is nothing that can be drawn at this time.
So, what is it what you want to tell us? Do you consider this a bug that should be fixed, or did you want help fixing your program? If the latter, don't call flush() yourself. The first show() will eventually draw() the window as well, so you don't need to call flush() yourself.
If you wanted to point out that there is a potential bug, then thanks for the debug log. It shows what's going on, and from what I can see in this case "i" must probably be NULL. W/o looking at the code this appears to be plausible since no system window object exists at that time.
That said, we could try to check this and either log an error or return silently if this happens. | |
|
#3 | andy1978 22:24 Jan 14, 2014 |
| Albrecht, it should be apparently to you that I don't need you to fix my code. I think a library like libfltk should never segfault if a logical order isn't considered. Instead it should return silently or thow an error/warning. In this case returning silently would be a good approach.
Reading your reply again and again I think I can hear a rude attitude, am I wrong?
Regards, Andy | |
|
#4 | AlbrechtS 03:11 Jan 15, 2014 |
| Andy, there was no intention to be rude in any way. I apologize if it sounded so. English is not my native language.
My problem was that we sometimes get posts in the bug system that ask for help in the user's code. I could not clearly identify your intention by reading your post, hence my question - and I also tried to give you a hopefully correct solution if you were asking for help.
OTOH, if it was a request to fix a bug, yes, then I wrote what I thought we could do. I'll take a look into the code more deeply and see how we can fix it. I assume that this will be a silent exit, as you suggested. I don't know the best solution yet.
Thanks again for the good bug report and the debug log, it was easy to spot the crash point in the code.
PS: for later reference: even if the crash point is in the X specific code, this issue is perhaps not restricted to X11. | |
|
#5 | andy1978 10:48 Jan 16, 2014 |
| Hi Albrecht, sorry if I've misinterpreted your answer and thank you for your help. I'll try to be more precise the next time I write here.
Regards, Andy | |
|
#6 | AlbrechtS 16:13 Feb 06, 2014 |
| Fixed in Subversion repository.
The fix is twofold: (1) if Fl_Window::flush() is called, this is ignored silently (2) if Fl_Window::make_current() is called directly, but the window is currently not shown(), then the program will be terminated with an error message. The latter is necessary because returning from make_current() would leave the program in a state where it would expect to have a valid drawing context.
Please confirm that this fixes the issue for you. I tested it under Linux and Windows with Cygwin and MinGW.
Thanks for the bug report. | |
|
#7 | chris 00:14 Feb 09, 2014 |
| Thinking about (2): Would it not suffice to just prevent Fl_Window::make_current() from crashing, when the window is not shown? The application could check its success by comparing with Fl_Window::current() if it really cares:
e.g.
win->make_current(); assert( Fl_Window::current() == win );
I don't feel well with the thought, that a library function can terminate my application if it's called wrongly.
In my opinion an Fl:error() message would be enough.
Just my 2 cents.. | |
|
#8 | AlbrechtS 08:11 Feb 09, 2014 |
| Chris, thanks for reading this and for your suggestion. Maybe you're right, and we should only document the issue, post only an error message with fl_alert (as is done now anyway), and then return. The program(mer) would be responsible for any later crashes...
This is a very rare condition, and maybe nobody ever cared, or their program crashed anyway. Now we have at least an error message before the program would access invalid data, if the error was not catched, for instance as Chris suggested.
Question to others: Should we remove the Fl::fatal() call which would terminate the application and let the function return with an invalid drawing context, as suggested by Chris? | |
|
#9 | ianmacarthur 14:59 Sep 04, 2014 |
| Do we want to close this one? Or go with Chris's suggestion to handle the "error" case differently? | |
|
#10 | AlbrechtS 06:12 Sep 06, 2014 |
| Well, I asked an nobody replied - meanwhile I think we could do as Chris suggested.
It's "my" STR anyway, so I'll take a look and change it, if nobody writes something different during the next days.
As I wrote before, this should not happen anyway, because it can be considered a programming error. It's only a matter of _how_ the program will be terminated (a) with Fl::fatal() when calling make_current() or (b) when drawing w/o a valid drawing context.
Ian, what is your opinion? | |
|
#11 | ianmacarthur 15:02 Sep 09, 2014 |
| I was happy with your fix as it was; let's just do that and close this one? | |
|
#12 | AlbrechtS 06:51 Sep 10, 2014 |
| Yep, now that you wrote "something different" I'm with you and will close the STR now.
If there's someone who complains about killing the program after a dedicated error message in such a border case, this person may file another STR.
Closed w/Resolution. | |
[ Return to Bugs & Features ]
|
| |