UDPBasicApp Copy/Paste Results in Segmentation Fault

[Roger Jolly]

Hello,

I'm in the process of designing and coding a unique traffic generator. To begin the coding, I took the UDPBasicApp source code (NED and C++), copied it and renamed it MyUDPBasicApp.

I created a simulation that runs fine with UDPBasicApp, but when I replace the single UDPBasicApp with MyUDPBasicApp in the ini file (updApp[0].typename), the simulation faults.

The call stack is thus:
Thread #1 0 (Suspended: Signal : SIGSEGV:Segmentation fault)
- inet::L3Address:getType() at L3Address.cc:54
- inet::L3Address:isUnspecified() at L3Address.cc:135
- inet::L3AddressResolver:tryResolve() at L3Address.cc:178
- MyUDPBasicApp::processStart(): at MyUDPBasicApp.cc:119
...

Basically, at 30 seconds, the app is started with the indirect call to processStart(). UDPBasicApp will run fine, but MyUDPBasicApp seems to be having some kind of addressing problem.

What's going on here? This is just a simple copy/paste ... along with some namespace changes - as I'm building it outside INET and in a separate project.
I've done similar with UDPSink and it functions fine.


Thanks,
Roger



OMNeT++ 5.0
INET 3.4
Windows 7

[Roger Jolly]

I move the source (NED and C++) for MyUDPBasicApp to the INET folder/namespace and built the app as part of the INET library.
My driver now works without fault.
What's the deal?

[Henning P]

Hey there,

I just found a way to circumvent this error. Although it is not the nicest type of a “solution”, it makes the program running as expected.

Notes:

This error only occurs under windows. Therefore, using Unix is also a solution.

I am using the older Versions Omnet 5.0 and INET 3.4.0. This error may not occur under newer versions. However, the INET code is still the same and this error was not mentioned in the INET changelogs at the time of writing.

 

“Solution” on Windows:

Write your own class that inherits from L3AddressResolver and copy the code from L3AddressResolver:

class MyL3AddressResolver : public L3AddressResolver

…

Use an instance of this class:

            Old (you get a segmentation fault):

inet::L3AddressResolver().tryResolve()

            New (working):

dummyL3AddressResolver = new MyL3AddressResolver();

            dummyL3AddressResolver->tryResolve(token, result);

 

Explanation (at least a try):

While debugging, I found that the method L3AddressResolver.addressOf() cannot be found although the program finds L3AddressResolver.tryResolve(). Actually, the debugger is complaining the following:

can't find linker symbol for virtual table for `inet::L3AddressResolver' value

I guess that the virtual table is not set up correctly under Windows in this case and the Unix compiler works better here for some reason.

[Rudolf Hornig]

The reason for this error was that the clang compiler bundled with OMNeT++ 5.0 was generating an incorrectl virtual table for certain classes. Newer versions of OMNeT++ come with an updated compiler where this was fixed. (OMNeT++ 5.1 did not bundle the mingw-clang compiler for this reason. It came only with gcc. ) OMNeT++ 5.2 clang compiler should work fine.

Rudolf

[Henning P]

@Rudolf: Ah great. Thank you for clarifying.