Quite tricky segfault.

[Hannu Vuolasaho]

Hi!

Something breaks my application and I hope someone can give some info
how the problem might be born.

I have
class UiLayout: public Fl_Double_Window {
....
private:
static const int menuH = 30;
static const int widgetSeparation = 2;
void init(int W, int H);
UiMenubar * _menubar;
CenterTile * _center;
StatusBar * _statusbar;
}
where CenterTile is
class CenterTile: public Fl_Double_Window ...

And after some inheritance and classes I get to Fl_Tiles where my
widgets are....

Now. I have UiLayout * ui = new UiLayout;

And somewhere in init() (my function, called from ctor) it says new CenterTile.

And then it screws up. * ui's FL::Double_Window::icon_->count gets
some junk value. The icon_->icons stays the same. The segfault comes
when show() is called and for-loop runs away. And if I change count in
debugger to 0, everything works.

Where does icons_ come and what sets their count? I found
memset(icon_, 0, sizeof(*icon_))from Fl_Window constructor so
something change it. Or is this compiler problem?
g++ --version
g++ (GCC) 5.1.0

Sorry for bad question, I hope someone else has seen this kind of
behaviour and can help. I try to make small test case, but taking it
to basics isn't that easy. And I have feeling that I cast something
wrong. Or it might be X related feature.

Best regards,
Hannu Vuolasaho

[Edzard Egberts]

> class UiLayout: public Fl_Double_Window

> class CenterTile: public Fl_Double_Window

Do you want to mangage more than one window, or do you want to manage a
layout inside of a window? In second case you should replace
"CenterTile: public Fl_Double_Window" by "CenterTile: public Fl_Group",
because a Fl_Window is mapped to an operating system window and you
can't place such kind of window inside of such kind of window.

[Albrecht Schlosser]

On 22.07.2015 14:30 Edzard Egberts wrote:
>> class UiLayout: public Fl_Double_Window
>
>> class CenterTile: public Fl_Double_Window
>
> Do you want to mangage more than one window, or do you want to manage a
> layout inside of a window? In second case you should replace
> "CenterTile: public Fl_Double_Window" by "CenterTile: public Fl_Group",

Agreed mostly so far. Although there may be reasons to use an Fl_Window
inside another Fl_Window (e.g. relative coordinate space).

> because a Fl_Window is mapped to an operating system window and you

True as well.

> can't place such kind of window inside of such kind of window.

That's not true. You can. See the test/subwindow.cxx demo program.
Although this one uses Fl_Window (not Fl_Double_Window). I did a short
test, and it works with Fl_Double_Window as well.

Would be interesting though if anything changed in the OP's case if he
used Fl_Window instead of Fl_Double_Window.

[Albrecht Schlosser]

The icon handling was changed significantly in FLTK 1.3.3 (or maybe even
later in svn = FLTK 1.3.4). You did not mention which FLTK version you
are using. If it is FLTK 1.3.3 (or earlier), can you please try the
current svn version or a recent snapshot to rule out old bugs?

Are you somehow setting up a window icon? There are many different ways
to do so, hence this information is important. If you don't, then the
windows icon(s) should probably not be set at all, and count should be 0
(off the top of my head - maybe there is a default icon, but I don't
think so).

> Or is this compiler problem?
> g++ --version
> g++ (GCC) 5.1.0

I don't think so, but you never know. I never used gcc/g++ 5.x before,
the latest version I ever used was 4.9.x.

What OS and version?

> Sorry for bad question, I hope someone else has seen this kind of
> behaviour and can help. I try to make small test case, but taking it
> to basics isn't that easy. And I have feeling that I cast something
> wrong. Or it might be X related feature.

Yep, you did not provide enough information to find out anything
concrete. A small test case would be very helpful.

If you can't reduce the issue to a small test case it's very likely that
you are using an uninitialized variable or wrong pointer in your code
and overwriting something elsewhere.

[Edzard Egberts]

Albrecht Schlosser wrote:
> On 22.07.2015 14:30 Edzard Egberts wrote:

>> can't place such kind of window inside of such kind of window.
>

> That's not true. You can. See the test/subwindow.cxx demo program.
> Although this one uses Fl_Window (not Fl_Double_Window). I did a short
> test, and it works with Fl_Double_Window as well.

Is this a "Wow it works!" and could cause problems in spite of that, or
is this a "Of course it works!" and no problems in sight?

I don't trust in the "window in window", because this doesn't feel
straight forward to me. A basic window and fl toolkit does it's things
inside of it, feels much more comfortable to me.

[MacArthur, Ian (Selex ES, UK)]

> > That's not true. You can. See the test/subwindow.cxx demo program.
> > Although this one uses Fl_Window (not Fl_Double_Window). I did a
> short
> > test, and it works with Fl_Double_Window as well.
>
> Is this a "Wow it works!" and could cause problems in spite of that, or
> is this a "Of course it works!" and no problems in sight?

It is by design, not by chance.

Although window-in-a-window would not be the recommended choice, it should generally work (and in some cases is "required", e.g. for GL on some platforms, or for embedding output from other tools such as video streaming and such...)

On the other hand, some platforms do not really support the concept of nested windows (I think OSX may be in that camp) so we had to make quite some effort to get it to work consistently across platforms.

> I don't trust in the "window in window", because this doesn't feel
> straight forward to me. A basic window and fl toolkit does it's things
> inside of it, feels much more comfortable to me.

As a general rule, I'd favour nesting groups inside windows, but nesting of windows is possible and *should* work.




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Albrecht Schlosser]

On 22.07.2015 14:59 Edzard Egberts wrote:
> Albrecht Schlosser wrote:
>> On 22.07.2015 14:30 Edzard Egberts wrote:
>>> can't place such kind of window inside of such kind of window.
>>
>> That's not true. You can. See the test/subwindow.cxx demo program.
>> Although this one uses Fl_Window (not Fl_Double_Window). I did a short
>> test, and it works with Fl_Double_Window as well.
>
> Is this a "Wow it works!" and could cause problems in spite of that, or
> is this a "Of course it works!" and no problems in sight?

It definitely SHOULD work.

[ I saw that Ian posted something similar meanwhile. Anyway ...]

I remember that we changed many window types in test/*.cxx from
Fl_Window to Fl_Double_Window, and I don't remember why the subwindow
program was not changed.

Faint memory says that we experienced a few incompatibilities though, so
we reverted /some/ changes to use Fl_Window again. AFAICT this was
related to embedded GL windows though, hence all OpenGL programs in the
test folder might use Fl_Window instead of Fl_Double_Window.

Nothing in my memory tells me that bare Fl_Double_Windows should not be
nested.

As a side note: at that time (when we changed Fl_Window to
Fl_Double_Window in test/<many>.cxx) OS X used an own implementation of
"subwindows". This was changed recently to use real OS windows as on all
other platforms. Maybe this changed something - to the good or bad side,
I don't know (and I don't claim anything). I hope that /if/ it changed
anything in the behavior, then only to the good side.

> I don't trust in the "window in window", because this doesn't feel
> straight forward to me. A basic window and fl toolkit does it's things
> inside of it, feels much more comfortable to me.

There are exceptions though. Fl_Gl_Window is certainly one of them.
Fl_Cairo_Window is another example.

I agree that I'd use Fl_Group inside a window whenever possible, but
nested windows are a design feature of FLTK, and so you should be able
to rely on it. If anything goes awry with nested windows then we should
fix it or document the issue.

That said, I don't know if the issue "Fl_GL_Window does not work as
subwindow in Fl_Double_Window" is documented - if it is true at all (I
don't remember all the details).

[Albrecht Schlosser]

On 22.07.2015 15:06 MacArthur, Ian (Selex ES, UK) wrote:

> On the other hand, some platforms do not really support the concept of nested windows (I think OSX may be in that camp) so we had to make quite some effort to get it to work consistently across platforms.

AFAICT all platforms use real subwindows now (off the top of my head).
Manolo changed OS X subwindows in 1.3.4 (current svn).

[Hannu Vuolasaho]

SVN from last night. on archlinux x86_64

>
> Are you somehow setting up a window icon? There are many different ways to
> do so, hence this information is important. If you don't, then the windows
> icon(s) should probably not be set at all, and count should be 0 (off the
> top of my head - maybe there is a default icon, but I don't think so).

When I drove in to this problem there is the memset to zero and it
should stay zero. I haven't touch icons.

>
>
> Yep, you did not provide enough information to find out anything concrete. A
> small test case would be very helpful.
>
> If you can't reduce the issue to a small test case it's very likely that you
> are using an uninitialized variable or wrong pointer in your code and
> overwriting something elsewhere.

First overwrite happens on return from new UiMenubar and results are
on debugger window.
The real bad stuff happens when centertile is created and count is overwritten.

IMHO this should not happen and is rather weird side-effect.

Hannu Vuolasaho

[MacArthur, Ian (Selex ES, UK)]

> First overwrite happens on return from new UiMenubar and results are
> on debugger window.
> The real bad stuff happens when centertile is created and count is
> overwritten.

I think you are going to have to produce a small test example that exhibits the failure - I'm not able to see what is going on that might be causing this...

[Hannu Vuolasaho]

2015-07-22 16:47 GMT+03:00 MacArthur, Ian (Selex ES, UK) wrote:
>
>> First overwrite happens on return from new UiMenubar and results are
>> on debugger window.
>> The real bad stuff happens when centertile is created and count is
>> overwritten.
>
> I think you are going to have to produce a small test example that exhibits the failure - I'm not able to see what is going on that might be causing this...

I tried same segfaulting code on Ubuntu 14.04 box and it worked. So
this is non-fltk problem. But in deed tricky segfault.

I'll try in some better time tomorrow to write test case for Arch.

I was also able to fix this segfault but not get to the reasons behind this.

In my main() I had startSystem(); which initialized libraries etc...
Libraries called back to my functions and initialization was chained.
I changed to main() ui = new UiLayout; startSystem(); and removed it
from last init function and it worked.

If I separate those components and they work nicely.

Hannu