Environment variables problem in OMNeT++ 5.1.1

[Tian Bin]

Dear Rudolf and omnet community

I meet a classical problem when I try omnet 5.1.1. After I ./configure && make the omnet 5.1.1 in mingw, I run the sample aloha. But I get nothing...so silence...like the figure below:

And then, I run omnetpp to open the IDE, no surprise, I get the environment variables problem as follows:

the log file is as follows:

Starting...

 

$ cd C:/OMNeTpp/omnetpp-5.1.1/samples/tictoc

$ tictoc.exe -m -u Qtenv omnetpp.ini 

 

Simulation terminated with exit code: -1073741511

Working directory: C:/OMNeTpp/omnetpp-5.1.1/samples/tictoc

Command line: tictoc.exe -m -u Qtenv omnetpp.ini

 

Environment variables:

PATH=;C:\OMNeTpp\omnetpp-5.1.1\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\mingw64\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin;;C:/OMNeTpp/omnetpp-5.1.1/ide/jre/bin/server;C:/OMNeTpp/omnetpp-5.1.1/ide/jre/bin;C:/OMNeTpp/omnetpp-5.1.1/ide/jre/lib/amd64;.;C:\OMNeTpp\omnetpp-5.1.1\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\mingw64\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\local\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin\site_perl;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin\vendor_perl;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin\core_perl;C:\OMNeTpp\omnetpp-5.1.1\samples\aloha;

OMNETPP_ROOT=C:/OMNeTpp/omnetpp-5.1.1/

OMNETPP_IMAGE_PATH=C:\OMNeTpp\omnetpp-5.1.1\images

From the previous experience, the problem is that: there is no appropriate dll file in the environment variable path, for example, zlib1.dll. So, I copy the zlib1.dll from "omnetpp-5.1.1\tools\win64\mingw64\bin" to "omnetpp-5.1.1\bin" and "windows\sysWOW64" and the folder of the aloha. But, it is useless. I hope someone can help me out. 

In addition, the mingw of the omnet++ 5.1 and laster version seems become more advanced, like support 64bit systems, support Qt etc. But, it seems vulnerable when I use. It's just my feeling. 

All in all, please give me some inspirations. 

Best Wishes!

Bin

[Attila Török]

Dear Bin,

Could you please attach a stack trace of the failing simulations? We might gather some insight about your problem from that. Either aloha or tictoc will be fine.

Thank you,
Attila

2017-09-13 12:01 GMT+02:00 Tian Bin <artisa...@gmail.com>:

Dear Rudolf and omnet community

I meet a classical problem when I try omnet 5.1.1. After I ./configure && make the omnet 5.1.1 in mingw, I run the sample aloha. But I get nothing...so silence...like the figure below:

And then, I run omnetpp to open the IDE, no surprise, I get the environment variables problem as follows:

the log file is as follows:

Starting...

 

$ cd C:/OMNeTpp/omnetpp-5.1.1/samples/tictoc

$ tictoc.exe -m -u Qtenv omnetpp.ini

 

 

Simulation terminated with exit code: -1073741511

Working directory: C:/OMNeTpp/omnetpp-5.1.1/samples/tictoc

Command line: tictoc.exe -m -u Qtenv omnetpp.ini

 

Environment variables:

PATH=;C:\OMNeTpp\omnetpp-5.1.1\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\mingw64\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin;;C:/OMNeTpp/omnetpp-5.1.1/ide/jre/bin/server;C:/OMNeTpp/omnetpp-5.1.1/ide/jre/bin;C:/OMNeTpp/omnetpp-5.1.1/ide/jre/lib/amd64;.;C:\OMNeTpp\omnetpp-5.1.1\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\mingw64\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\local\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin\site_perl;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin\vendor_perl;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin\core_perl;C:\OMNeTpp\omnetpp-5.1.1\samples\aloha;

OMNETPP_ROOT=C:/OMNeTpp/omnetpp-5.1.1/

OMNETPP_IMAGE_PATH=C:\OMNeTpp\omnetpp-5.1.1\images

From the previous experience, the problem is that: there is no appropriate dll file in the environment variable path, for example, zlib1.dll. So, I copy the zlib1.dll from "omnetpp-5.1.1\tools\win64\mingw64\bin" to "omnetpp-5.1.1\bin" and "windows\sysWOW64" and the folder of the aloha. But, it is useless. I hope someone can help me out. 

In addition, the mingw of the omnet++ 5 and laster version seems become more advanced, like support tool chain of 64bit, support Qt etc. But, it seems vulnerable when I use. It's just my feeling. 

All in all, please give me some inspirations. 

Best Wishes!

Bin

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[Tian Bin]

Dear Attila

I try to do the stack trace, but omnet does not give me the chance. The program is terminated before it go to the debugging. 

I do like this: first, configure the debug, tick the "debug on errors". 

And then debug, the interface is like this:

the debug interface does not show up. The debugger console shows as follows:

GNU gdb (GDB) 7.11.1

Copyright (C) 2016 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-w64-mingw32".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word".

[New Thread 5208.0x1e20]

I can give more information. That is, I tryed omnet 5.1 and omnet 5.1.1 on my PC (Win 7 64bit), the same problem shows up. At the same time, I also have installed omnet 4.4, it works well. 

The mingw has been improved after 5.0, it's good for sure. However, it does not work for me temporarily. I guess the problem lies in that: omnet accesses wrong dll when the program starts. But, there is not warning message jumped out. Maybe the dll is existed, but the version is wrong? 

Do you and the omnet team have some experience for this problem? Thanks in advance.

Best Wishes!

Bin

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.

[Tian Bin]

By the way, I also check the environment path of mingw as follow:

On Wednesday, September 13, 2017 at 8:38:15 PM UTC+8, Attila Török wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.

[Attila Török]

You could try running the debugger from the command line.

So in mingwenv, in the samples/aloha directory, instead of simply running ./aloha.exe, run gdb ./aloha.exe

Then, when you are presented with a (gdb) prompt, enter run
Hopefully some kind of error message will show up.
After this, if it was a segmentation fault for example, you can get the stack trace by entering backtrace
Maybe we can get some useful information this way.

Attila

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.

[Tian Bin]

Dear Attila

I do the command debug as you told me. The results are as follows:

GNU gdb (GDB) 7.11.1

Copyright (C) 2016 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-w64-mingw32".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Traceback (most recent call last):

  File "<string>", line 3, in <module>

ImportError: No module named libstdcxx.v6.printers

c:\omnetpp\omnetpp-5.1.1\tools\win64\mingw64\bin\../etc/gdbinit:5: Error in sour     ced command file:

Error while executing Python code.

Reading symbols from ./aloha.exe...done.

(gdb) run

Starting program: C:\OMNeTpp\omnetpp-5.1.1\samples\aloha\aloha.exe

[New Thread 12052.0x1518]

During startup program exited with code 0xc0000139.

(gdb) backtrace

No stack.

(gdb)

"During startup program exited with code 0xc0000139." Is this a useful information? Maybe we are closing the answer.

Best.

[Attila Török]

Thank you. Well, since it crashes during startup, it does indeed look like a problem with DLL loading - or something of that sort.

And I'm afraid I'm out of ideas for now. Maybe Rudolf can help you, but he is on holiday this whole week. I'll ask him on Monday if he has any tips for you.

Attila

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.

[Tian Bin]

Thanks a lot, attila.

I also will try to solve it. If I get some solutions, I will update this post.

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/cFHdQtojCJk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Tian Bin]

Hi, Attila

I provide more information. I have installed omnet5.0 on the same PC (win7 64bit), it works successful. So, the difference between 5.0 and 5.1 is a hint for the startup problem. I checked the file of 5.0 and 5.1, they are omnetpp-5.0\tools\win32 and omnetpp-5.1.1\tools\win64. Rudolf said that after 5.1 (include 5.1), omnet++ only support 64 bit system. Maybe something changed from tools\win32 to win64, which leads to load wrong dll file, e.g., zlib1.dll. 

Actually, I find many zlib1.dll on my PC, many software use it as follow. The zlib1.dll file refers to a compression function mentioned on wiki.

I also compared the environment path of 5.0 and 5.1 as follow:

5.1 seems include fewer paths than 5.0.

I still on the way to figure out way why the omnet program get a failed startup silently, without any warning....

Best 

Bin

[Rudolf Hornig]

In my experience this kind of error happens when there is a DLL somewhere in the windows system path (ie. windows/system32 etc.) or windows directory which is a different version that the one required by OMNeT++ (or more precisely the used MSYS/MINGW libraries). OMNe++ tries to insert its path entries at the beginning of the PATH variable to minimize the DLL hell effect, but sadly, if a DLL is in the system folders, that takes precedence over anything in the normal path.

Check the following articles for the library load order:

https://docs.microsoft.com/en-us/cpp/build/search-path-used-by-windows-to-locate-a-dll

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

Long story short, some of the programs you have installed on the machine put a DLL in the system directory which is now loaded by omnet instead of its own (tested) version from the win64/tools directory. The mentioned zlib1.dll is a good candidate for this, but any other dll can be an issue.

You need to figure out which is the offending DLL and remove it from the system directory. One trick that usually helps me is that the error reporting in Windows is MUCH better if you start the program from the WIndows Explorer (instead of the command line). In those cases Windows usually displays the name of the DLL that failed to load. To do this, you have to add the following entries directly at the beginning of the system path (in the System/Advanced dialog) and then restart Windows and double click the aloha.exe directly in the Windows Explorer (instead of starting it from the MingwEnv command line).

C:\OMNeTpp\omnetpp-5.1.1\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\mingw64\bin;C:\OMNeTpp\omnetpp-5.1.1\tools\win64\usr\bin

Don't forget to remove these entries from the global system path after you have figured out the offending DLL.

You should delete the problematic (incorrect version) of dll. 

Hope this helps, Rudolf

[Tian Bin]

Dear Rudolf

Your method is really really helpful ! Thank you ! Your email can be a classical solution for this kind of problems. These post serial must be very useful to latter users. 

I found that a dll file, called libeay32.dll, is reported by windows. So, I searched it and found that there are many software have this dll,  as shown in Figure 1.

Figure 1. Searching for libeay32.dll

And then, I compared these software path with the ones in system PATH. Bingo, I found that a software path including libeay32.dll also is in the system path, as shown in Figure 2.

​​Figure 2. System path of windows

I remove the path of the software from system path. Try aloha sample again.

Finally, I solved the problem.

Best Wishes!

Bin

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/cFHdQtojCJk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

--

Dr. Bin TIAN

LIMOS Laboratoire UMR 6158 CNRS - FRANCE

Tel: +33 (0)4 73 40 51 55

Website: http://edss.isima.fr/sites/smir/member/intro?userId=105

[YIJU WU]

Hi, Bin

I am facing familiar problem as you mentioned that: Running examples code and being stuck getting nothing.

I followed Mr. Attila Török suggested:

The program was stuck and the GUI showed up in toolbar but there was no window.

Although Mr Rudolf has gave the best answer, but I have no idea how to find the .dll files as he mentioned.

Would you give me some tips as a experiencer. That will be helpful.

WU

[Attila Török]

Thank you for trying to find a solution for your issue in the mailing list archives.
However, I don't think your issue is with DLL loading. The "Loading images from..." message is printed by Qtenv during its initialization, which means that its DLL (and all others it depends on) have been loaded successfully.

On Mon, Sep 10, 2018 at 9:05 AM YIJU　WU <karl...@gmail.com> wrote:

Hi, Bin

I am facing familiar problem as you mentioned that: Running examples code and being silence getting nothing.

I followed Mr. Attila Török suggested:

The program was stuck and the GUI showed up in toolbar but there was no window.

Although Mr Rudolf has gave the best answer, but I have no idea how to find the .dll files as he mentioned.

Would you give me some tips as a experiencer. That will be helpful.

WU

Tian Bin於 2017年9月13日星期三 UTC+9下午7時01分21秒寫道：

[Tian Bin]

Hi Yiju

Your problem is not exactly as the one I meet. My problem is that when I run the sample, I get nothing...so silence. While you get feedback and the sample is running. I feel there seems a little problem with Qt interface. 

There is a experience for me, you can run the sample by OMNet++ interface (Eclipse), and there are options for user interface as follows:

You can change the User interface from Qtenv (default) to Tkenv, to check Qt interface is ok or not. 

Best

Bin

On Mon, Sep 10, 2018 at 3:05 PM YIJU　WU <karl...@gmail.com> wrote:

Hi, Bin

I am facing familiar problem as you mentioned that: Running examples code and being silence getting nothing.

I followed Mr. Attila Török suggested:

The program was stuck and the GUI showed up in toolbar but there was no window.

Although Mr Rudolf has gave the best answer, but I have no idea how to find the .dll files as he mentioned.

Would you give me some tips as a experiencer. That will be helpful.

WU

Tian Bin於 2017年9月13日星期三 UTC+9下午7時01分21秒寫道：

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/cFHdQtojCJk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[YIJU WU]

Hi, Bin, Attila Török

Thanks for replying.

I post this problem in the other thread yesterday, and the problem has been solved quickly.

Thanks again.

WU