I confirm your findings.
On master sources updated today, 
git grep -n 'PROT_ALL' * returns nothing

git grep -n 'PROT_WRITE' * gives:
bridges/source/cpp_uno/shared/vtablefactory.cxx:82:        nullptr, n, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1,
bridges/source/cpp_uno/shared/vtablefactory.cxx:87:    else if (mprotect (p, n, PROT_READ | PROT_WRITE | PROT_EXEC) == -1)
bridges/source/cpp_uno/shared/vtablefactory.cxx:275:        block.start = mmap(nullptr, block.size, PROT_READ | PROT_WRITE, MAP_SHARED, block.fd, 0);
external/hunspell/0001-Revert-Remove-autotools-autogenerated-files.patch:24139:+  data2 = (char *) mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
external/hunspell/0001-Revert-Remove-autotools-autogenerated-files.patch:24155:+  if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
sal/rtl/alloc_arena.cxx:1063:    addr = mmap (nullptr, static_cast<size_t>(size), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);

So, there's only the second line (already quoted by reporter), see https://opengrok.libreoffice.org/xref/core/bridges/source/cpp_uno/shared/vtablefactory.cxx#87

It's been like this since 2006, see https://cgit.freedesktop.org/libreoffice/core/commit/?id=dca1c17b960e40c824fd396242acbee1eb2e97f5

Stephan/Mike: noticing your last commit on this file, thought you might be interested in this one.

LO does some native code generation at runtime (for the bridge between C++ and binary UNO).  There is USE_DOUBLE_MMAP to not have to map those pages as rwx, but rather to split that into w and rx access.  This is enabled for LINUX and the various *BSD in bridges/inc/vtablefactory.hxx.

The relevant code is VtableFactory::createBlock in bridges/source/cpp_uno/shared/vtablefactory.cxx.  For performance reasons, it first tries to allocate rwx pages, via rtl_arena_alloc calling allocExec (at the top of that vtablefactory.cxx).  If that fails (because rwx is forbidden by the OS), VtableFactory::createBlock goes on to do the double mmap.

But this code should not be executed by the oosplash process.  (It will be executed e.g. by the soffice.bin process, though.)  You would need to debug oosplash further to find out why it fails with "permission denied" for you.

(Julien, not sure why you set this from UNCONFIRMED to NEW.  I don't think your argument for doing so is sound.)

Thank you for your very detailed feedback Stephan.
I had put it at NEW since the code showed indeed the use of write and exec flags.
Now if you say that's normal, no pb. I must recognize I'm not expert at all on this subject.
Let's revert back to UNCONFIRMED then.
Don't hesitate to update to a more appropriate status.

Can I / Should I open a new bug for oosplash / soffice? 

Or can we inform someone that maintans them, to see this bug? 

Many thanks!

(In reply to hessnovTHR44 from comment #4)
> Can I / Should I open a new bug for oosplash / soffice? 
> 
> Or can we inform someone that maintans them, to see this bug? 

I'm not sure what you mean with either of those two questions.

The essence of your problem description in this bug's comment 0 is something like, "on OpenBSD with W^X enforced, starting LO fails with 'Permission denied' in oosplash", while this bug's title looks like guesswork to me.  I think it's best if you make the title match the problem description.

And if you don't want to debug the problem yourself, lets hope that somebody who knows how to do so comes across this bug, or you can point people in some OpenBSD-specific channel at it.

Hi, OpenBSD ports dev here.

The reporter is confused about how the mechanism works on recent OpenBSD. W+X mappings are rejected unless an executable has OPENBSD_WXNEEDED in the ELF program header. Executables marked in this way will always get EPERM immediately at startup unless the filesystem holding them was mounted with the "wxallowed" flag.

I haven't investigated this (and to be honest don't have time to do so at present) but if LibreOffice itself is doing shadow mappings (USE_DOUBLE_MMAP), it's quite possible that the flag is set due to use of Java (the normal method of getting the flag set is by a linker flag, and in ports the standard method is to use a wrapper "ld" script to add the flag, so all executables from that port will be so marked).

In any event simply disabling wxallowed on the mount point is not giving any useful information, it is guaranteed that a program linked in this way will fail to start. A proper test would be to build without setting the linker flag and then see what (if anything) fails.

Thanks for your helpful hints that would lead to fixing this W^X related crash in LibreOffice. 

Thanks!

So, is the unconfirmed status still appropriate for this bug report ?

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #8)
> So, is the unconfirmed status still appropriate for this bug report ?

Somebody involved in the LO OpenBSD port would need to answer that.

(In reply to sthen from comment #6)
> A proper test would be to build without setting the linker
> flag and then see what (if anything) fails.

hessnovTHR44: can you try it?

"A proper test would be to build without setting the linker flag and then see what (if anything) fails."

Can someone please help me that what "linker flag" should I use when building/testing LibreOffice? 

If I would know it, then I can help!

Many thanks.

(In reply to hessnovTHR44 from comment #11)
> Can someone please help me that what "linker flag" should I use when
> building/testing LibreOffice? 
> 
> If I would know it, then I can help!


@Stephan Bergmann, do you know it ?

(In reply to Xisco Faulí from comment #12)
> @Stephan Bergmann, do you know it ?

no

(In reply to hessnovTHR44 from comment #11)
> "A proper test would be to build without setting the linker flag and then
> see what (if anything) fails."
> 
> Can someone please help me that what "linker flag" should I use when
> building/testing LibreOffice? 

sthen: can you elaborate on this?

You can build from ports with the USE_WXNEEDED=Yes removed/commented-out. To save time with dependencies you can do "make prepare FETCH_PACKAGES=Yes" and to build on multiple cores "make MAKE_JOBS=4" or similar, but it will still take a LONG time to build.

(In reply to sthen from comment #15)
> You can build from ports with the USE_WXNEEDED=Yes removed/commented-out. To
> save time with dependencies you can do "make prepare FETCH_PACKAGES=Yes" and
> to build on multiple cores "make MAKE_JOBS=4" or similar, but it will still
> take a LONG time to build.

@hessnovTHR44, any update here ?

Dear hessnovTHR44,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp