Page 1 of 2
Posted: 12 Sep 2013 12:27
Hi Thomas and all others,
when I am stepping through code with the debugger (in VIP 7.4 build 7402), it often happens, that the debugger is hanging for minutes before it proceeds with the next line. I cannot see a relation between the code or memory usage and this effect - it occurs with arbitrary code in a seemingly random debug step. Once the effect has appeared in a debug run, further debug commands are also hanging for minutes until carried out.
I wonder whether someone else has experienced the effect or I am the only one? In the later posts in the forum I have not found anybody telling about it, also in the knowledge base I found nothing. Maybe on my system (Windows 7, 64 bit) there is some bad constellation causing the effect?
For me the effect is extra severe, because I am outstanding creative in making mistakes and badly need the debugger for clearing them. Please help to fix the debugger delays!
Regards and my thanks to Thomas for answering my prior posts,
Posted: 12 Sep 2013 15:02
When the debugger stops in a breakpoint it will have to assume that everything in the debugged program can have changed. So when refreshing the windows it has to look-up a lot of memory in the debugged program.
Perhaps you can try to figure out if the delay is caused by some particular debug window?
Posted: 12 Sep 2013 16:56
I have just tested this: I closed all windows in the debugger besides the source code windows. The effect did not appear anymore when stepping through my code. Then I opened the "variables for current clause"-window and stepped again through the code. With that window opened the effect did show up again.
I had not realized before, that the effect is related to the "variables for current clause"-window, because in debugging I was used to have this window open always. I just tested also, to step through a trivial, but long running, program while having the "variables for current clause"-window open. The effect did not appear with the trivial program. Yet I was not able to figure out, displaying what variable triggers the issue. I suppose, it must be a variable of some type construct, which I have already used often.
Posted: 13 Sep 2013 8:14
It is natural that the time should be proportional (linear) to the amount of displayed data, because the data has to be fetched from your program.
However that should (unless you have a very old computer) not take minutes. Taking minutes indicates that we have made something worse than linear.
If you happen to narrow down the cause further please let us know, it will help us remove the problem. It is always far easier to eliminate a problem that you can reproduce.
Posted: 13 Sep 2013 16:57
I have sent a test case project via email to email@example.com
(Gmail added the alias "Elizabeth Safro" when I sent it - she must have been in my contact list). I am not able to upload the test case to the forum thread myself, probably file size is too big.
The test case produces the effect seemingly by random on my system. I.e. sometimes the debugger hangs at some step, other times all stepping is going normal. To reproduce the effect please try as follows:
Run the project with the debugger in 64 bit mode. It will stop at the one breakpoint, which I have set. Open the "variables in current clause"-window, if it is not open already. Now press F11 and keep holding it down. Release F11 after some moments, press F11 a few times, and again hold it down for some time. Try repeating this game for a time, restarting the debug run when it has run through normally. On my system it does not take long, until the debugger starts hanging.
My system is an HP EliteBook 2540p having 4 GB RAM running 64 bit Windows 7. The system isn't in the list of world's top 500 supercomputers, but it is not too old. With the test case the debugger produces delays of ca. 1 minute on my system. With more complicated programs I have seen longer delays already. On my system the effect has appeared often without having to hold F11 down, only a few F11 typing made it.
In the test case project I have used a construction similar to the one in my post "Crash in stdIo::write/0... ". So, maybe both problems come from one and the same origin. I am curious to hear about, whether you can reproduce the effect with my test case.
Posted: 14 Sep 2013 10:19
I will just add that I got a similar behavior when changing an antivirus. The problem was resolved by excluding the VIP applications of the fields of the antivirus work.
Posted: 14 Sep 2013 17:21
Hi, Martin. We have not received the test case at firstname.lastname@example.org
Did you make sure that the Obj and Exe directories was deleted before you zipped (or what you did) the project, with these directories the the resulting file will be many times larger than necessary.
Posted: 14 Sep 2013 21:48
I don't know, what went wrong with the email. The mail is in my "sent mails"-folder and I did not get a "delivery failure"-mail in return. Attachment size is 3903KB, which should not exceed Gmail's limit.
In the mail I had sent all directories. Because I tried deleting the Obj, Obj64, Exe and Exe64 directories and recovering them by rebuilding all platforms. But then stepping into called predicates with F11 did not function anymore for all predicates.
But well, here comes the test case without these directories (hopefully the upload will have succeeded, when I press "Submit" now).
Posted: 14 Sep 2013 22:26
Dominique, I have tested it: It happens too, when my virus scanner is stopped, and also, when I exclude my VIP application from scanning.
Posted: 15 Sep 2013 13:05
As I said before, if I recover the Exe/Obj-directories in my test case by "rebuild all platforms", then stepping into predicates by F11 does not work correctly. When I start the debug run, it stops at the one break point in line
After pressing F11 four times, the debugger is in line
in file grammar.pro. When I now press again F11, it runs through until the end of the program.
However I found behavior being different, when I do not initially rebuild all platforms, but start the debugger right away. The debugger then compiles the project and thereby also recovers the Exe/Obj-directories. Stepping through all source code with F11 works fine this way - besides that the "delay"-effect randomly shows up.
Posted: 24 Sep 2013 8:23
Thomas, have you been able to reproduce the delay-effect with my test case?
Posted: 24 Sep 2013 14:21
Not really, but I maybe I didn't try hard enough. I will ask somebody else to have a look at it
Posted: 24 Sep 2013 15:28
Yes, please ask someone - it is really a serious problem for me. I hope, somebody can reproduce the problem, so that you can grib it. If it is reproducible nowhere, something with my system must be wrong. The virus scanner is first suspect. But as far as I can see (and as I said before), the virus scanner cannot be made accountable here. Yet I have no idea, what configuration in my system could cause such problem. I can tell however, that the debugger did not produce delays for me in times of prior VIP versions.
I want to add the following, which possibly can give a further hint to the problem's cause: When control has returned after the debugger has been hanging for a time, any next command (resp. mouse click) causes it to hang again. It means, when I then click "Stop Debugging" or "Restart", execution of that is also delayed. Durations of delays vary. Short delays can take a half minute, in a longer delay I have canceled tasks after waiting more than a quarter hour.
Posted: 4 Nov 2013 16:39
has somebody of your collegues already taken a look at my test case? 15 minutes to unzip, compile and try it are presumably sufficient to reproduce the issue. Please (let) invest a quarter hour in trying.
Thank you in advance,
Posted: 4 Nov 2013 22:31
Sorry, I forgot to answer. We have not been able to reproduce the problem.