Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
21 Views

Possible bug in latest compiler 17.0.0.109

Programs compiled under the latest version when running in a windows subsystem in VS2013 Shell when exited by either the windows exit command from the drop down box or the "X" in the upper right hand corner of the window are still running in the background.  The windows close as if the program has exited, but when viewed in task manager are still running.  Exiting from within the programs works normally.

I noticed this during a rebuild after exiting with a click on the window  "X" that the link would fail.  Sure enough the program was still active when viewed in the process list. 

I tested this on several different programs with the same results.  On complier versions 15 and 16 the programs exited correctly.

Running with Windows 10 latest updates.  Also occurs on Windows 7 system.

 

 

0 Kudos
24 Replies
Highlighted
17 Views

Hi,

 

I can't reproduce the behavior on my Windows 10 system using VS2013 + 17.0 ifort. Which project type did you select when creating the project. Can you attach a simple test case?

 

Thanks,

Xiaoping Duan

Intel Customer Support

0 Kudos
Highlighted
Beginner
17 Views

Today I checked the program running without VS2013 and the same actions occurs.  The open windows closes, but the process says it's still running.  So it is not related to VS2013.  It has to be something in IVF 17. 

The program is a QuickWin application using win32 or win64 windows subsystem it is not a console application.

I am using "IFQWIN" and opening the window with:  SETWINDOWCONFIG(wc) and page frame with QWIN$SET.

Here is the compiler options:

/nologo /debug:full /Od /fpscomp:filesfromcmd /fpscomp:general /warn:interfaces /Qsave /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc120.pdb" /traceback /check:bounds /libs:qwin /dbglibs /c

0 Kudos
Highlighted
17 Views

Building a simple program containing those calls and using the same options I still can't reproduce the behavior.

If a complete test case can't be post here can you try to run the code within VS 2013 by starting a debugging session with key "F5", close the window, and then check the debugger output message on if the program has exit? If it doesn't exist as you described you may break the running through "Debug -> Break All" and look into the call stack window on where it is stuck.

 

Thanks,

Xiaoping Duan

Intel Customer Support

0 Kudos
Highlighted
Black Belt
17 Views

FWIW I have seen similar behaviour to this, where a zombie process results when an ifort 17.0 generated executable terminates in a certain way.

From spelunking with windbg I suspect this might be related to the virus scanner in use.  Are you using a virus scanner?  If so, what is it?

 

 

0 Kudos
Highlighted
Beginner
17 Views

I haven't had a chance to work on an example program.  I can't send the ones I am working on.  Maybe I can work one this weekend.

But this happens on two separate computers with two separate operating systems and separate antivirus programs.  One system is on a network running Windows 7 and the other is a standalone running Windows 10.  It does not happen on either computer when compiling with version 16.  It happens on both when using version 17.  It's very annoying since I have to go to task manager and kill the program before I can recompile after every change since the linking fails when the program is still running.  This has never occurred before using IVF and I have been using it for many years. 

0 Kudos
Highlighted
17 Views

>>Here is the compiler options: ...  /check:bounds ...

Any bounds errors are displayed to "the console" window. In a QuickWin application you do not have a console. It may the case that the termination of the application is causing a out-of-bounds message to the non-existent console and additionally is waiting for response (e.g. ^C).

Try disabling (not using) /check:bounds and see what happens.

Note, I am not stating that /check:bounds is at fault. Rather I am saying:

   should lack of /check:bounds result in either: expected behavior (proper close), or SIGSEGV

Then you have a program bug that needs to be fixed.

Jim Dempsey

0 Kudos
Highlighted
17 Views

An additional diagnostic you can use (with failing configuration):

Run the program and then exit it and verify that the (or part of) the program is still running. Then, without terminating the program, use VS IDE: Debug | Attach to Process to attach to the process. You should be able to get the call stack information. You may need to specify the location to your .pdb file.

Jim Dempsey

0 Kudos
Highlighted
Beginner
17 Views

Disabling /check:bounds has no effect.  I ran the program exited and then in VS Debug attached the Process.  It loaded a lot of symbols from Microsoft servers, but when I went to the call stack tab it was empty.  I am not familiar with using this function maybe I did not correctly use it.

0 Kudos
Highlighted
Valued Contributor III
17 Views

kenneth m. wrote:
I am using "IFQWIN" and opening the window with:  SETWINDOWCONFIG(wc) and page frame with QWIN$SET.

Setwindowconfig is for setting the properties of a child window it does not open it. The is with OPEN with file='user'

How do you close the window, by a menu call to winexit or by the in the top corner. I recall that latter can sometimes cause some  problems from time to time. 

0 Kudos
Highlighted
Beginner
17 Views

 

In this program only one window is used to run the program.  No other windows are opened. The output just scrolls in that window.  The program closes when the user selects the input request to stop the program, that input causes the following lines to execute  " result = setexitqq(QWIN$EXITNOPERSIST)" and  "end".  The problem I am having is when I am in VS working on the code and I close the window to recompile after changes are made while still in VS.  Like I said the window closes but the process is still running for some reason.  I have never had this happen before V17.

 

0 Kudos
Highlighted
17 Views

Please provide a small but complete program that shows the problem. You can attach it to a reply here or submit through Intel Premier Support. (If you do the latter, please reply here with the issue number.)

0 Kudos
Highlighted
Beginner
17 Views

Program with example of problem attached.

Run the program and it will stop, waiting for an input, at that time close the window with the "X" in the upper right corner.  The windows will close then look for the program in the processes.  It will still be active.  This has not been the case in the past.  If you just hit enter for the input it will close normally.

This same program can be used to test the other issue I posted here.  So I will also attaché it there with comments.

 

0 Kudos
Highlighted
17 Views

I can reproduce this - thanks for the example. I will pass this on to the developers. Issue ID is DPD200415258.

0 Kudos
Highlighted
Beginner
17 Views

You are welcome. 

0 Kudos
Highlighted
Beginner
17 Views

This issue is now fixed in 2017 Update 1.  Thanks. 

0 Kudos
Highlighted
17 Views

Interesting - we didn't deliberately fix this. May have been a side effect of something else. Thanks for letting us know.

0 Kudos
Highlighted
Beginner
17 Views

Well I thought this was fixed, but when I checked on 2nd machine with Windows 7 I am still having this issue.  So now I'm not sure why one systems works and another does not.  I will further test machine that started working and see if it will fail again.

Question:  I do not remember the program stopping to load symbols in the past.  Is this something new?  It slows down my work waiting for the downloads.  Are they necessary?  What if I was not connected to internet when using program and it can not find them?

 

0 Kudos
Highlighted
Valued Contributor III
17 Views

tools>options>debugging>symbols

do you have the "Microsoft Symbols Servers" ticked? You only need these symbols if you are trying to debug into the windows system.

0 Kudos
Highlighted
17 Views

I could not reproduce the problem anymore on my Windows 7 system.

0 Kudos