Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Extra libraries, Code snippets, applications etc. » OS Problems etc., Win32, POSIX, MacOS, FreeBSD, X11 etc » Untrivial EditString bug(?) in FreeBSD(and may be all POSIX)
Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20725] Wed, 01 April 2009 23:21 Go to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

I develop some app for both Windows and FreeBSD systems. Last code changes revealed very untrivial (from my point of view) behaviour in POSIX systems. When compiled and linked, application is executed in Windows flawlessly without any runtime errors. In FreeBSD the same application causes segmentation fault on startup.
I dag into the source of this fault.
So the fault happens when static EditString class member is appeared.
It looks like this:
//.h
class AAA {static EditString es;};
//.cpp
//...
EditString AAA::es;

Debugger shows call stack when this fault happens:
Quote:

XInternAtom () from /usr/local/lib/libX11.so.6
Upp::XAtom ()
Upp::Ctrl::IsCompositedGui ()
Upp::Ctrl::Ctrl ()
Upp::EditField::EditField ()
Upp::EditValue<Upp::WString, Upp::ConvertString>::EditValue ()
Upp::EditString::EditString ()


If I make this EditString non-static, application runs flawlessly without faults. It seems like something in EditString ctor causes big segmentation fault when executed on program start, in the globals initialization period.

[Updated on: Wed, 01 April 2009 23:23]

Report message to a moderator

Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20754 is a reply to message #20725] Sat, 04 April 2009 19:21 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

I`ve made trivial testcase:
#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class TestWindow : public TopWindow
{
};

EditString es; //if you comment it, everything is OK

GUI_APP_MAIN
{
	TestWindow().Run();
}
Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20755 is a reply to message #20754] Sat, 04 April 2009 20:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Sat, 04 April 2009 13:21

I`ve made trivial testcase:
#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class TestWindow : public TopWindow
{
};

EditString es; //if you comment it, everything is OK

GUI_APP_MAIN
{
	TestWindow().Run();
}



Because es is global.

For some untrivial subtle reasons, it is not possible to have widgets as global variables (they get initialized too soon).

Mirek
Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20756 is a reply to message #20755] Sat, 04 April 2009 22:39 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

IMO this fact [slightly] violates "everything belongs somewhere" rule, which is one of the mains of U++.
Maybe it will be wiser to have everything possible to be static (global), but the real initialization should be postponed to the first draw/paint attempt? Of maybe it would be wiser to have internal controls list, which is initialized when it is possible?

In any way, this is crucial development information. And IMO it should be resided somewhere to be seen by everyone (i.e. in the beginning of GUI tutorial).

[Updated on: Sat, 04 April 2009 22:53]

Report message to a moderator

Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20764 is a reply to message #20756] Sun, 05 April 2009 14:50 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Sat, 04 April 2009 16:39

IMO this fact [slightly] violates "everything belongs somewhere" rule, which is one of the mains of U++.
Maybe it will be wiser to have everything possible to be static (global), but the real initialization should be postponed to the first draw/paint attempt? Of maybe it would be wiser to have internal controls list, which is initialized when it is possible?

In any way, this is crucial development information. And IMO it should be resided somewhere to be seen by everyone (i.e. in the beginning of GUI tutorial).


I agree with both. I too consider it rather a flaw; however it is one that is harder to fix while in practice fixing it would bring only very little benefits.

Mirek
Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20765 is a reply to message #20764] Sun, 05 April 2009 14:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
Added to U++ traps and pitfals...

Mirek
Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #20772 is a reply to message #20765] Sun, 05 April 2009 23:22 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Thank you!

Mirek, could you please tell what is your typical solution to avoid static controls? How do you then manage controls shared between a number of objects of the same class.

To move this question into more practical area, I`ll post the exact situation.

Application works with a scheme. Scheme consists of scheme elements. Elements are of different types. Clicking some element on the scheme drawn shows edit control in the toolbar. And the type of this controls depends on element type.
So I have a number of SchemeElement descendants
SchemeElementAAA : SchemeElement
SchemeElementBBB : SchemeElement
SchemeElementCCC : SchemeElement
and each of these classes has shared control (which is of course static).

There is of course a number of possible solutions, but IMO it would be wiser to hear one from a man who solved it many times before.

[Updated on: Sun, 05 April 2009 23:24]

Report message to a moderator

Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #21461 is a reply to message #20772] Thu, 21 May 2009 16:48 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12105
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Sun, 05 April 2009 17:22

Thank you!

Mirek, could you please tell what is your typical solution to avoid static controls? How do you then manage controls shared between a number of objects of the same class.




Lazy intitalization:

EditString& GlobalEditor()
{
static EditString x;
return x;
}

(Sorry for the very late reply Wink

Mirek
Re: Untrivial EditString bug(?) in FreeBSD(and may be all POSIX) [message #21484 is a reply to message #21461] Fri, 22 May 2009 14:11 Go to previous message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Simple & effective. Thanks!
Previous Topic: Using DMC
Next Topic: Cross Compile HowTo?
Goto Forum:
  


Current Time: Mon Nov 18 02:25:05 CET 2019

Total time taken to generate the page: 0.02272 seconds