Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 03 May, 2019 8 kayıt (commit)
  3. 02 May, 2019 1 kayıt (commit)
  5. 01 May, 2019 1 kayıt (commit)
  7. 30 Nis, 2019 7 kayıt (commit)
  9. 29 Nis, 2019 9 kayıt (commit)
  11. 28 Nis, 2019 4 kayıt (commit)
  13. 27 Nis, 2019 6 kayıt (commit)
  15. 26 Nis, 2019 4 kayıt (commit)
    • Stephan Bergmann's avatar
      tdf#122244 Put InfoPlist.strings files at correct places on macOS · 5c637684
      Stephan Bergmann yazdı 
      Don't know how this got broken, presumably somewhere along the line from
01344a8c "convert sysui to gbuild and add to
tail_build" through 4430ace3 "tdf#90753:
AutoInstall more packages" to the current state, where a spurious bin directory
containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is
placed in instdir/ and in the root window of .dmg files.

As discussed in the <https://developer.apple.com/library/archive/documentation/
General/Reference/InfoPlistKeyReference/Articles/
AboutInformationPropertyListFiles.html> "Localizing Property List Values"
section, those InfoPlist.strings files shall apparently be placed into the
Contents/Resources/*.lproj/ directories.  (And the zip wrappers were presumably
needed in the past to transport their payload to the proper places in the
installation set, and are now obsolete.)

The list of Apple language IDs for the *.lproj directories was already
duplicated in Makefile.in (test-install target) and
solenv/bin/modules/installer/simplepackage.pm (sub create_package).  Ultimately
those lists should all be consolidated.  Also, mapping from our language IDs
(see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g.,
from zh-CN to zh_CN), and it is not clear to me why the old code explicilty
added en-US to the gb_WITH_LANG list of languages for which to generate
InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the
non-localized strings stored in Info.plist itself).  But as mentiond, those
InfoPlist.strings files are all empty anyway (which may be due to another bug?),
so it shouldn't matter much---at least for now---what
Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an
installation set.

Change-Id: Iaadce2375ed319928891bace44f9866622ec3084
Reviewed-on: https://gerrit.libreoffice.org/71277
Tested-by: Jenkins
Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 7a08bfea)
Reviewed-on: https://gerrit.libreoffice.org/71297Reviewed-by: 's avatarCaolán McNamara <caolanm@redhat.com>
Tested-by: 's avatarCaolán McNamara <caolanm@redhat.com>
      5c637684
    • Noel Grandin's avatar
      tdf67629 FILEOPEN Particular .xlsx hangs Spreadsheet · 9dac5b11
      Noel Grandin yazdı 
      Seems like this is a somewhat pathological document, has lots of
duplicated ranges. Checking for duplicates makes it load in <10s on my
machine

Change-Id: I25da24e0f8b1d4ad99d00474be168c75586ea579
Reviewed-on: https://gerrit.libreoffice.org/71251
Tested-by: Jenkins
Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit e1ebb5cb)
Reviewed-on: https://gerrit.libreoffice.org/71379
      9dac5b11
    • Caolán McNamara's avatar
      Related: tdf#124919 assert on ctrl+[ on four selected cells in table · 41fa694e
      Caolán McNamara yazdı 
      since...

commit a91992e7
Date:   Fri Nov 16 16:26:38 2018 +0100

    sw: SwTextNode::GetAttr() inconsistency

Change-Id: I45a89a83332f964fc813f8083e09d816965d2658
Reviewed-on: https://gerrit.libreoffice.org/71313
Tested-by: Jenkins
Reviewed-by: 's avatarCaolán McNamara <caolanm@redhat.com>
Tested-by: 's avatarCaolán McNamara <caolanm@redhat.com>
(cherry picked from commit cc2c0439)
Reviewed-on: https://gerrit.libreoffice.org/71350Reviewed-by: 's avatarMichael Stahl <Michael.Stahl@cib.de>
      41fa694e
    • Stephan Bergmann's avatar
      Avoid calling java.lang.Class.newInstance() · bfdae941
      Stephan Bergmann yazdı 
      For one, it is deprecated since Java 9, and for another it causes a
NullPointerException when called from the JNI Invocation API (i.e., without a
Java caller frame) at least with some Java 12.

(Found when doing a test build with Java 12 and JAVA_SOURCE/TARGET_VER
explicitly configured as 7 with d365f363 "Allow
to pass JAVA_SOURCE/TARGET_VER into configure".)

I have entered information about the NullPointerException at
<https://bugreport.java.com/bugreport/start_form.do>, but haven't heard back
yet, so duplicate that information here:

Issue Type:
> Bug

Component:
> Core Libraries

Operating System:
> Linux 64-bit

Java Release:
> 12

Synopsis:
> Calling java.lang.Class.newInstance from JNI Invocation API causes NullPointerEx

Description:
> I can reproduce this with the OpenJDK 12 RPMs on Fedora 30, but from looking at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/java/lang/Class.java> it looks plausible that it is a common issue that Reflection.getCallerClass() returns null when java.lang.Class.newInstance is called from the JNI Invocation API, and that null is propagated to jdk.internal.reflect.Reflection.verifyMemberAccess as parameter currentClass, which dereferences it at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/jdk/internal/reflect/Reflection.java#l130>.
> This is known to have been working with older OpenJDK (at least 1.8).

Steps to Reproduce:
> Compile the provided test.cc with `g++ -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include/linux /usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server/libjvm.so test.cc` and run it with `LD_LIBRARY_PATH=/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server ./a.out`.

Expected Result:
> exit 0

Actual Result:
> Exception in thread "main" java.lang.NullPointerException
> 	at java.base/jdk.internal.reflect.Reflection.verifyMemberAccess(Reflection.java:130)
> 	at java.base/java.lang.reflect.AccessibleObject.slowVerifyAccess(AccessibleObject.java:673)
> 	at java.base/java.lang.reflect.AccessibleObject.verifyAccess(AccessibleObject.java:666)
> 	at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:638)
> 	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:490)
> 	at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:166)
> 	at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:404)
> 	at java.base/java.lang.Class.newInstance(Class.java:590)
> Aborted

Source code for an executable test case:
> #include <cstdlib>
>
> #include "jni.h"
>
> void handleError(JNIEnv * env) {
>     if (env->ExceptionCheck()) {
>         env->ExceptionDescribe();
>         std::abort();
>     }
> }
>
> int main() {
>     JavaVM * vm;
>     JNIEnv * env;
>     JavaVMInitArgs args{JNI_VERSION_1_2, 0, nullptr, true};
>     if (JNI_CreateJavaVM(&vm, reinterpret_cast<void **>(&env), &args) != JNI_OK) {
>         std::abort();
>     }
>     auto const c1 = env->FindClass("java/lang/Class");
>     handleError(env);
>     auto const id = env->GetMethodID(c1, "newInstance", "()Ljava/lang/Object;");
>     handleError(env);
>     auto const c2 = env->FindClass("java/lang/Object");
>     handleError(env);
>     env->CallObjectMethod(c2, id);
>     handleError(env);
> }

Workaround:
> Call via JNI the suggested replacement of clazz.getDeclaredConstructor().newInstance() instead of the deprecated java.lang.Class.newInstance().

Change-Id: I85ff7102a18b98561f188e609873753546bc050d
Reviewed-on: https://gerrit.libreoffice.org/71240
Tested-by: Jenkins
Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 27c6d1db)
Reviewed-on: https://gerrit.libreoffice.org/71347Reviewed-by: 's avatarMichael Stahl <Michael.Stahl@cib.de>
      bfdae941