Problem z niczego...

@lampasss: mnie namawiał, to opiszę, a nóż widelec ktoś coś będzie wiedział ;-)

U jednego klienta, na różnych komputerach, są z moim systemem dziwaczne problemy.
Aplikacja napisana w Delphi XE, działająca na Win10 Pro (kompilacja 17134.407).
Klient zgłasza, że program działa dobrze, po jakimś czasie zaczyna działać wolniej albo się zacina, zawiesza a w efekcie często po protu znika bez komunikatu błędu.
Używam Eureki, ale ona również niczego nie widzi.

Problem występuje tylko u jednego klienta (ale na wielu komputerach w firmie), ta sama aplikacja u innych działa poprawnie.
Sprawdziłem wszystko co mogłem w programie i jego otoczeniu, wszystko wydaje się OK.

I nagle wczoraj, na sesji z klientem zauważyłem coś, co mnie zmroziło.

1. User odpala akcję dodaj załączniki
2. Otwiera się standardowy OpenDialog.
3. User wybiera pliku, które są dodawane do danego dokumentu.

Po chwili system wisi, potem znika.
Myślę: StackOverflow w aplikacji?

Sprawdzam jeszcze raz, ale coś mnie tknęło i włączyłem sobie TaskManagera z boku.

1. Odpal formatki, wszytko ok.
2. Chcę dodać załącznik, dodając plik z dysku.
3. Odpala się OpenDialog i pamieć zostaje zużywana przez proces mojego programu w tempie 10-50 MiB na sekundę. Na oko. Po zamknięciu Open Dialog RAM dalej rośnie i nie przestaje aż do totalnej zwiechy.

W pierwszej chwili myślałem, że może coś ze strumieniami pogmerałem (które są używane przy wczytywaniu plików) albo cokolwiek.
Ale dobra, proszę klienta o restart aplikacji i chcę sprawdzić czysty OpenDialog bez żadnych strumieni.
Wiem, gdzie mam prosty temat również ze standardowym OpenDialog.
Wykonujemy akcję, która odpala OpenDialog i program w tle nic nie robi - po prostu czeka aż OpenDialog się zamknie.

Otwarcie OpenDialog, znowu powoduje masowe zużywanie RAM.
WTF?!

Zauważam, że klient używa OpenDialog na wypasie - z włączonymi wszelkimi podglądami plików.
Używa dużo PDFów i przeglądarki PDFów z Acrobat Readera, która się integruje z Windows Explorer.
I ta przeglądarka jest osadzona w OpenDialog.
Nie wiem czy to trop, ale proszę go takie skonfigurowanie dialogów, aby przeglądarki plików i katalogów zostały wyłączone.
Sprawdzam ponownie.
Teraz działa normalnie.

Czy ktoś coś wie?
Czy ktoś z Was spotkał się z takim tematem?
A może jakieś sugestie?

Sam chcę sprawdzić inne użycie OpenDialog. Może nie Delphiowe (które używa standardowego OpenDialog z windows), jeszcze nie wiem co i jak dokładnie...

Daj może tutaj "gołą" aplikacje testową (w sensie - sam mechanizm z OpenDialogiem), zobaczę, czy u mnie się zachowuje podobnie.

Trop z PDF może być trafny, u mnie kiedyś PDF sam w sobie w sytemie otwierał się 20 sekund, a pliki były małe.
Prosta akcja, niech ktoś nawet na innej wersji delphi - ja mam Berlina tomogę Ci wystawić jakąś formatkę z Opendialogiem i sprawdzisz apke u Klienta.
Jak będzie powtórka to czyli nie wina delphi.

Dla wszystkich, którzy czytają, mam update info ;-)

Problemy występuje przy zwykłym OpenDialog.Execute - i tu już jest masowe zużycie pamięci.
Ale występuje tylko wtedy, gdy OpenDialog ma włączony podgląd drzewa katalogów. Bez tego podglądu drzewa katalogów, wszystko zachowuje się normalnie. Podgląd plików w OpenDialog też nie powoduje problemów.

Ja mam dokładnie tę samą wersję systemu co klient, u mnie problemów nie ma.
Zresztą u innych klientów, też nie ma...

Co ma ten klient, czego nie mają inni?
Używa sporej ilości zamapowanych dysków sieciowych, które udostępnia Synology RS814 z DMS 6.1.
Widziałem, ze czasem te dyski w OpenDialog są widoczne jako nieaktywne, ale klikniecie na taki dysk spowoduje jego wybudzenie.
Może to jest jakiś trop?

@cerrato Goła aplikacja testowa, to formatka z OpenDialog.Execute. I taki problem pewnie nie wystąpi u Ciebie jak i nie występuje u mnie :/
@lampasss Nie jest to problem z PDF ani z obsługa plików w aplikacji. To ma sprawdzone dokładnie.

PS.
Dzięki za zainteresowanie :)

a nie ma jakichś dodatków do Eksploratora, np. Clover https://www.dobreprogramy.pl/Clover,Program,Windows,37495.html czy czegoś podobnego?

żywa sporej ilości zamapowanych dysków sieciowych

No to na logikę, najprostszym krokiem jest wywalenie tych dysków na czas testów i zobaczenie, czy error się będzie pojawiać.
Napisz jeszcze (bo nie do końca jest to jasno powiedziane), czy na tych "wadliwych" kompach problem się pojawia zawsze, czy tylko jak mu się zachce. W sensie - na ile jest reprodukowalny?

abrakadaber napisał(a):

a nie ma jakichś dodatków do Eksploratora, np. Clover https://www.dobreprogramy.pl/Clover,Program,Windows,37495.html czy czegoś podobnego?

Z tego co wiem na dziś, jest używany preview od Acrobat Readera i Office i nic więcej.
Ale oczywiście dowiem się więcej, też moje podejrzenia meandrują w tę stronę.

Ale - dlaczego problem znika po wyłączeniu drzewa katalogów?
Tego nie potrafię wyjaśnić.
Jeszcze :)

cerrato napisał(a):

żywa sporej ilości zamapowanych dysków sieciowych

No to na logikę, najprostszym krokiem jest wywalenie tych dysków na czas testów i zobaczenie, czy error się będzie pojawiać.

Dokładnie i tak będziemy to testować.

Napisz jeszcze (bo nie do końca jest to jasno powiedziane), czy na tych "wadliwych" kompach problem się pojawia zawsze, czy tylko jak mu się zachce. W sensie - na ile jest reprodukowalny?

I to jest ciekawe, bo wg moich obserwacji problem występuje zawsze, ale nie zawsze przy pierwszym uruchomieniu OpenDialog.
Czasem jest to 1, a czasem 5 odpalenie OpenDialog, ale w końcu zawsze wystąpi.
Userzy tam dodają masę plików do systemu.
Czasem popracują godzinę, czasem pół dnia a czasem 5 minut...

Najciekawsze jest to, że aplikacja alokuje co jakiś czas (na oko co kilka sekund) ilość RAM, którą alokuje OpenDialog przy Execute.
Dzieje się to po zamknięciu OpenDialog (tak jakby w tle działała pętla co kilka sekund robi OpenDialog.Execute i nie zwalniała pamięci), ale dzieje się to poza aplikacją (w WindowsAPI), ale w kontekście procesu aplikacji. No masakra jakaś...

Najciekawsze jest to, że OpenDialog zawsze powoduje zużycie RAM. Tam jest ładowana cała masa bibliotek i dodatków COM, a wszystko jest wstrzykiwane w proces nadrzędny (wywołujący OpenDialog).
Tak to działa w Windows i koniec.

Znalazłem rozwiązanie - napisanie programu, który tylko Odpala OpenDialog i się zamyka, a dane do nadrzędnej aplikacji przekazuje jakoś (np. pipe czy WM_COPYDATA).
To wygląda na chory temat, ale jak nie będę miał wyjścia...

Jeszce jeden UpdateInfo od kolegi programisty:

TOpenDialog i tFileOpenDialog działają tak samo. Nawet używają tych samych obiektów.
Przy obu pamięć rośnie do 10MB... 15MB przy przeglądaniu. Jak naprzemiennie ich używasz w tym samym programie to nadal jest 10MB (czyli korzystają pod spodem z tych samych obiektów).

Raz na kilkanaście wywołań u mnie, bez żadnej widocznej przyczyny Tortoise się podłącza pod ten proces i zaczyna sobie cache budować.
i to nie ma znaczenia czy przeglądam katalogi gita, czy nie.

Tylko co się podłącza u mojego klienta?

Znalazłem rozwiązanie - napisanie programu, który tylko Odpala OpenDialog i się zamyka,

Prowizorka, ale może być skuteczna ;)
Zresztą - jak coś jest głupie, ale działa, to znaczy, że nie jest głupie ;)

cerrato napisał(a):

żywa sporej ilości zamapowanych dysków sieciowych

No to na logikę, najprostszym krokiem jest wywalenie tych dysków na czas testów i zobaczenie, czy error się będzie pojawiać.

Sprawdzone; odłączenie wszystkich dysków sieciowych, a włączenie widoku drzewa katalogów w OpenDialog niczego nie zmienia.
Tak więc drogą eliminacji na dziś wiem, że to jedyne rozwiązanie (wyłączenie drzewa katalogów w OpenDialog), które daje pozytywne wyniki.

Panie @wloochacz - czy mamy jakieś nowe informacje odnośnie "problemu z niczego"? ;)

@wloochacz: minęły dwa tygodnie od ostatniego posta. Czy coś udało Ci się w temacie wyjaśnić? Masz może jakieś nowe obserwacje, teorie albo inne rzeczy, którymi fajnie by było się z nami podzielić? :P

Nic nowego poza tym co napisałem wcześniej.
Po prostu na kilku komputerach (nie na wszystkich w tej samej firmie) włączanie drzewa katalogów w Open i SaveDialog powoduje takie jaja.
Co ciekawe, tam są dwa identyczne komputery Dell i na jednym problem występuje a na innym nie.

Nie posiadam szerszych informacji o różnicach w oprogramowaniu firm trzecich (jakieś CAD/CAM tam jest, ale nie wiem dokładnie co) na tych Dellach.

Po prostu napisaliśmy sobie wrapper na Open/Save Dialog i tyle.
Ekonomika wygrała - nikt minie zapłaci za głęboki research ;-)

A informacji na interentach u zużyciu ramu przy różnych scenariuszach użycia Eksploatatora Windows jest całkiem sporo...

Po prostu napisaliśmy sobie wrapper na Open/Save Dialog

A czy napiszesz coś więcej? Wcześniej pojawiła się opcja/pomysł, żeby stworzyć osobną apkę, której jedynym zadaniem będzie odpalenie dialogu, a potem (zanim pojawią się zwiechy) zamknięcie się. Właśnie w tym kierunku poszedłeś, czy wykminiłeś coś innego?

cerrato napisał(a):

Po prostu napisaliśmy sobie wrapper na Open/Save Dialog

A czy napiszesz coś więcej?

A co tu pisać?

Wcześniej pojawiła się opcja/pomysł, żeby stworzyć osobną apkę, której jedynym zadaniem będzie odpalenie dialogu, a potem (zanim pojawią się zwiechy) zamknięcie się. Właśnie w tym kierunku poszedłeś, czy wykminiłeś coś innego?

Tak, jest apka która ma takie zadanie jak wyżej i komunikacja pomiędzy procesem (to musi być nowy proces, który startuje, odpala dialog, zwraca dane i zamyka się - inaczej będzie tak samo jak wcześniej, tylko w innym procesie) głównym a wrapperem.
To wszystko.
Nie za bardzo jest co wykminić co innego; testowałem tez OldStylDialog, ale to nie wprowadziło żadnych zmian.
A pisać własny dialog od zera naprawdę mi się nie chciało.

To jeszcze napisz proszę (i obiecuję - przestanę Cię męczyć :D) w jaki sposób rozwiązałeś komunikację między apką z dialogiem a "główną".

Czy wywołujesz to z jakiegoś DLL'a, czy w inny sposób? I jak przekazujesz nazwę pliku do "aplikacji głównej" - bo zakładam, że po wybraniu przez użytkownika pliku do otwarcia, wrapper jedynie przekazuje jego nazwę/lokalizację, a nie wczytuje i nie przekazuje całej treści pliku.

cerrato napisał(a):

To jeszcze napisz proszę (i obiecuję - przestanę Cię męczyć :D) w jaki sposób rozwiązałeś komunikację między apką z dialogiem a "główną".

Czy wywołujesz to z jakiegoś DLL'a, czy w inny sposób?

DLL?
OpenDialog musi być uruchomione w osobnym procesie.

A więc jest sobie exe, którego zadaniem jest odpalenie OpenDialog z przekazanymi z hosta parametrami.
Owo exe odpala OpenDialog, a potem do hosta przekazuje listę plików, które zostały wybrane w OpenDialog.
Analogicznie dla SaveDialog.

Do tego w aplikacji Host istniej wrapper na cały ten bałagan, którego zadaniem jest używanie całego mechanizmu identycznie jak zwykłego Open/Save Dialog.
W zależności od globalnej flagi konfiguracyjnej systemu, wrapper używa zewnętrznej aplikacji lub standardowych dialogów.

I jak przekazujesz nazwę pliku do "aplikacji głównej" - bo zakładam, że po wybraniu przez użytkownika pliku do otwarcia, wrapper jedynie przekazuje jego nazwę/lokalizację, a nie wczytuje i nie przekazuje całej treści pliku.

No to by było raczej mało sensowne :D
Oczywiście do hosta przekazywane są tablice stringów zawierające pełne ścieżki do plików z wykorzystaniem WM_COPYDATA.

pozdrawiam @wloochacz'a

Aż dziwne, że to się musiało tak skończyć. Działa - jest OK, ale sam fakt pisania aplikacji osobnej do tego jest moim zdaniem dziwny, co oni tam mają na tych komputerach (czy tam serwerach plikowych) hmm...
Jak nie opendialog, to coś możę się sypać przy drukowaniu czy wysylaniu maila... oby nie trzeba było osobnych exeków robić innych :),

lampasss napisał(a):

pozdrawiam @wloochacz'a

Elo ;-)

Aż dziwne, że to się musiało tak skończyć. Działa - jest OK, ale sam fakt pisania aplikacji osobnej do tego jest moim zdaniem dziwny, co oni tam mają na tych komputerach (czy tam serwerach plikowych) hmm...

Nie wiem, nie znam się, zarobiony jestem.
Klient jest zachwycony, bo mu system normalnie działa.
Ja jestem zachwycony, bo nie męczę się z tym gównem już, a trwało to z pół roku...
Metoda czołgowa czasem jest pomocna (innymi słowy, daliśmy całusa brzytwie -> KISS + Ockham Razor :P) ;-)

Jak nie opendialog, to coś możę się sypać przy drukowaniu czy wysylaniu maila... oby nie trzeba było osobnych exeków robić innych :),

Na szczęście po eliminacji problemu z wysysaniem pamięci przez OpenDialog wszystko zaczęło działać jak trzeba.
A to wysysanie pamięci jest "fascynujące" - sam widziałem zużycie ok 10-12 MB co ok. 1,5s; aplikacja kończyła swój żywot po kilkunastu minutach działania, działając coraz bardziej mułowato...

Ciekawe, czy ma to jakiś związek z Delphi, czy jest to stricte jakiś zonk na poziomie systemu. Bo jeśli to jest błąd systemu/jakichś dodatków czy pluginów zainstalowanych w systemie (przykładowo, pisałeś coś wcześniej o generowaniu miniaturek plików, integracji PDF'a z explorerem itp.), to analogicznie powinno się dziać w innych aplikacjach odpalanych na tych komputerach, które korzystają z Windowsowych dialogów. Aczkolwiek pewnie zaraz napiszesz, że żaden inny program tak dużo i mocno nie jest wykorzystywany jak ten Twój, więc nie ma jak sprawdzić/porównać ;)

To chyba coś z komunikacją windows <> delphi i nie tylko, bo ja mam ten sam problem w Lazarusie, jeśli używam komponentu opendialog to często program mi się wykrzacza po którymś razie, używam Windowsa 10 ;-(

No to aż się prosi, żeby zrobić analogiczną apkę w C++ builderze i zobaczyć, jak się to zachowa. Obecnie to nie wygląda mi na problem stricte Delphiowy, ale raczej coś skopanego w dialogach Windows10. Tylko niemożliwe, żeby nikt inny na świecie tego nie zauważył ;)

Może chodzi o to, że w Lazarusie generuję aplikację 32bit a Windows 10 jest 64bit? Zresztą na Win10 czasami też wykrzaczają się aplikacje gdzie używam biblioteki Indy - szczególnie podczas odpalania z poziomu IDE.

Teoretycznie apki32-bit na maszynie 64 powinny chodzić bezstresowo, jeśli jesteś w stanie coś uruchomić na Windows 32-bit to tak samo powinno to chodzić na 64. Jeszcze jakby chodziło o jakieś sterowniki czy inne niskopoziomowe działania, to moglibyśmy szukać tutaj powodu, ale dialog openFile jest naprawdę jedną z podstawowych części składowych systemu. A co do Indy - zachęcam do spróbowania Synapse. @olesio może potwierdzić :)

Teoretycznie 32bit powinny działać bezstresowo na Win10/64:) Ale np. taki Total Commander 32bit czasem robi problemy, a jak wiadomo jest napisany w Delphi:)

Tak technicznie rzecz biorąc, to od. 2010 roku rozpoczęła się migracja na Lazarusa/FPC, więc podejrzewam, że obecnie całość jest pisana jedynie w tym środowisku:
https://www.ghisler.com/history.txt - "14.07.10 Added: Start work on conversion to Lazarus/Free Pascal in preparation for 64-bit version"

@olesio: Smiało, wbijaj na PW, jeśli będe w stanie to chętnie pomogę, ale niczego obiecać nie mogę :(

Zawsze możesz też pójść drogą tradycyjną i wrzucić pytanie na forum. Więcej osób, do tego wiele z nich mądrzejszych i bardziej doświadczonych, to większa szansa na uzyskanie sensownej odpowiedzi, niż bazowanie na jednym, do tego średnio rozgarniętym szczurku ;)

Skoro ten wątek stał się taką "odkrywką" do tematów problematycznych z Delphi/Lazarus/Indy itp, to może zapytam - jako że dotąd używałem Indiego by pobierać zawartość jakiejś strony i analizować ją - w Lazarusie, próbowałem też w Delphi standardowego komponentu webbrowser - ale wiadomo nie działa z każdymi stronami. Czy synapse działa jak Indy, czy może ma komponent jakiejś wirtualnej przeglądarki, żeby można było symulować zachowanie użytkownika na stronie www, javascript itp?