Impossible to run examples

[mridolfi]

Starting...

$ cd :/omnetpp-5.1pre2/samples/inet/examples/adhoc/ieee80211 $ ../../../../../bin/opp_run.exe -m -n ../..;../../../src;../../../tutorials -l ../../../src/INET omnetpp.ini

Simulation terminated with exit code: -1073741511 Working directory: C:/omnetpp-5.1pre2/samples/inet/examples/adhoc/ieee80211 Command line: ../../../../../bin/opp_run.exe -m -n ../..;../../../src;../../../tutorials -l ../../../src/INET omnetpp.ini

Environment variables: PATH=;C:/omnetpp-5.1pre2/samples/inet/src;C:\omnetpp-5.1pre2\bin;C:\omnetpp-5.1pre2\tools\win64\usr\bin;C:\omnetpp-5.1pre2\tools\win64\mingw64\bin;C:/omnetpp-5.1pre2/ide/jre/bin/server;C:/omnetpp-5.1pre2/ide/jre/bin;C:/omnetpp-5.1pre2/ide/jre/lib/amd64;.;C:\omnetpp-5.1pre2\bin;C:\omnetpp-5.1pre2\tools\win64\mingw64\bin;C:\omnetpp-5.1pre2\tools\win64\usr\local\bin;C:\omnetpp-5.1pre2\tools\win64\usr\bin;C:\omnetpp-5.1pre2\tools\win64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\omnetpp-5.1pre2\tools\win64\usr\bin\site_perl;C:\omnetpp-5.1pre2\tools\win64\usr\bin\vendor_perl;C:\omnetpp-5.1pre2\tools\win64\usr\bin\core_perl;C:\omnetpp-5.1pre2; OMNETPP_ROOT=C:/omnetpp-5.1pre2/ OMNETPP_IMAGE_PATH=C:\omnetpp-5.1pre2\images

[namnatulco]

what is the actual output of opp_run here? or does it really just terminate with that exit code without any output?

[mridolfi]

Exactly, it just terminates with that exit code

[michaelkirsche]

I surprisingly had this error too. Occurs on different INET examples when building it under Windows, it seems to vanish when you build everything with GCC instead of Clang. Everything fine under Linux though :|

[rhornig]

Umm, now we have problem. OMNeT++ 5.1 bundles clang-3.8 on Windows and it seems that the compiler has a serious bug. Trying to compile and run the following code results in a crash:

class VeryBase {
    virtual void foo() {}
};

class Base1 : public virtual VeryBase {};

class Base2 : public virtual VeryBase {};

class TargetClass : public Base1, public Base2 {};

int main()
{
    VeryBase* a = new TargetClass;
    Base2* c = dynamic_cast<Base2*>(a);  // segmentation fault
}

As you can see, the compiler generated code is crashing when you try to downcast to subclass if virtual inheritence was used. Now this is a problem because physical model and the radio heavily uses interfaces which are implemented as classes with only virtual methods.

Unfortunately even the latest clang 3.9 exhibits this behavior :( I'm not sure how to proceed. We can either rewrite INET and remove all virtual inheritance (making the code a bit more convoluted) or drop the support of clang and default to gcc on Windows?

[michaelkirsche]

Some additional infos on this problem. I've tested it on two different Windows 10 installations with the latest OMNeT 5.1pre3 and the INET Github version. Take the "WiredAndWirelessHostsWithAP" example for example :) INET (including all necessary features) compiled with GCC 6.1.0 from the OMNeT Windows installation --> everything works fine.

INET (including all necessary features) compiled with CLANG 3.8.0 from the OMNeT Windows installation --> the segmentation fault occurs.

Some details on this:

The segfault occurs in the function 'W MediumLimitCache::computeMaxTransmissionPower() const' of 'inet\src\inet\physicallayer\common\packetlevel\MediumLimitCache.cc' With the '...radio->getTransmitter()->getMaxPower())' part (line 157) in the loop, a pointer to the current transmitter of the radio should be returned and the MaxPower for this transmitter should eventually be used for the maxTransmissionPower calculation.

While INET compiled with GCC gets us the pointer to the transmitter of the radio, the Clang compiled INET runs into the segmentation fault because the returned pointer to the transmitter is somehow not initialized (or a Nullpointer which shouldn't happen)?!?

---

Just saw that you've posted an update before on this issue.

Yep, just Clang on Windows is having this problem.

Best advice at the moment would be to change the preferred compiler back to GCC (PREFER_CLANG=no in configure.user). Completely dropping the Clang support would be as bad as a complete rewrite of the INET radio/PHY code. This error might be fixed and under Linux, things run just fine.

So probably a note that the default behavior is compilation with GCC but Clang can be enabled under Linux but errors might occur under Windows for INET wth the Clang compiler.

[rhornig]

@michaelkirsche Ahh no, I was just proposing to remove the clang compiler from the Windows bundle. (i.e. no change to the core OMNeT++ files). That way OMNeT would never detect clang on Windows even if PREFER_CLANG is yes. Once this is fixed, you still can install manually the clang compiler from mingwev by typing pacman -Sy mingw-w64-clang

[michaelkirsche]

@rhornig When I compare the disassembly of your example under Clang-Windows, Clang-Linux and GCC-Windows and step through the instructions from the creation of Base2* c... , I can see that:

1. the c variable is null on both Clang-Linux and GCC-Windows compared to a random value under Clang-Windows
2. when accessing the foo method of c, there's an additional 'mov' operation under Clang-Linux and GCC-Windows that sets the value of c to the correct memory area, which is missing from Clang-Windows somehow.

Is this issue not removed when you create variable a from TargetClass instead of VeryBase ??? This way, the correct pointer address is written, no segmentation fault.

[rhornig]

@michaelkirsche The crash does not happen either if you try to cast to Base1* i.e. it is a problem only if we cast to the second (not first) class in the inheritance list (obviously). Sadly this is just one manifestation of the issue. Inside INET this actually surfaces in a way that you get a a module pointer (with getSubmodule("transmitter")) and then try to cast it to an Interface class that it implements. At this point the program does not crash, but returns and pointer which points to a totally random address. Accessing this pointer later causes the segmentation fault. Long story short, the compiler cannot handle virtual inheritance properly...

[rhornig]

This should now work with OMNET 5.1RC1 and INET 3.5

[michaelkirsche]

Maybe add a bug on the OMNeT list concerning the Clang Windows (virtual inheritance) issue, so that nobody forgets about this?

[michaelkirsche]

@rhornig A short follow-up... I've upgraded the Clang/LLVM parts of the older OMNeT 5.0 final, where the MinGW environment is installed as a 32-bit version. The i686-w64-windows-gnu target of MinGW does provide the same versions like the x86_64-w64-windows-gnu target.

So even with Clang/LLVM 3.8.0 (same as 5.1pre3) or Clang/LLVM 3.9.1 (newest version), things work fine with compiling INET under the newer 32-bit Clang versions.

The issue seems to be with the 64-bit Clang compiler, which was introduced when MinGW changed to the 64-bit version.

I actually doubt that it is an error that was introduced in later Clang/LLVM versions. It seems more like a difference between the 32- and 64-bit versions from Clang (or different interpretations of the virtual inheritance used in INET).