Crash - OOM & or z_Grafik

English support for the software AllDup
Post Reply
therube
Posts: 322
Joined: 07 Nov 2012, 00:28

Crash - OOM & or z_Grafik

Post by therube »

Crash - OOM & or z_Grafik

Not sure if these are accurate?

AppUp: 5 days 21:39:55
SysUp: 90 days 15:15:40

AppUp, eh, possible, but... ?
My uptime says 28 days (& except for a power outtage, would likely have been much > 90 days):
  • System information for \\RUBEN7:
    Uptime: 28 days 10 hours 27 minutes 18 seconds
    Kernel version: Windows 7 Ultimate, Multiprocessor Free
    Product type: Professional
    Product version: 6.1
    Service pack: 0
    Kernel build number: 7601
    Registered organization:
    Registered owner: RUBEN
    IE version: 9.0000
    System root: E:\Windows
    Processors: 4
    Processor speed: 3.4 GHz
    Processor type: Intel(R) Core(TM) i5-3570K CPU @
    Physical memory: 3792 MB
    Video driver: Intel(R) HD Graphics 4000
AllDup first started not drawing the screen correctly.
I closed a few (other) things, & jumped back, still AllDup not right, closed a few more (other) things...
At some point, AllDup crashed...

I had (still have) a LOT of windows open, ~144, & that may have played in to the issue?
A time before, with similar windows (programs running) & number of windows, i started noticing "oddities",
though closing some windows, caused those oddities to subside.
Not seeing anything specific to the particular file.
(Looking at it again, on restart of AllDup, no problem, nor in viewing it in a few other programs.)

I scanned, successfully, & was just going through, arrow-key down, the Results list looking at what was found.
(I'd been doing this for some time.) Hadn't marked anything or attempted to delete anything, just exploring what was found. Had used hotkeys to copy found names, many individual times (for use elsewhere), but that was pretty much the extent of it.

Any time I had looked (which I did do on occasion) RAM & CPU usage was negligible.

Anyhow...


---


Now: 10/26/2023 10:04:21 PM
App: AllDup 4.5.50
ExeInst: 11/01/2022 08:45:00 AM
IniCreate: 04/24/2019 07:39:02 PM
Modul: z_Grafik
Func: ZoomPicture1
Line: 410
Err: 480 - Can't create AutoRedraw image
Path: C:\DEV\DUPLICATE\AllDup4\alldup_commandline\AllDupPortable.exe
AppUp: 5 days 21:39:55
SysUp: 90 days 15:15:40
OS: Windows 7 Ultimate Edition SP1 (Build 7601) Version: 6.1 Build: 7601 ID: 2
64bit: True
IE: 9.11.9600
PhysRAM: 12,273.24 MB Free / 16,079.14 MB Total
MemLoad: 23%
RAM used: 37.39 MB
Pagefile: 21,839.57 MB Free / 32,156.43 MB Total
VirtMem: 1,649.23 MB Free / 2,047.88 MB Total
CPU: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
Screen: 1920x1200xUNKNOWN
Command: "W:\PICS\P2"
Portable: True
User: RUBEN
Comp: RUBEN7
FormCount: 3
FormNames: frmMain,frmDupSearch,frmPreview,
Apptitle: AllDup 4.5.50 PE
Datapath: C:\DEV\DUPLICATE\AllDup4\alldup_commandline
Admin: False
Errcount: 1
Lang: 9
Stop:0,0
Unicode:0
SM:0001000
Sb1:W:\PICS\P2\P2-PICS\VCD\34-7.jpg
Sb2:
Sb3: Groups: 561
Sb4: Files: 0 \ 1136
Debug0: 3
Debug1: 323
Debug2: 349
Debug3: 971
Debug4: 948
Debug5: 323
Debug6: 349
Debug7: 0
Debug8: 0
Debug9: 0
Debug10: 4845
Debug11: 14565
Debug12: 5235
Debug13: 14220
.
AllDup Crash - 34-7 OOM.png
Administrator
Site Admin
Posts: 4047
Joined: 04 Oct 2004, 18:38
Location: Thailand
Contact:

Re: Crash - OOM & or z_Grafik

Post by Administrator »

It looks like you have to restart your compter to fix this problem...
therube
Posts: 322
Joined: 07 Nov 2012, 00:28

Re: Crash - OOM & or z_Grafik

Post by therube »

(take this with a grain of salt, cause I don't really know what I'm talking about, & at least part of what I'm seeing likely is due to my particular setup/running, but... there is something here...)


AllDup (crashed @ P2-MD5 - 0891.jpg), 03:36 PM 11/04/2023
.
AllDup Crash - Handles 9999 10000.png
.

"crash" - GDI Handles 9999 10000
so "that's the issue", perhaps ? - YES, definitely
(certainly contributory)

Uptime: 30 days 22 hours 50 minutes 26 seconds
- DISAGREES with error.txt: SysUp: 99 days 6:22:53
- also 'Uptime:' (as reported by PsInfo) must only take actual running time into consideration (rather then running + sleep cycles - otherwise "Uptime:" would be more then 30 days, based on what was reported at the beginning of the thread)
AppUp: 4 days 15:33:52
- agrees with Process Hacker, so that is accurate


1. open
2. load filelist
- dang! i opened the wrong 1, i opened md5 & meant to open aHash... (in any case)
3. expand filelist
- open preview
4. arrow-key down the list, continuously, without pause, such that Preview did not have chance to display
5. arrow-key down the list, allowing Thumbnail to display (if existent, many were not)
- i iterated down through each Group / File(s) / Group / Files (s)
- i had /just/ about reached the end (oh, 95%+ i'd guess), at which time i crashed

6. shot of AllDup "uptime" (26.min)
.
AllDup Crash - Handles - arrow-key down list of names.png
.

didn't think to look (ahead of time), but on restarting AllDup (again)
[or at least somewhere along the line ?]
AllDup "programdir/temp/'guid'/" was empty, where i might have otherwise expected
thumbs to have been generated

should also note that upon hitting "9999" i "crashed", it was not an "outright" crash,
in that i was able to successfully close AllDup (at that point) simply by hitting the
[X] close button (which returned me from the Results List, back to the Main screen, &
where a [X] close then closed AllDup (cleanly [& i'm guessing in doing so, also wiped
out the generated thumbs ?]

i'll also note that i did not restart my computer since i ran into this before, nor did
i significantly reduce the number of windows i have open. (basically, since my last
"crash", i simply "carried on forward" ;-).)

pretty sure GDI Handles are limited to 10K (for a single process).
AllDup starts off with a significant number to begin with.
(Significant compared to most other programs i may happen to look at.)
then, arrow-keying down a list of files (image files as they were, with Preview open,
so thumbnails are generated...) greatly exacerbates the situation - until all Handles
are used up, & the program crashes.

(process hacker [process explorer ?] can interactively show gdi
handles, so you can arrange windows & /watch/ how gdi changes as
you arrow-key down a Result List)
(did not check to see if "simply" arrow-key down a list reacts the same as arrow-key
down while Preview was open; i.e., if it might be more then just a "thumbnail"
related kind of issue)

- appears that "GDI" overall is the issue, & "Bitmap" (as GDIView calls it) plays in too.
- looks like it is more the Group itself, rather then the individual items in a particular group, that are more apt to cause the issue (or at least the Group has a greater influence)
- appears issue is primarily related to "images" (Picture search)

Is it when you are on a Group that the /temp/'guid'/*.png are generated?



in addition...

simply purging (the list of) "directories" [Which drives or folder should be scanned...] has a significant impact on GDI
handles used - on program open (so aside from anything else)

1. i started with (what was there, which was) 281 directories (per [Ordnerlist])
- deleted same (from withing AD) & quit
2. restart AD
- GDI handles, with that change alone, down from ~2300 to ~900
- quit
- manually delete config4.ini
3 restart AD
- GDI handle usage ~same as having deleted all pre-existing directories
- though oddly, one might think, higher here then in 2
- but then, maybe not, as (in my case) a "new" config4.ini populates itself
with 18 entries
.
AllDup GDI handles usage DROP by deleting directory entries.png
.

on this particular "profile", i typically start DC from a command-line, & i'm
typically only concerned about the particular directory tree i happened to be
in, so in that regard, that i happened to have 300 directories accumulated,
was of no concern. that 1 or 1000 directories may have been listed was
immaterial.


regardless of [Ordnerlist], GDI Handles are still, high.
(Granted, just because they may be high isn't an issue in & of itself,
but when you're running out of them...)


GDIView - View GDI handles/resources list and detect GDI leaks
Process Hacker
A customer had a line-of-business application that frequently bumped into the default limit of 10,000 GDI handles per process.
PsInfo is a command-line tool that gathers key information about the local or remote Windows NT/2000 system
What's the upper limit on GDI objects for one process in Windows 7?

Code: Select all

10/21/2023 02:49:44 AM - INFO: Unable to detect VLC Media Player 32-bit version 3 on your system
10/21/2023 02:49:44 AM - --------------------------------------------------
10/21/2023 02:49:44 AM - AllDup 4.5.50 PE
10/21/2023 02:49:44 AM - Search method: Find similar pictures
10/21/2023 02:49:44 AM - Comparison method: MD5 (128-Bit)
10/21/2023 02:49:44 AM - Image Formats: BMP, GIF, JPEG, JPG, PNG
10/21/2023 02:49:44 AM - Match: 100%
10/21/2023 02:49:44 AM - Picture area: entire picture
10/21/2023 02:49:44 AM - Comparison size: 100% Pixel
10/21/2023 02:49:44 AM - Checksum Strength: 128 Bit
10/21/2023 02:49:44 AM - Compare only pictures with the same properties:
10/21/2023 02:49:44 AM - Orientation, Aspect ratio
10/21/2023 02:49:44 AM - 1.Source folder: W:\PICS\P2
10/21/2023 02:49:44 AM - Option: Compare files from all source folders
10/21/2023 02:49:44 AM - Folder filter activated: 8
10/21/2023 02:49:44 AM - Filter type: Exclusive
10/21/2023 02:49:44 AM - 1.folder filter: e:\windows
10/21/2023 02:49:44 AM - 2.folder filter: e:\program files (x86)
10/21/2023 02:49:44 AM - 3.folder filter: e:\program files
10/21/2023 02:49:44 AM - 4.folder filter: ?:\system volume information
10/21/2023 02:49:44 AM - 5.folder filter: ?:\recycled
10/21/2023 02:49:44 AM - 6.folder filter: ?:\recycler
10/21/2023 02:49:44 AM - 7.folder filter: ?:\$recycle.bin
10/21/2023 02:49:44 AM - 8.folder filter: c:\local\ruben\temp\par-525542454e\cache-exiftool-11.10
10/21/2023 02:49:44 AM - Determine file count of all source folders...
10/21/2023 02:49:45 AM - File count: 64,230
10/21/2023 02:49:45 AM - Scan: W:\PICS\P2
10/21/2023 02:58:10 AM - ERROR: An error occurred while creating the checksum of the file ...
... (80 more) ...
10/21/2023 09:39:24 AM - Files filtered: 255
10/21/2023 09:39:24 AM - Found 1,256 duplicates with a total of 122.78 MB inside folder 'W:\PICS\P2'
10/21/2023 09:39:24 AM - Scanned files: 64,230
10/21/2023 09:39:24 AM - Groups: 617
10/21/2023 09:39:24 AM - File comparison count: 391,753,534
10/21/2023 09:39:24 AM - Checksums created: 63,966
10/21/2023 09:39:24 AM - Duplicates: 1,256 (1%) (122.78 MB)
10/21/2023 09:39:24 AM - Elapsed time: 06:49:40   (not accurate cause of system sleep)
Last edited by therube on 07 Nov 2023, 00:43, edited 2 times in total.
therube
Posts: 322
Joined: 07 Nov 2012, 00:28

Re: Crash - OOM & or z_Grafik

Post by therube »

On a different computer, MUCH less going on, with a far lessor set of data to work with, with some oomph, I was able to get GDI up to ~5000 (1/2 of max) (& on startup [also, like above] ~1000 GDI handles).
.
AllDup GDI handles - Dell - oomph vs startup.png
Administrator
Site Admin
Posts: 4047
Joined: 04 Oct 2004, 18:38
Location: Thailand
Contact:

Re: Crash - OOM & or z_Grafik

Post by Administrator »

AllDup 4.5.52, Win10x64

GDI-Handles (Windows Task-Manager > tab details > column GDI-Objects):

1. after starting Alldup: 1079
2. after the scan is done: 1472
3. clicking on a group with 47 BMP-files: 1563
4. clicking on a group with 2 JPEG-files: 1500
5. clicking on a group with 10 PCX-files: 1518
6. clicking on a group with 23 TIF-files: 1551
7. clicking on a group with 3 WMF-files: 1507
8. after closing the search result: 1169
therube
Posts: 322
Joined: 07 Nov 2012, 00:28

Re: Crash - OOM & or z_Grafik

Post by therube »

From what I could make of it, it was more the Group, itself, rather then the items in the group.
So if you're arrow-keying down a long list (like in the OP it was, Sb3: Groups: 561, & over time or not, you might be more apt to see this.

Anyhow.
Administrator
Site Admin
Posts: 4047
Joined: 04 Oct 2004, 18:38
Location: Thailand
Contact:

Re: Crash - OOM & or z_Grafik

Post by Administrator »

I created a search result with 1086 groups of pictures. After arrow-keying down more than half the list the GDI-handles are only at 1543 and the value never reaches 1600 all the time.
therube
Posts: 322
Joined: 07 Nov 2012, 00:28

Re: Crash - OOM & or z_Grafik

Post by therube »

I think I figured out what you did wrong ;-).
(What you did not do in order to see the issue.)


If you iterate down the Results list - but have not 'Expand all groups', then as you go down, you are going from Group to Group to Group...
And in that manner, the number of GDI Handles remains relatively static.

If you 'Expand all groups' & then iterate down the Results list, so you're then going down as:
Group-File-File - Group-File-File-File-File-File - Group-File-File-File - Group...
With that, I think you should see the issue.
(I normally always 'Expand all groups' so I did not catch where not expanding all did make a difference in what was seen.)

Also, Image (File) Preview must be enabled.
If not enabled, you won't see it.

And Image file types (.jpg, .png, ...) are required.
Other file types (.txt, .doc) didn't see to be an issue (that I saw).
(I did not look at video.)

Likewise, you cannot just hold the arrow-key in a down position & progress down the list as that will not show the issue.
You need to arrow-down . arrow-down . arrow-down...


If you did 'Expand all groups' in your testing, then I'll have to look further.
Administrator
Site Admin
Posts: 4047
Joined: 04 Oct 2004, 18:38
Location: Thailand
Contact:

Re: Crash - OOM & or z_Grafik

Post by Administrator »

I was finally able to reproduce the issue and fix the memory leak! Thanks a lot for you feedback!
Administrator
Site Admin
Posts: 4047
Joined: 04 Oct 2004, 18:38
Location: Thailand
Contact:

Re: Crash - OOM & or z_Grafik

Post by Administrator »

New update with the GDI leak fix is available for download.
therube
Posts: 322
Joined: 07 Nov 2012, 00:28

Re: Crash - OOM & or z_Grafik

Post by therube »

Fixed.

Thank you :-).
Post Reply