Board index FlightGear Support Compiling

Segfault in SGVec3 constructor

Building FlightGear from source, and in the need for help?

Segfault in SGVec3 constructor

Postby MNwjtech » Sat Oct 20, 2018 10:45 pm

Start of any flightgear program caushes immediate segfault. I have debugged this, and want to make sure it is not a known problem.
Slackware 14.2 Linux 4.4.38, 4.4.88 and 4.4.153.
GCC 5.3.0 and 5.5.0.

In SimGear there is a SSScaleTransform that is derived from osg::Transform.
I have created several test objects to verify that any object derived from osg::Transform will segfault during the constructor of osg::Transform.

I built SimGear with debugging so I could follow it.
Other similar objects I made did not segfault.
A simple object with only two fields derived from osg::Transform, will also segfault in the constructor.

(Edit: Latest tests show that the segfault occurs in the SGVec3 constructor <template> which is a field in the same object.
My initial test objects were including the SGVec3 as the two fields.
One of the latest test objects derives from osg:::Transform without including the SGVec3 field and it does not segfault.
This test code is in a later post.)

This happens for OpenSceneGraph 3.4.0 and 3.5.5.
Currently I am trying to build Flightgear 2018.2.2, but have had build problems for every recent version of flightgear. I have not had a flightgear build since I had Linux 2.6.

It seems that it will segfault if the SGScaleTransform constructor is called from "new" but not if it is a static variable.
My most immediate solution is to modify the WrapperProxy, take out the "new" and make SGScaleTransform a static variable.
At least it does not segfault immediately.

This could be happening for several reasons:
1. There is a field in SGScaleTransform that is not initialized right away, and the constructor of osg:Transform is indirectly invoking a virtual function that leads to a SGScaleTransform function running and trying to use garbage values as a ptr. The garbage values on my system just happen to be more fatal than the garbage values on your system.
2. The osg::Transform is indirectly accessing some other structure that is not setup up yet, but it assumes that it is setup already.
3. The virtual setup on my GCC 5.5.0 compiler is different enough that some indirectly invoked virtual function calls in the osg::Transform is access the virtual call system before it is
able to handle them. Any virtual call during a constructor is capable of going wrong due to the strange setup rules for the virtual tables during constructors.
A properly written object should be careful to never call a virtual function during a constructor, not even indirectly. I suspect there is such a call in OpenSceneGraph.

There have been other postings about OpenSceneGraph segfaulting when some calls are done in the wrong order, so I think this is worthy of being made less fragile.

Is this some known and fixed in the next release (I doubt that, it been there for so many releases now) ?

Can you get OpenSceneGraph to fix their constructor to not call any virtuals ??

As I said previously, you might not get these segfaults just because your garbage values are not as fatal as the garbage values on my system.
It should not be accessing the garbage values in the first place.
Last edited by MNwjtech on Wed Oct 24, 2018 8:25 pm, edited 2 times in total.
MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm

Re: Segfault in osg::Transform constructor

Postby Hooray » Sun Oct 21, 2018 7:09 am

Hi & welcome,

that looks like a fairly thorough analysis already.
However, since these are the FlightGear forums, and since you are reporting an OSG related issue, it would obviously help if you could try to nail down this further.

Ideally, you would try to reproduce the issue using just OSG - i.e. by running a tiny self-contained OSG demo that contains the corresponding osg::Transform calls to see if the issue is specific to SimGear/FlightGear or if it can be reproduced with stock OSG.

Afterwards, you should know if the issue has anything to do with FlightGear's use of OSG or if it is unrelated, i.e. if you can reproduce the same issue using a standalone hello-world style application.

Obviously, that would also make it much easier to do any further troubleshooting, and you'd also have much better chances of getting support/feedback on the osg-users mailing list.

If you can repro the whole issue without involving SG/FG, you'd probably also want to share your exact compiler version including the settings used to build both, the compiler and the OSG program in question.

It might also matter whether you are using a pre-built compiler or if you have built your own. Depending on your findings, this issue might be a compiler issue or even a RAM issue.

http://www.openscenegraph.org/index.php ... 5-09-34-43
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11314
Joined: Tue Mar 25, 2008 8:40 am

Re: Segfault in osg::Transform constructor

Postby MNwjtech » Mon Oct 22, 2018 6:01 am

I have done a 3 hour memtest on this memory, and it is an entirely different set of memory sticks from when I first started tracking down the segfault issue.
I have tried two different compilers. I would not be surprised if this bug was compiler related. That usually comes from programming in the gray areas where it works for some compilers but not all compilers. I could try clang next, but that would not prove that useful. The code would still be buggy.

It is not going to fail when doing a simple test with OSG alone, as there have been other uses of OSG that have tested the simple usages. Also, because OSG is sensitive to how it is used, it will only show these specific faults under the specific context that FG has put it. It is known to segfault under certain setups. If the context is changed, then will like trying to debug OSG under entirely different circumstances, which would be mostly irrelevant to this usage in FG.

I tried building OSG and SimGear using "-ggdb", so I could step through the problem area and watch.

A break on Transform::Transform() does not trap, so I am not sure when that constructor gets run.
GDB says <pending> on the break, as if that library has not loaded yet.

It is still segfaulting within SGScaleTransform::SGScaleTransform(),
The execution of _scaleFactor(1,1,1) seems to have no effect, all the fields are still 0 when the segfault occurs.
I cannot step through that constructor because it is all done within a template.
The segfault points to the next line, which is _boundScale(1).

Some of the template code for SGVec3 looks suspicious.
It has a warning about "Avoid _data not initialized warnings" for GCC.
Trying to read through the templated SGVec3 is like trying to read APL. It uses templates within the templates.
Is all that just so they could derive SGVec3d and SGVec3f from a template.
I am just as suspicious that this SGVec3 constructor is fouling the stack or something, breaking the osg constructor.
This needs to be written in a more rugged fashion, with less of the language feature abuse.
I need to replace that SGVec3 with something I can trust before I can debug this properly.
I expect that will make the symptoms change radically, or it may have no effect, but at least I will be able to step through the constructor and confirm it executes.
That is likely going to take a week to unravel the mess, and I don't that that kind of time right now.

I may try more test objects. I think the others I tested had SGVec3 fields in them, which might have contributed to the failures.

Ugh, found the simd4 code. If that is issuing SSE2 instructions to set a value in the constructor, then that is suspicious too.
Ugh2, they should not use loops for 3 and 4 item vectors, it is not worth setting up the loop. The vector code should be unrolled. It is also a waste of effort making them templates in the first place, that just makes it more difficult. You use templates when you cannot predict what the type or other some other parameters might be, such as a support library for lists.
With only two possibilities, it should have just been copied.
With so many variations, it is also possible the simd code is broken for my Athlon64 CPU.
MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm

Segfault in SGVec3 constructor

Postby MNwjtech » Wed Oct 24, 2018 2:53 am

The problem is not osg::Transform, it is SGVec3.
I caught one of the segfaults at math/SGVec3:58
Code: Select all
{ _data = simd4_t<T,3>( x, y, z); }


Please notice, that the test objects ST92, ST93, ST97 only segfault in the constructor when it is invoked from "new".
They do not segfault when created as static objects, even though the same constructor is run and can be stepped through in the debugger..

I would attach this file, but don't see a way to do that.
So this is my test code (as a patch file), with the pertinent comments.

Code: Select all
Only in source/: build
diff -r -U4 orig/simgear-2018.2.2/simgear/scene/model/SGScaleTransform.cxx source/simgear/scene/model/SGScaleTransform.cxx
--- orig/simgear-2018.2.2/simgear/scene/model/SGScaleTransform.cxx   2018-06-03 13:56:36.000000000 -0500
+++ source/simgear/scene/model/SGScaleTransform.cxx   2018-10-23 20:41:33.000000000 -0500
@@ -30,8 +30,100 @@
 #include <simgear/scene/util/OsgMath.hxx>
 
 #include "SGScaleTransform.hxx"
 
+
+
+SG_ST1::SG_ST1()
+  :
+  int4(18)
+{
+   // does not segfault
+   // osg::Transform alone is not a problem
+   printf( "SG_ST1 constructor done\n" );
+};
+
+
+
+SG_ST7::SG_ST7()
+  :
+  _boundScale(1),
+  int3(3)
+{
+   int4 = 4;
+   // does not segfault
+   // osg::Transform, _boundScale
+   printf( "SG_ST7 constructor done\n" );
+};
+
+SG_ST8::SG_ST8()
+  :
+  _center(0, 0, 0),
+  int3(3)
+{
+   int4 = 4;
+   // does not segfault
+   // osg::Transform, _center
+   printf( "SG_ST8 constructor done\n" );
+};
+
+SG_ST92::SG_ST92()
+  :
+  _scaleFactor(1, 1, 1),
+  // segfault near here, when called from "new"
+  // Segfault at math/simgear/SGVec3.hxx:58
+  // { _data = simd4_t<T,3>(x, y, z); }
+  int3(3)
+{
+   int4 = 4;
+   printf( "SG_ST92 constructor done\n" );
+};
+
+SG_ST93::SG_ST93()
+  :
+  _center(0, 0, 0),
+  _scaleFactor(1, 1, 1),
+  // segfault near here, when called from "new"
+  int3(3)
+{
+   int4 = 4;
+   printf( "SG_ST93 constructor done\n" );
+};
+
+SG_ST97::SG_ST97()
+  :
+  _center(0, 0, 0),
+  _scaleFactor(1, 1, 1),
+  _boundScale(1),
+  // segfault near end of _boundScale constructor, when called from "new"
+  int3(3)
+{
+   int4 = 4;
+   printf( "SG_ST97 constructor done\n" );
+};
+
+
+// these do not segfault
+SG_osg  vosg1;
+SG_ST1  vst1;
+SG_ST7  vst7;
+SG_ST8  vst8;
+SG_ST92  vst92;
+SG_ST93  vst93;
+SG_ST97  vst97;
+
+SG_osg * posg1 = new SG_osg;
+SG_ST1 * pst1  = new SG_ST1;
+SG_ST7 * pst7  = new SG_ST7;
+SG_ST8 * pst8  = new SG_ST8;
+// these will segfault, so must be last
+SG_ST92 * pst92  = new SG_ST92;
+SG_ST93 * pst93  = new SG_ST93;
+SG_ST97 * pst97  = new SG_ST97;
+
+
+
+
 SGScaleTransform::SGScaleTransform() :
   _center(0, 0, 0),
   _scaleFactor(1, 1, 1),
   _boundScale(1)
diff -r -U4 orig/simgear-2018.2.2/simgear/scene/model/SGScaleTransform.hxx source/simgear/scene/model/SGScaleTransform.hxx
--- orig/simgear-2018.2.2/simgear/scene/model/SGScaleTransform.hxx   2018-06-03 13:56:36.000000000 -0500
+++ source/simgear/scene/model/SGScaleTransform.hxx   2018-10-23 20:40:15.000000000 -0500
@@ -24,8 +24,70 @@
 
 #include <osg/Transform>
 #include <simgear/math/SGMath.hxx>
 
+
+
+class SG_ST1 : public osg::Transform {
+public:
+  SG_ST1();
+  int  int4;
+};
+
+class SG_ST7 : public osg::Transform {
+public:
+  SG_ST7();
+
+  mutable double _boundScale;
+  int     int3;
+  int     int4;
+};
+
+
+class SG_ST8 : public osg::Transform {
+public:
+  SG_ST8();
+
+  SGVec3d _center;
+  int     int3;
+  int     int4;
+};
+
+class SG_ST92 : public osg::Transform {
+public:
+  SG_ST92();
+
+  SGVec3d _scaleFactor;
+  int     int3;
+  int     int4;
+};
+
+class SG_ST93 : public osg::Transform {
+public:
+  SG_ST93();
+
+  SGVec3d _center;
+  SGVec3d _scaleFactor;
+  int     int3;
+  int     int4;
+};
+
+
+class SG_ST97 : public osg::Transform {
+public:
+  SG_ST97();
+
+//  META_Node(simgear, SG_ST4);
+
+  SGVec3d _center;
+  SGVec3d _scaleFactor;
+  mutable double _boundScale;
+  int     int3;
+  int     int4;
+};
+
+
+
 class SGScaleTransform : public osg::Transform {
 public:
   SGScaleTransform();
   SGScaleTransform(const SGScaleTransform&,

MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm

Re: Segfault in osg::Transform constructor

Postby MNwjtech » Wed Oct 24, 2018 8:11 pm

This problem goes back several years, so it has persisted through many variations of installed packages on this system.

CPU is a K8 ATHLON64, Hammer family (actually a Sempron, which has 1/2 the cache). It is SSE, SSE2, 3DNow instructions.
Linux Slackware 14.2, upgraded to latest packages as of October 2018.
Kernels used were Linux 4.4.38, 4.4.88, and now 4.4.153.
The first compiler was GCC 5.3.0, installed as a package from the Slackware 14.2 install discs.
The second compiler was GCC 5.5.0, installed from a package obtained from the Slackware support site for 14.2.

I have tried OpenSceneGraph 3.4.0 and 3.5.5.
FlightGear 3.4.0, Flightgear-2017.3.1, and Flightgear-2018.2.2
All the latest tests were done with Flightgear-2018.2.2 and OpenSceneGraph 3.5.5.

I ran mprime for a few hours last night, to verify the CPU and OS operation. This has a stress test (Prime95) that checks the operation of vector instructions.
It used the K8 vector instructions and reported no errors.
I tuned it to not use K8, and use just SSE and SSE2, it ran for an hour, and reported no errors.

I have run memtest on the memory, no errors.
Then, I have changed out the memory sticks, and ran memtest86 on them for hours to verify, no errors.

The power supply is a high quality Enermax, with plenty of extra power.
The motherboard is a conservative business machine, with conservative clocking.

The segfaults are completely repeatable, and appear when debugging too.

Please make a noise if there is anyone paying the slightest attention to this.
MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm

Re: Segfault in SGVec3 constructor

Postby Hooray » Wed Oct 24, 2018 10:02 pm

I am reading this, and again, you seem to be doing the right thing from a troubleshooting standpoint.
Like I said, I would try to come up with a really minimal test case that can reliably reproduce the problem, and then look at what the compiler is doing under the hood, i.e. in terms of generated machine code instructions.

Alternatively, you could try a non-gcc compiler instead and see if/how the problem persists or not.
Either way, it would seem like a good idea to come up with a tiny self-contained piece of code that you can share with the osg/gcc folks to get them involved and see what they can suggest at this point.

That being said,since you specifically mention this going several years, you could also download an image of a recent Linux distro, put that on a memory stick, CD or DVD and see if the problem persists when rebooting into a fresh system.

I realize that most this may seem daunting at first, but it's literally trial and error to see what, if anything, makes a difference or not, to see if we are looking at something that is apparently hardware/OS/kernel related or if it's specific to certain compiler or libc version.

It really does help to do troubleshooting this way and share your findings with the various channels (fg, osg, gcc for now)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11314
Joined: Tue Mar 25, 2008 8:40 am

Re: Segfault in SGVec3 constructor

Postby MNwjtech » Thu Oct 25, 2018 8:19 pm

I have been professionally programming in embedded and real-time systems since 1978.
There is sufficient information already that this should be presented to someone on the development team that can respond with some useful information.
More platitudes about my debugging style, at this point, is not really the kind of information I am seeking.
I am posting this on this forum for the purpose of getting some wider information on this concerning the relation to various compilers and the ATHLON64 K8.

I really need answers to all these questions. On so many forums, you get someone who picks out one question, gives a useless answer, and then gives pointless
responses to dismiss the other questions. I will have to decide which debugging avenues are worth pursuing.

1. Have there been problems with the GCC 5 series of compilers vrs flightgear ?

2. Have there been problems with the SGVec3 class on various CPU and compiler combinations ?

3. Are the developers in love with this SGVec3 implementation ? I have met plenty of developers who get emotionally involved with their code.

The SGVec templates, within templates, inline, while optimizing, is the real problem.
That is a torture test for the compiler. That is why we don't use such things in embedded code. When you have code for a multi-million dollar project depending on your functions,
you do not use complicated templates. Compilers are complex and all of them are buggy. To get reliable binary you don't torture the language features, you keep it simple for the compiler.
Template messes like that can be used on a in-house project, that will be exposed to only one compiler, and probably a couple CPU types. The developers will then just program around the bugs.
Template messes do not work when turned loose into the wild to cope with unrestrained combinations of CPU and compiler.
Are they trying to stress test the compiler or generate fast code ?

The SGVec constructor CAN generate good code, for a static var, but not in the context of the "new".
So one fix is to not use "new". Make these static variables.

A better fix is to unroll those templates, and tune each vector case individually.
This is generating worst case generic vector code. It should have separate optimized functions for the vector-2, vector-3 and vector-4. These can optimize entirely differently when it gets down to the instruction that should be used, they are not just different lengths of the same thing.

I could spend weeks or a month trying to generate pretty test cases.
They will of course only fail on my CPU, compiler combination, and will be ignored.
If the response from the development team is along the lines, that I should be using the compiler they used, or I should buy the CPU they used, then all that work is not going to be used anyway.
MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm

Re: Segfault in SGVec3 constructor

Postby wkitty42 » Fri Oct 26, 2018 1:00 am

you might want to join the developers' mailing list and present your original problem there... generally speaking, they do not participate in these forums... the real work and dev discussions take place over there... mailing list links are at the top of each page in these forums ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5339
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Segfault in SGVec3 constructor

Postby Hooray » Sat Oct 27, 2018 6:06 pm

Look, I am sincerely sorry if I bored, let alone offended you in some way.
The point is however that I realized right away that you had a certain background, but that you also came to the wrong place by posting on the forum.

The majority of users here are not developers like you, i.e. most people around here are not able to build FlightGear from source, unless they're using an existing script that handles all the details. The nature and degree of information you have shared here, makes it rather obvious that you should consider talking to other developers, i.e. people able to read and write C++ code.

And like I said previously, for that it would definitely make sense to come up with a down-stripped test case. And like I also said previously, it does make sense to pick your audience carefully - which is to say, that something that /may/ be compiler related, would probably not be best dealt with on the FlightGear developers mailing list. Equally, a fgfs or osg related issue should not be reported via the gcc channels.

That is one of the reasons why I suggested to come up with a reduced test case that still exhibits the problem, so that you can try different versions/types of compilers to see if the issue persists or not. If that seems daunting, just consider downloading a different Linux distro to a flash drive and boot into that, and try your reduced test case.

Either way, regardless of your -undoubtely- impressive background and the findings you have shared so far, you are obviously looking for help, but you don't seem to realize that you are doing so in the wrong place, as in preaching to the choir.

Again, sorry for my "platitudes", I was really just trying to make exactly this point.

With your sort of professional background, you should be able to tell that it's the right thing to do, i.e. before encouraging people to get rid of code that's worked for the majority of people over the course of many years, it does make sense to see if the issue is any way reproducible, beyond your particular setup (OS, Linux distro, libc, gcc/compiler, hardware).

This isn't to say that you are wrong, it's just to encourage a line of thinking that has more to do with exploring options, so that we can draw informed conclusions.

All that being said, I am sorry for being the only one to respond here in any substantial fashion, and of course for my platitudes, but with your sort of background you have undoubtedly also come around the "how to ask smart questions" essay, which interestingly suggests right at the beginning:

Choose your forum carefully

Be sensitive in choosing where you ask your question. You are likely to be ignored, or written off as a loser, if you:

[*] post your question to a forum where it's off topic

[*] post a very elementary question to a forum where advanced technical questions are expected, or vice-versa

[*] cross-post to too many different newsgroups

[*] post a personal e-mail to somebody who is neither an acquaintance of yours nor personally responsible for solving your problem
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11314
Joined: Tue Mar 25, 2008 8:40 am

Re: Segfault in SGVec3 constructor

Postby MNwjtech » Wed Oct 31, 2018 2:39 am

This report has reached a stage where I can wait for a response. It has been less than a week. I had my own project to work on, and another that wanted some help, so I was letting this go for a while.
All the information is here on the forum. I am not fond of the idea of duplicating it entirely somewhere else.

On this other project I work on we have a bug reporting system. The developers mailing list is more restricted to developers because it goes directly into their email.
It can become a nuisance when a user gets on there and wants to carry on a long conversation with one developer, using the mailing list.

The Flightgear project should have a proper system for reporting bugs.

Second best would be for one developer to get the prod to check out this bug report on this forum. That way only those who are participating in this discussion
need read all of this. And if the discussion gets long, it is not broadcast to everybody on the developers mailing list.

It would be best if a bug reporting system suddenly appeared.

I can wait a while to see if the second choice might happen.

Trying out another compiler or another operating system is not going to develop any new information. We already know it compiles and runs for some compilers.

If I am going to be prompted to change my OS, as a fix, then it is clear why this bug has not been dealt with. Excluding the problem cases from your support base on the
theory that it works for most people (who is anyone lucky enough to have the right OS and compiler), is one way to not have to deal with certain bugs.

There should not be anything that the OS contributes to the fault. It is an issue between the complex template code and how well the compiler's can cope with it.
I know that better optimized code can be generated for every compiler case by not using templates, and creating an individual customized function for every distinct case.

I could do this on my own, but it is of marginal usefulness if there is resistance in the project to adopting such code.
I can fix the symptom much more simply, but that would leave the bug in the code to be re-encountered with each new release.
MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm

Re: Segfault in SGVec3 constructor

Postby Hooray » Wed Oct 31, 2018 6:40 am

MNwjtech wrote in Wed Oct 31, 2018 2:39 am:The Flightgear project should have a proper system for reporting bugs.
[...]
It would be best if a bug reporting system suddenly appeared.


Like I said previously, while you seem to have an impressive background, you have come to the wrong place by posting this kind of information on the forum and you are drawing the wrong conclusions, too.

You could read up about fgfs issue tracking and the developers mailing list using the wiki, or even just looked at the links listed at the top of the forum, and you would have found this: https://sourceforge.net/p/flightgear/codetickets/


Second best would be for one developer to get the prod to check out this bug report on this forum. That way only those who are participating in this discussion
need read all of this. And if the discussion gets long, it is not broadcast to everybody on the developers mailing list.

A number of forum users do actually interface between the forum and the devel list, but given your postings and the technical details contained there, it would be kinda silly for end users unable to read/write C++ code code and unable to patch/rebuild fgfs, to forward your posting to other developers. In other words it would be silly for you not to use either the devel list and/or the issue tracker.

If I am going to be prompted to change my OS, as a fix, then it is clear why this bug has not been dealt with.

This I entirely agree with, but I didn't suggest re-installing your OS to "fix" the issue, but rather try a different Linux distro/gcc version or libc version to further troubleshoot the issue - ideally by booting into a live system from a flash disk - to be entirely sure that the problem is unrelated to your hardware (memory, cpu). Let's be honest, even knowing if different gcc versions (or gcc build flags) are unaffected would be helpful to know.
I certainly didn't suggest to "change your OS" to fix this, it would be ridiculous to do so - regardless of where the problem lies. I would hate doing so myself. But booting into a different distro via a flash drive is easy to do, as is trying different compilers on the same system, especially for someone with your background.


Excluding the problem cases from your support base on the
theory that it works for most people (who is anyone lucky enough to have the right OS and compiler), is one way to not have to deal with certain bugs.

There should not be anything that the OS contributes to the fault. It is an issue between the complex template code and how well the compiler's can cope with it.
I know that better optimized code can be generated for every compiler case by not using templates, and creating an individual customized function for every distinct case.


Right, like you said previously, "serious RL projects" are often prohibited from using certain modern language features, like templates specifically.

This I entirely agree with, but there are some key contributors involved in the project that have the tendency to push "for the latest and greatest" (e.g. C++ 0x) - and they are the ones shouldering most of the work (often for years, if not even a whole decade), so they obviously get to decide what to use in terms of language features and additional dep endencies.

That's also why it would be interesting to see if your issue can be reliably reproduced - i.e. I do agree that if there are still certain compilers/systems around that cannot deal with such modern C++ code, the FlightGear project should hopefully learn a lesson or two from that.

However, as long as you are not using the developers mailing list and/or the issue tracker, you are clearly posting in the wrong place.

In my eyes, what you have shared so far is not conclusive enough to really confirm that this indeed the case. As a matter of fact, I actually once had a similar issue, and it turned out to be faulty hardware that was only triggered by using gcc in conjunction with heavy code (such as nested templates).


PS: No offense intended or taken - I still think, you should check out the developers mailing list or the issue tracker, because you are literally preaching to the choir, i.e. other end-users only.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11314
Joined: Tue Mar 25, 2008 8:40 am

Re: Segfault in SGVec3 constructor

Postby Gijs » Wed Oct 31, 2018 7:24 am

Hi,
MNwjtech wrote in Wed Oct 31, 2018 2:39 am:The developers mailing list is more restricted to developers because it goes directly into their email.
It can become a nuisance when a user gets on there and wants to carry on a long conversation with one developer, using the mailing list.
Don't worry! Most core developers actually favour the mailing list over a forum or other system (which is why you'll find most of them there and not here). Posting a link to your forum topic and/or issue tracker, and possibly discussing its implications on the list is certainly not seen as a nuisance ;-) Do note that there's a pretty big flightsim event this weekend that some of us are attending, so you may have to wait till next week for a reply.

Cheers,
Gijs
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9361
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Segfault in SGVec3 constructor

Postby wkitty42 » Thu Nov 01, 2018 12:18 pm

MNwjtech wrote in Wed Oct 31, 2018 2:39 am:All the information is here on the forum. I am not fond of the idea of duplicating it entirely somewhere else.

as others have said, since you have posted the problem here, simply provide a link in a post on the mailing list with a brief description and someone will take a look...

MNwjtech wrote in Wed Oct 31, 2018 2:39 am:The Flightgear project should have a proper system for reporting bugs.

there is... do you see the Bug Tracker link at the very top of every page in these forums? ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5339
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Segfault in SGVec3 constructor

Postby MNwjtech » Thu Nov 01, 2018 1:17 pm

Thank you, I have now found the bug tracker menu item. That menu bar is the exact same background color as my Firefox menu bars. Hard to notice when there is a different colored, much more visible, menu bar, that has your login on it.
MNwjtech
 
Posts: 7
Joined: Sat Oct 20, 2018 8:37 pm


Return to Compiling

Who is online

Users browsing this forum: No registered users and 0 guests