Age | Commit message (Collapse) | Author |
|
Change-Id: Ia367fcd3b204b9dd96f5fa6d3a52d0895bd9c0c9
|
|
Change-Id: I08f17dd9cc092206083ff41bbbc178e0322e86d0
|
|
Change-Id: Ia8f2c9f1c1c284708a2cbde379197ec6ba58742f
|
|
Change-Id: I5f2393b13729ab43ad2cfd4a3f960a507e3e608b
|
|
Change-Id: Icbab4d030877f978babfc51f984fb4793b60f681
|
|
Change-Id: I132d22e2af3cf673c17d8964f690d48990834884
|
|
found with some minor modifications to find/find-unused-defines.sh
Change-Id: I18cc479adedc7a0dada68a4aeef08300e62631dd
Reviewed-on: https://gerrit.libreoffice.org/14194
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Iaefde6a2fbe1b37f31435217c9f57d611d255b11
|
|
Change-Id: Ib8575109cfe0339f2d8b56741d3ad2a538ecf164
|
|
Change-Id: Ic224abf67acb212ee20ccf9eb81b5ed5edf851b9
|
|
...when write+exec mmap fails (due to SELinux deny_execmem). This avoids the
tmp file creation in environments that don't need it and which in turn have
problems of their own with that tmp file business.
An alternative would be to first check whether SELinux deny_execmem is enforced
and only then try double mmap first. An advantage could be that it might avoid
false SELinux alerts in that case. The disadvantage would be the overhead of
introducing a conditional dependency on libselinux here. And given that for one
deny_execmem typically appears to be off by default (as at least both
contemporary GNOME desktop and OpenJDK malfunction when it is enabled), and for
another I guess deny_execmem could still change its value between the time of
checking for it and the time of requesting a write+exec mmap, that just does not
seem worth it.
Change-Id: I3560803139b630557b6219d3db52945c7e0cdcd2
|
|
Change-Id: Iffc8cbf108310099318e37378c4b3033ea087cee
|
|
Change-Id: I7c41b90c9af045fd452ee62ed0c5d9b261236855
|
|
This reverts commit 3976739f2378391fa09379c48844daf0e2790f5b,
the problem mentioned there was caused by a different commit, and
has meanwhile been fixed.
|
|
cf. 9a745cbf549aa391be2b67f41c83056bd44db97a "Introdude SAL_JNI_EXPORT and use
that instead of JNIEXPORT"
Change-Id: I81dcc8dfcb878d3e935d807f491b99927637c23c
|
|
as an experiment to see if that's somehow the cause of
NEXT An uncaught exception of type com.sun.star.sdbc.SQLException
NEXT - General error: java.lang.UnsatisfiedLinkError: com.sun.star.sdbcx.comp.hsqldb.StorageFileAccess.isStreamElement(Ljava/lang/String;Ljava/lang/String;)Z
NEXT ##Failure Location unknown## : Error
Test name: HSQLDBTest::testEmptyDBConnection
NEXT An uncaught exception of type com.sun.star.sdbc.SQLException
NEXT - General error: java.lang.UnsatisfiedLinkError: com.sun.star.sdbcx.comp.hsqldb.StorageFileAccess.isStreamElement(Ljava/lang/String;Ljava/lang/String;)Z
under clang
This reverts commit ce7f442bd0b600c0acc74d4757e894a2ba382c53.
Change-Id: Ieed0be5721953b9644e4be411173e0ea73f33ed8
|
|
Using std::unordered_map causes a complex multi-line error message, call to
implicitly-deleted copy constructor of 'jni_uno::JNI_type_info_holder' etc.
Revert ce7f442bd0b600c0acc74d4757e894a2ba382c53 for one source file.
Change-Id: I24453498d3fcaadf900f2bb56a2812f8bce55dd4
|
|
Change-Id: I3a16703727f1a421e0ed18079e14219a4feeb8c8
|
|
found by CodePro
Change-Id: If1b75e43f81d70984422e437147048a491395b66
|
|
found by looking for unused parameters (in Eclipse)
Change-Id: I03cf9bc8312e59747b2d0ac153ee2fc8d76be893
|
|
Change-Id: I5d458f43616edc395faa8c27edaddc7d515166db
|
|
I had introduced it with d83de4b1a93ba7ed7bc3243073be3de96a44bfa9 in
2012, when the C++/UNO bridge for 64-bit OS X was created mostly as a
copy of the Linux one.
Stephan says that the only need for USE_DOUBLE_MMAP should be on
SELinux anyway, so most likely also its use for the various BSDs and
Android are copypasta or cargo cult.
Change-Id: I1c16e830e5e8269b78b14837a9127a98612a6e54
|
|
Rewrite of 32-Bit-Code to work under 64 Bit:
To use the 32 Bit offset values in the ExceptionType we have to
allocate a single allocation block and use it for all code and data.
All offsets inside this area are guaranteed to be in 32 bit address
range. So we have to calc total memory allocation size for D-tor,
C-Tors, ExceptionType and type_info. ExceptionType is allocated via
placement new operator to locate everything inside our mem block.
There is one caveat: Struct type_info is kept in a map and was
referenced from class ExceptionType. Therefore type_info now is also
member of ExceptionType and can be referenced via 32 bit offset.
Change-Id: I6b524e36975a66fb64ca0cfb014c207053acec90
Reviewed-on: https://gerrit.libreoffice.org/13653
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I7866959b9ea36c81003259cd387a001e9f34f26a
|
|
Change-Id: I72e0df381bd9525ea4fff1f4bbd57ffe84ce241f
|
|
Change-Id: I95ec7503ab7cf0309427118cc5af95eba4f5785b
|
|
Change-Id: I5d6071096307adbe7df0178000346cf915afa3e7
Reviewed-on: https://gerrit.libreoffice.org/13477
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ic8fea32a163ca5e85ac3e2a34d04e4fa1a1943f9
|
|
...make sure the class is actually found, etc.
Change-Id: I5459d531be39b07594a975ae708a7611d1667a2f
|
|
...to have it available during JNI-UNO's uno_initEnvironment (see next)
Change-Id: I7a2f27b512fc74f418b4648d92dafbf0304eaa96
|
|
Change-Id: Ife9a98cfe2166ccc7aac3904c7be4ea71443d857
|
|
Change-Id: I8e6fb1fc0acff781dd6e6b62018c7ccd5d0e2307
|
|
Change-Id: I97879d250ed0ed20d5e129ff3af6dbc2f5759078
|
|
Change-Id: I3bfaeab9dd9f2d8cd603c655ec3aa7c4f508c673
|
|
This addresses some cppcheck warnings.
Change-Id: I1122494e295af756ef3cc32717fe204505aeb9e3
Reviewed-on: https://gerrit.libreoffice.org/13335
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
found by PMD
Change-Id: Id6737916b68ccbdbdeec5d314747a38410923ac6
Reviewed-on: https://gerrit.libreoffice.org/13409
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
since we introduced the new constructors that pass the cause all the
way up to java.lang.Throwable.
Also simplify some exeception printing sites, because Throwable
will correctly print out child exceptions for us.
Change-Id: Ibbecce3c6f971fbc80d6de2052ab4f33a4503c0a
|
|
Change-Id: Idc87ab05f817a21e491537a1fa4c014c5a313bf6
|
|
Change-Id: Id949718baf77bb7e2d276d3db08f68149c114796
Reviewed-on: https://gerrit.libreoffice.org/13364
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
...but the code does not yet work: Care must be taken to allocate the various
data structures close enough together so that the offset calculations at the
four places now marked with
assert(...); //TODO
actually succeed.
Change-Id: I1fedf7d2d3cdde5035842b4ad5eca9ad9ccf2d44
|
|
Change-Id: I9fbe8d7eba181cbfcab704761e6feebd78120644
|
|
AsynchronousFinalizer was originally added as
870a4401c05beec3d31c1f6055a64591edd0a9d9 "INTEGRATION: CWS mtg1: #i57753# Avoid
long-running finalize methods" referring to
<https://issues.apache.org/ooo/show_bug.cgi?id=57753> " Fix JNI-UNO bridge so
that the JVM doesn't run out of memory when a destructor locks the SolarMutex."
It is unclear to me how relevant "If JVMs are getting more mature and should no
longer have problems with long-running finalize methods, this class could be
removed again" really is in practice. After all, advice on hotspot-gc-devel is
to avoid finalize() if possible
(<http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-June/010215.html>
"Re: History of finalizer execution and gc progress?"). So stick with this
approach of home-grown draining for now (where a home-grown approach using
PhantomReferencens would need a dedicated draining thread, too, so would not
have much benefit over the existing code in practice).
Timely termination of AsynchronousFinalizer threads is achieved by using a
dedicated thread per bridge and joining it in the remote bridge's dispose()
resp. the JNI environment's new java_env_dispose.
Change-Id: Idcef2dbf361a1de22f60db73828f59e85711aea7
|
|
Change-Id: I4262fb56d681c70a089638b876dc07b1f472f583
|
|
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
|
|
Change-Id: Ic47f69b01cf17a55901e9e3541419d9f477d9585
Reviewed-on: https://gerrit.libreoffice.org/13210
Tested-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I34b308db422d861098fdf93cff8fea63128ba47a
Reviewed-on: https://gerrit.libreoffice.org/13211
Tested-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I86864f832c0377d307cfa0b2c137f452e43797eb
|
|
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
|
|
Change-Id: I9cd345de6895b38fc766b0fe16e218a146bfb7b9
|
|
Change-Id: Ie422682f38752a5f92336106d40c79d2bf9006c7
|