Bug 124776 - Running soffice.exe with a relative path from Command Prompt doesn't work
Summary: Running soffice.exe with a relative path from Command Prompt doesn't work
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.3.0
Keywords:
Depends on:
Blocks: Commandline
  Show dependency treegraph
 
Reported: 2019-04-16 17:34 UTC by Tor Lillqvist
Modified: 2019-04-17 04:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tor Lillqvist 2019-04-16 17:34:20 UTC
Description:
Try to run soffice.exe from Command Prompt (this is specific to Windows, obviously) using instdir\program\soffice.exe. The soffice.exe and soffice.bin processes run for a short while but exit then without doing anything.

Using an absolute pathname C:\where\ever\instdir\program\soffice.exe works.

Not sure how long this has been broken. But surely the intent is that using just instdir\program\soffice.exe should work? (Like it does when run from a Cygwin shell in mintty, and on Linux.)

The problem seems to be that getIniFileName_Impl() in sal/rtl/bootstrap.cxx does not return a file: URL but a relative pathname, huh.

And that is because osl_getExecutableFile() does not return an absolute filename, but what happens to be in argv[0]. Surely we should use some other way to find out the executable's pathname and not rely on what happens to be in argv[0] (Also, sal_detail_initialize() takes a plain char argv, not a wchar_t one, and thus is fairly broken already when LibreOffice is installed in a pathname that isn't expressible in the system codepage. We should use GetModulePathNameW(NULL,...).

Steps to Reproduce:
.

Actual Results:
.

Expected Results:
.


Reproducible: Always


User Profile Reset: No



Additional Info:
.
Comment 1 Tor Lillqvist 2019-04-16 17:35:45 UTC
I mean GetModuleFileNameW().
Comment 2 Tor Lillqvist 2019-04-16 17:42:27 UTC
(The same happens if you try to run instdir\program\soffice.com.)
Comment 3 Tor Lillqvist 2019-04-16 17:51:11 UTC
The code in osl_createCommandArgs_Impl() looks like it would be doing the right thing, even uses CommandLineToArgvW( GetCommandLineW(), &nArgs ), and has the comment /* Replace argv[0] with its absolute path */

But that gets used only if osl_setCommandArgs() is called with a zero argc. And we apparently call osl_setCommandArgs() with whatever happens to be in the args and argv passed to main(). I think we shold always ignore any argc and argv passed to main() and just let that osl_createCommandArgs_Impl() do its job.

Or is there some detail I am missing?
Comment 4 Oliver Brinzing 2019-04-16 18:32:32 UTC
confirming with Win10 x64 and LO 6.1.5.2
Comment 5 Mike Kaganski 2019-04-16 19:57:39 UTC
Likely regression after https://git.libreoffice.org/core/+/515d2579d305a6127c6c194319a58eac62437e33 - where possibly I actually enabled the calls to SetDllDirectoryW and SetSearchPathMode, which task is to exclude some paths (including current directory) from search; possibly they weren't called in old code for some reason (located in a different library in newer Windows?).
Comment 6 Mike Kaganski 2019-04-16 20:13:34 UTC
https://gerrit.libreoffice.org/70844
Comment 7 Aron Budea 2019-04-16 21:10:37 UTC
This worked fine including 4.3.0.4.
In 4.4.0.3 it started to crash.
Between LO 5.0.0.5 and 5.4.0.3 it gave an error when trying to access the central configuration.
In 6.0.0.3 it started to crash again.

The latest crash was introduced by the following commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=00657aef09d854c74fb426a935a3e8b1fc390bb0
author		Caolán McNamara <caolanm@redhat.com>	2017-06-11 20:56:30 +0100
committer	Caolán McNamara <caolanm@redhat.com>	2017-07-21 08:20:50 +0100

migrate to boost::gettext
Comment 8 Tor Lillqvist 2019-04-16 23:00:52 UTC
Oh, it crashes even? Is that in a non-developer build?
Comment 9 Aron Budea 2019-04-16 23:40:41 UTC
(In reply to Tor Lillqvist from comment #8)
> Oh, it crashes even? Is that in a non-developer build?
Both in local debug and official release builds.
Comment 10 Commit Notification 2019-04-17 04:03:00 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/c650217cc543080928a26de4bfc07ebb0be5c6ca%5E%21

tdf#124776: don't use SearchPathW to get full path of executable

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.