FLTK logo

STR #3028

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.