I was working in the Editor - the last keystroke I recall was an up-arrow. Error window popped up, but Toad locked up before repainted the screen so no error message. It has been unresponsive, chewing up memory, for the last 10 minutes, so I will kill it.
Michael, appears that an .el file was created which I can send to you.
I’ve had something real similar in versions <.40 (just applied latest patch). In both cases, I had compiled a >1400-line package body that resulted in an error, then attempted to arrow to the highlighted line with that error.
Rich
There are several reports of pretty much the same issue. Dale's log file matches what I've seen from others. I don't yet know what's causing it, but it appears as though Toad's running out of graphics resources. I can fast track reproduction on my machine by
trying to load 512 files. I'll get the exception sometime before it finishes. By default Windows has a limit of 10,000 GDI handles per process with a theoretical system-wide cap of 65,536. The per-process limit can be bumped up in the registry (requires restart)
and I was able to get beyond the error after doing so. However, why Toad beta is using so many more handles than 12.6 still has me stumped.
On 02/05/2015 03:09 PM, Rich J. wrote:
Reply by Rich J.
I've had something real similar in versions <.40 (just applied latest patch). In both cases, I had compiled a >1400-line package body that resulted in an error, then attempted to arrow to the highlighted line with that error.
Rich
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or
Unsubscribe from Toad for Oracle - Beta notifications altogether.Toad for Oracle - Beta Discussion Forum
Flag
this post as spam/abuse.
Hey Michael,
I’ve snapped a shot of my Toad process and its handles (using Sysinternals’ ProcessExplorer). If it happens again, I’ll snap another for comparison.
I think I also got an “out of memory” at some point, and my first thought is that with 16GB of RAM on a 64-bit OS, that shouldn’t be happening. I was busy at the time and didn’t check things like free System PTEs (I need to lookup again how to do that), but I’ll see about adding in things like that next time.
Any other info I should include? I may have to sanitize my elf, if needed, for legal reasons…
Lemme know!
Rich
I'm not sure what else you should include. I think I have enough to go on now that I can reproduce it, but perhaps confirmation that what you're seeing matches what I'm seeing would be helpful. I'm hoping this is a single, nasty bug and not multiple.
I have Handles set to display in PE and it always displays less than the 10,000 cap when I hit the error; however, there's another useful utility,
GDIView. It's standalone and can be run after Toad crashes provided that Toad is still present in some fashion. There are columns for All GDI and GDI Total.
Nirsoft has this to say about the two...
" The
'GDI Total' column (a new column added on v1.05) displays the total number of all GDI handles found in the GDI table for the specified process. This means that 'GDI Total' column display the sum of the following columns: Pen, ExtPen, Brush, Bitmap, Font, Palette,
Region, DC, Metafile DC, Enhanced Metafile DC, and Other GDI.The
'All GDI' value is taken from Windows API call (GetGuiResources), and it usually contains a value larger than 'GDI Total', probably because it also counts some internal kernel GDI objects that are not included in the GDI objects table of the process."
The GDI Total column shows handle counts that more closely match what PE displays, but without fail when Toad crashed for me the All GDI was sitting on 10,000 exactly every time through repeated tests. When I
increased the 10,000 per-process limit to 65,536 I was able to load 512 files without crashing and GDIView was reporting ~12-14K handles. I'd be really curious to know what you're sitting at when it crashes to see if there's a common problem here.
If you get a Toad.el file generated the following lines in the call stack have been present in all of the logs I've received from users and in testing.
"Canvas does not allow drawing" exception
|7FFFFFFE|04 |0000000000000000|00000000043D198D|Toad.exe |000000000024198D|Vcl.Graphics |TCanvas |RequiredState |4191[8] |
|00000040|04 |000000000042ADB8|00000000043D1810|Toad.exe |0000000000241810|Vcl.Graphics |TCanvas |GetHandle |4141[2] |
"The parameter is incorrect" exception
|7FFFFFFE|04 |0000000000000000|00000000043D22AC|Toad.exe |00000000002422AC|Vcl.Graphics | |GDIError |4349[10] |
|00000040|03 |0000000000429C78|000007FEFD959407|KERNELBASE.dll|0000000000009407|KERNELBASE | |RaiseException | |
Thanks,
Michael
On 02/05/2015 04:25 PM, Rich J. wrote:
Reply by Rich J.
Hey Michael,
I've snapped a shot of my Toad process and its handles (using Sysinternals' ProcessExplorer). If it happens again, I'll snap another for comparison.
I think I also got an "out of memory" at some point, and my first thought is that with 16GB of RAM on a 64-bit OS, that shouldn't be happening. I was busy at the time and didn't check things like free System PTEs (I need to lookup again how to do that),
but I'll see about adding in things like that next time.
Any other info I should include? I may have to sanitize my elf, if needed, for legal reasons...
Lemme know!
Rich
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or
Unsubscribe from Toad for Oracle - Beta notifications altogether.Toad for Oracle - Beta Discussion Forum
Flag
this post as spam/abuse.
I have a long history of dealing with TOAD using too much GDI handles and not releasing them. Working with many databases and windows the 10000 GDI cap is reached very quickly by TOAD.
TOAD beta (as of 12.7.0.43) however seems to have re-introduced issue of not releasing / leaking GDI handles. I was working with several db’s and multiple windows (editor/schema browser/session browser mostly) when I hit 10000 GDI limit.
So I’ve closed all the windows and db connections, and TOAD still holds over 5000 GDI handles:
Process Name : Toad.exe
Pen : 7
ExtPen : 0
Brush : 66
Bitmap : 241
Font : 39
Palette : 52
Region : 978
DC : 75
Metafile DC : 0
Enhanced metafile DC: 1
Other GDI : 1
GDI Total : 1460
All GDI : 5006
Note the difference between “GDI Total” and “All GDI”.
“All GDI” of GDIView = “GDI Objects” of PE. Reaching 10000 makes bad things happen in TOAD.
Some useful information from NirSoft page:
"Notice: If you have a problem that the ‘All GDI’ value is increased, while there is no leak with the other GDI values, it means that you probably have a leak in the creation of icons or cursors (Icons and cursors are created without destroying them later). "
I’m definitely seeing more GDI usage by beta than 12.6 in the Editor, but closing everything releases them.
What were you doing in Toad before closing all connections/windows… which windows were open, features used within those windows, number of connections, number
of tabs open in editor, etc.? If you zip and send me your user files folder I’ll setup your scenario with your user files.
Michael.staszewski@quest.com.
Thanks,
Michael
From: Piotr [mailto:bounce-piotrwrzosek@toadworld.com]
Sent: Thursday, February 19, 2015 8:54 AM
To: toadoraclebeta@toadworld.com
Subject: RE: [Toad for Oracle - Beta Discussion Forum] Editor - another Toad lock-up
RE: Editor - another Toad lock-up
Reply by Piotr
I have a long history of dealing with TOAD using too much GDI handles and not releasing them. Working with many databases and windows the 10000 GDI cap is reached very quickly by TOAD.
TOAD beta (as of 12.7.0.43) however seems to have re-introduced issue of not releasing / leaking GDI handles. I was working with several db’s and multiple windows (editor/schema browser/session
browser mostly) when I hit 10000 GDI limit.
So I’ve closed all the windows and db connections, and TOAD still holds over 5000 GDI handles:
Process Name : Toad.exe
Pen : 7
ExtPen : 0
Brush : 66
Bitmap : 241
Font : 39
Palette : 52
Region : 978
DC : 75
Metafile DC : 0
Enhanced metafile DC: 1
Other GDI : 1
GDI Total : 1460
All GDI : 5006
Note the difference between “GDI Total” and “All GDI”.
“All GDI” of GDIView = “GDI Objects” of PE. Reaching 10000 makes bad things happen in TOAD.
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or
Unsubscribe from Toad for Oracle - Beta notifications altogether.
Toad for Oracle - Beta Discussion Forum
Flag
this post as spam/abuse.
The most GDI-hungry window seems to be schema browser, with lots of icons for different types of objects.
For me going through all selected object types in one schema browser window can add 1000+ GDI objects (All GDI, counting toward the process limit).
And this is not shared between other schema browser windows, so they easily add up.
New empty editor window is +400, new tab is +27.
Session browser window +110.
Normally closing them does release GDI handles, but on some specific condition that does not happen. It may be some error from which it’s possible to recover and continue working in Toad, but resulting in not disposing used resources on close.
I mostly work with above mentioned windows, but across about 20 database connections. I’m reusing windows when possible, but it is not uncommon for me to eventually run out of letters in window menu 
- I have many active/current tasks during the week.
I’ll try to watch it more closely to see if I can find the cause of this issue.
