Bug 147572

Created attachment 178429 [details]
Backtrace of hanged process

I'm not sure if I created this backtrace correctly (as in instruction there is no case for hanged process).
I just attached to the changed process for a while and then break. After that analysis has been done.

Thanks for the backtrace. Unfortunately, it doesn't look useful. Could you please try to obtain a minidump - https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump

Do that nearly the same way as you did for WinDBG: let the process to hang a little, then run

> procdump.exe soffice.bin

(note that no additional command line options needed, like '-h' - since we don't know if the process is actually hung, or if it just waits indefinitely in the background).

The command should create a minidump file, and print its path. Please attach it here.

Thank you!

Also, you may check proxy and set to None, if that's in use. 
I set Needinfo because hardly will anyone come up with a solution, unless you find out why LO doesn't close.

I tried to create a minidump but without success.
I opened a LibreOffice then run "procdump64 soffice.bin -h" and then I closed a LO window but procdump64 still displaying only "Press Ctrl-C to end monitoring without terminating the process". So I pressed Ctrl-C but then I only saw a message "Dump count not reached" and nothing has been produced (I mean no debug logs or something).

Sorry, I'm not an expert in terms of debugging. Could you assist me and provide more information what I'm done wrong and what I should do?

I also tried change a proxy settings to None but without effect.

Btw. do I need specially compiled version of LO or can I use that one comes with MSI installer package?

(In reply to Michał Piotrowski from comment #4)
> I opened a LibreOffice then run "procdump64 soffice.bin -h"

Please look at what I wrote in comment #2:
> ... then run
> 
> > procdump.exe soffice.bin
> 
> (note that no additional command line options needed, like '-h' - since we
> don't know if the process is actually hung, or if it just waits indefinitely
> in the background).

Created attachment 178452 [details]
Minidump

(In reply to Mike Kaganski from comment #5)
> (In reply to Michał Piotrowski from comment #4)
> > I opened a LibreOffice then run "procdump64 soffice.bin -h"
> 
> Please look at what I wrote in comment #2:
> > ... then run
> > 
> > > procdump.exe soffice.bin
> > 
> > (note that no additional command line options needed, like '-h' - since we
> > don't know if the process is actually hung, or if it just waits indefinitely
> > in the background).

Very sorry, you indeed point me what I should do. My bad.

(In reply to Michał Piotrowski from comment #6)
> Minidump

Great! The problematic call stack is

> ntdll.dll!NtCreateFile()	Unknown
> KERNELBASE.dll!00007ff9f54831e2()	Unknown
> [Inline Frame] sal3.dll!create_dir_with_callback(_rtl_uString *) Line 556	C++
> sal3.dll!create_dir_recursively_(_rtl_uString * dir_path, void(*)(void *, _rtl_uString *) aDirectoryCreationCallbackFunc, void * pData) Line 598	C++
> sal3.dll!osl_createDirectoryPath(_rtl_uString * aDirectoryUrl, void(*)(void *, _rtl_uString *) aDirectoryCreationCallbackFunc, void * pData) Line 639	C++
> [Inline Frame] mergedlo.dll!osl::Directory::createPath(const rtl::OUString &) Line 1940	C++
> mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2032	C++
> mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2056	C++
> mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2056	C++
> mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2056	C++
> mergedlo.dll!comphelper::BackupFileHelper::tryPush() Line 1656	C++
> mergedlo.dll!desktop::Desktop::doShutdown() Line 1687	C++
> mergedlo.dll!desktop::Desktop::Main() Line 1611	C++
> mergedlo.dll!ImplSVMain() Line 199	C++
> [Inline Frame] mergedlo.dll!SVMain() Line 231	C++
> mergedlo.dll!soffice_main() Line 98	C++
> [Inline Frame] soffice.bin!sal_main() Line 49	C
> soffice.bin!main(int argc, char * * argv) Line 47	C
> [Inline Frame] soffice.bin!invoke_main() Line 78	C++
> soffice.bin!__scrt_common_main_seh() Line 288	C++
> kernel32.dll!BaseThreadInitThunk()	Unknown
> ntdll.dll!RtlUserThreadStart()	Unknown

It seems to hang at trying to backup the user configuration in Desktop::doShutdown [1]. The call stack ends inside NtCreateFile (itself inside CreateDirectoryW), which is very unusual to hang - but unfortunately, the minidump doesn't include the process memory, only stack memory, which doesn't allow to inspect which path it tries to create.

Creating a dump with full process memory (like 'procdump64 soffice.bin -ma' [2]) would produce way too large dump, and additionally could be unsafe (I have no idea what could it contain in addition to the information we need); so I'd suggest you to try another Sysinternals tool: Process Monitor [3] - to try to see which paths it accesses from the point where it gets closed, up to the hang point. Then seeing those paths could shed some light, and maybe allow you to see some permission issues?

[1] https://opengrok.libreoffice.org/xref/core/desktop/source/app/app.cxx?r=229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a#1686
[2] https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
[3] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Thanks for advice.

I used a ProcMon and I sow LO trying to save one file inside %appdata%/LibreOffice but ProcMon shows a NAME_COLLISION for that file what indicate a problems with offline files in Windows.
And indeed, space for offline files was full (but I'm not sure if it was a cause) so I increased a space for offline files and cleared a "cache" (or something like that for offline files).
After that LO can close correctly but another strange thing start happen: after opening and closing a few documents it starts to hangs on opening (also tried to access or write some files).
My temporal solution is to disable offline files at all and it solves this problems correctly but I must to investigate it later.

Btw. probably I can be not alone in that kind of problems, so maybe it's a good idea to set some kind of timeout (number of tries) for saving this user configuration in LO?

(In reply to Michał Piotrowski from comment #9)
> I increased a space for offline files and cleared a "cache" (or
> something like that for offline files).
> After that LO can close correctly

Great that you found it!

> but another strange thing start happen:
> after opening and closing a few documents it starts to hangs on opening
> (also tried to access or write some files).
> My temporal solution is to disable offline files at all and it solves this
> problems correctly but I must to investigate it later.

From my times of administrating a Windows-based domain on my ex-job, I remember struggling with RDP-related quotas, roaming profiles, and some applications that regularly made those blow (including AutoCAD and OOo/LO). I don't remember the RDP-related details (it was more than 7 years ago - time flies...), but I do remember excluding some program-specific %appdata% subfolders from roaming profile content in respective group policies (adding exclusion of paths). Yes, the configuration of that is not straightforward.

> Btw. probably I can be not alone in that kind of problems, so maybe it's a
> good idea to set some kind of timeout (number of tries) for saving this user
> configuration in LO?

No, not at this time, since it's still not affecting many, and at this point, it's better to create a FAQ at wiki ( https://wiki.documentfoundation.org/Faq/General ) - I ask you to do that when you have some time, to dump the information you gathered. At some point, the FAQ could enable to see the problem as a whole; but implementing a "timeout" means great additional complexity at the code that is really fragile and critical (shutdown, which may happen at logoff time, must be as fast as possible as documented by MS; and timing out means we need to create a dedicated thread for the writing, and synchronizing on it (blocking), with all respective overhead for everyone).

I close it NOTABUG (just because there's no suitable "COMBINATION_OF_PARTICULAR_SYSTEM_SETTINGS_AND_OUR_PROCESSING" resolution), since we have found the problem (a system configuration blocking the write on system level), and we don't have something to fix at our side for the time being. Thank you for filing the issue; and again - please do create a FAQ with your findings, which might benefit other admins.

Also: please feel free to put it back to UNCONFIRMED, if you feel it should not be closed; please provide explanation why you think so, if you do.

(In reply to Mike Kaganski from comment #10)
> From my times of administrating a Windows-based domain on my ex-job, I
> remember struggling with RDP-related quotas, roaming profiles, and some
> applications that regularly made those blow (including AutoCAD and OOo/LO).
> I don't remember the RDP-related details (it was more than 7 years ago -
> time flies...), but I do remember excluding some program-specific %appdata%
> subfolders from roaming profile content in respective group policies (adding
> exclusion of paths). Yes, the configuration of that is not straightforward.

This is not exactly my case, but that for advices. In my case I don't have any RDP and also %appdata% is redirected into server by GPO.

I also created a wiki page: https://wiki.documentfoundation.org/Faq/General/LibreOffice_hangs_its_process_on_window_close_and_I_can%27t_open_another_instance_(Windows)

Thanks for all help.
Best Regards,
Michał