Sporadic errors 205 and 206 with vip 7.2.02

Discussions related to Visual Prolog
Matthias Greving
Posts: 18
Joined: 21 Mar 2002 0:01

Sporadic errors 205 and 206 with vip 7.2.02

Unread post by Matthias Greving » 13 Aug 2010 8:39

Hello,

in the last month I got several messages from users who complain about error messages they see in our Prolog application. I contaced them an asked for specifics, but there is no common pattern I could recognize. They all have an application compiled with Visual Prolog 7.2.02. Since the application is huge, and the error messages give no further hints on the code which might cause this, my hope is that you have seen similar messages and can give me a probable cause or a hint where I could start looking.
I have tried to reproduce these messages on my development PC, but with no result. I have seen them in the past on my PC too, but I can not find any pattern here too.

Any ideas?
Thanks.


Here the messages I mean:

1) Just an Error Box with a Hex value in it, in this case it is 14005F4C

2) Error 205

Exception: gcError (com/visual-prolog/exception/runtime_exception)

Exception in Garbage collector

error code = 205
ExtraInfo = Erorr in Garbage Collector: 'Too many heap sections'

3) Error 206

Exception: heapOverflow (com/visual-prolog/exception/runtime_exception)

Heap overflow

error code = 206
ExtraInfo = Heap exhausted. Request=1185884 (0x0012185C)

raised() 2010/06/24 15:28:38
ThreadId=3136
ClassInfo: com/visual-prolog/exception/runtime_exception $JustDate: 2008-02-20 $$Revision: 14 $

Chan Bok
VIP Member
Posts: 69
Joined: 13 Sep 2000 23:01

Unread post by Chan Bok » 13 Aug 2010 17:04

I had a similar problem (see details below) recently with VIP7.2.
I am also unable to reproduce the problem at my end.

Best Regards,



==================================

>> Dear Chan,
>>
>> after typing continuously into the Freewriter, I suddenly was surprised by the following program error:
>>
>> ========================================
>> Dump: 2010/08/04 16:30:20
>> ----------------------------------------
>> Exception: heapOverflow (com/visual-prolog/exception/runtime_exception)
>>
>> Heap overflow
>>
>> error code = 206
>> ExtraInfo = Heap exhausted. Request=100139006 (0x05F7FFFE)
>>
>> raised() 2010/08/04 16:30:20
>> ThreadId=5116
>> ClassInfo: com/visual-prolog/exception/runtime_exception $JustDate: 2008-02-20 $$Revision: 14 $
>>
>>
>> I closed the Program Error window, and continued to write, but the error arose again. And after closing Axon and restarting, I managed to reproduce this error again by typing into the Freewriter for a while.
>>
>> It seems that the error arises when Axon begins to do something in the background while the typing is continued: Suddenly the characters are no more displayed or with a certain delay, shortly before the error occurs.

>>I have several other programs running: Lotus Notes, Excel, Firefox, Internet Explorer, Explorer, Editor - perhaps to much for additionally using the FreeWriter. But none of these other programs reports some error saying "Memory to low" or something like that, only the FreeWriter comes up with this. I also have 2 G memory and Windows XP.
Chan Bok
Axon Research

Chan Bok
VIP Member
Posts: 69
Joined: 13 Sep 2000 23:01

Unread post by Chan Bok » 13 Aug 2010 18:51

Another crash report just came in (for VIP7.2)


=========================
>Hi Chan,
>
>I created a file in Axon.
>Most images are attached, a few are embedded.
>After opening the file, I can do about five to ten basic operations with my mouse (like left/ right >clicking objects) before Axon crashes. From start to crash, it takes about 15 seconds.
>
>I have included an mht error report for clarification.
>
>Hopefully it is possible to find an improvement.

Best regards,
xxxxxxxx

========================================
Dump: 2010/08/13 19:59:04
----------------------------------------
Exception: heapOverflow (com/visual-prolog/exception/runtime_exception)

Heap overflow

error code = 206
ExtraInfo = Heap exhausted. Request=6262806 (0x005F9016)

raised() 2010/08/13 19:59:04
ThreadId=5056
ClassInfo: com/visual-prolog/exception/runtime_exception $JustDate: 2008-02-20 $$Revision: 14 $


C:\Program Files (x86)\Axon2011\VIP7Kernel.dll (0x14004410)
Chan Bok
Axon Research

Gildas Menier
VIP Member
Posts: 78
Joined: 8 Jun 2004 23:01

Unread post by Gildas Menier » 13 Aug 2010 19:18

Dear Chan,

There is one think I use with extreme caution in Visual Prolog, because I know for sure it can produce memory leaks : I use to program graphic display with double buffering to avoid flickering.

I allocate an image (pictureCanvas/getPicture), draw the graphics in it, then picdraw the image to the screen, and then, only then, I draw the text on the screen.

If I draw the graphics AND the text offscreen, I can reproduce memory leaks similar to yours, sometimes immediatly, sometimes after a while. I seems to be related to GDI:drawText or setfont, I don't know. When I draw the text after the picdraw (this doesn't avoid text flickering) I can let the program run a day long without any memory leaks.

So my suggestion is : try to set a timer to redisplay your screen each n ms, let your program display a complex drawing and wait. If you catch such an error, try to remove the setfonts or extract the drawtext from a double buffering process.

I wish you'll find the problem

Best regards

Gildas

User avatar
Thomas Linder Puls
VIP Member
Posts: 2450
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 13 Aug 2010 22:55

You should also read Memory Management and Garbage Collection in Visual Prolog 7 (on page 88) by Carsten Kehler Holsts.

You should also notice that false pointers is a much smaller problem in Vip7.3 than in Vip7.2.
Regards Thomas Linder Puls
PDC

Chan Bok
VIP Member
Posts: 69
Joined: 13 Sep 2000 23:01

Unread post by Chan Bok » 14 Aug 2010 7:52

Thanks for the helpful suggestions from Gildas and Thomas.

I am indeed using double buffering extensively.

I will spend time looking into this problem.

Best Regards,
Chan Bok
Axon Research

Matthias Greving
Posts: 18
Joined: 21 Mar 2002 0:01

Unread post by Matthias Greving » 18 Aug 2010 13:20

Hello,

thanks for your hints. I did a bit of testing and could provoke the issue with the setFont on the canvas. This is an issue (there has been a post about this before http://discuss.visual-prolog.com/viewtopic.php?t=7716) but this produces a different error (6002, at least in our application). This is still an issue in Vip 7302.

I have also used the memory profiler, but no luck there too. Whatever I do with the application does not provoke the error 205 or 206 or unusual heap consuption, only the users get these errors.


Exception: vpi_Data_alloc (com/visual-prolog/vpi/vpi)

Error allocating data

ExtraInfo = Not enough memory
error code = 6002

raised() 2010/08/18 14:46:45
ThreadId=556
ClassInfo: com/visual-prolog/vpi/vpi $JustDate: 2009-03-04 $$Revision: 39 $

Gildas Menier
VIP Member
Posts: 78
Joined: 8 Jun 2004 23:01

Unread post by Gildas Menier » 19 Aug 2010 8:15

Hi Matthias,

Another suggestion (?)

If you use threads, check that the threads properly leave. If you abort/terminate a thread, you can be sure that the heap attached to the terminated threads can be a source of leak. (ie after the rule 1.check the setfont with the double buffering, I would state 2.check the termination of the threads).

Best regards

Gildas

Matthias Greving
Posts: 18
Joined: 21 Mar 2002 0:01

Unread post by Matthias Greving » 19 Aug 2010 8:29

Hello Gildas,

thanks for your reply, yes I was looking for other suggestions.

But no, I don't uses threads in that application, there is only the main thread.

My problem is that I can not reproduce the errors the users have.

regards
Matthias

Gildas Menier
VIP Member
Posts: 78
Joined: 8 Jun 2004 23:01

Unread post by Gildas Menier » 19 Aug 2010 11:13

Do you use some 3rd party dll ? My #3 suggestion would be a poorly coded binding or different dll versions for you and your clients ?

Gildas

Matthias Greving
Posts: 18
Joined: 21 Mar 2002 0:01

Unread post by Matthias Greving » 19 Aug 2010 12:27

Hello Gildas,

no, we don't use 3rd party dll's and we distribute the vip dll's with each distribution and the application checks the CRC sum of the application and the dll's on each start of the application.
We only have some calls to shellexecute and some other Windows api functions. There could be a source for an isse where these functions need byte fields. I think this is worth for me to check, but I don't have much hope to find the reason there.

Matthias

Post Reply