Bug 33737 - Платформа i586 LibreOffice падает без диагностики
Summary: Платформа i586 LibreOffice падает без диагностики
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: LibreOffice-extensions (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Fr. Br. George
QA Contact: qa-sisyphus
URL:
Keywords:
: 33716 35041 (view as bug list)
Depends on: 33741
Blocks:
  Show dependency tree
 
Reported: 2017-08-06 09:19 MSK by nbr
Modified: 2022-02-16 01:06 MSK (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nbr 2017-08-06 09:19:28 MSK
При установке пакета LibreOffice-extensions-java LibreOffice на i586 
при запуске libreoffice он падает без сообщений.
Кроме этого, LibreOffice-extensions-java не имеет зависимостей на java.
Экспериментальным путем выявлено, что причиной этого является любое из 
extensions:
SmART,Validator, WatchWindow.
При их удалении libreoffice работает нормально.
Comment 1 nbr 2017-08-06 12:37:14 MSK
Дополнительно.
Если поставить java-1.5.0-sun и выбрать ее для libreoffice,
то все extensions не роняют libreoffice.
Все остальные java не работают.
Comment 2 nbr 2017-08-06 15:45:14 MSK
https://stackoverflow.com/questions/14150746/calling-jni-createjavavm-crashes-the-program?rq=1
вот как именно java валится.

Program received signal SIGSEGV, Segmentation fault.
_expand_stack_to (
    bottom=0xbfe03fff <error: Cannot access memory at address 0xbfe03fff>, 
    bottom@entry=0xbfe03000 <error: Cannot access memory at address 0xbfe03000>)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:665
665         p[0] = '\0';
(gdb) 
(gdb) bt
#0  _expand_stack_to (
    bottom=0xbfe03fff <error: Cannot access memory at address 0xbfe03fff>, 
    bottom@entry=0xbfe03000 <error: Cannot access memory at address 0xbfe03000>)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:665
#1  0xacd37ff0 in os::Linux::manually_expand_stack (t=0x8cba800, 
    addr=0xbfe03000 <error: Cannot access memory at address 0xbfe03000>)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:678
#2  0xacd41bc7 in create_attached_thread (thread=0x8cba800)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:957
#3  os::create_main_thread (thread=0x8cba800)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:907
#4  0xace7b657 in set_as_starting_thread (this=0x8cba800)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/share/vm/runtime/thread.cpp:988
#5  Threads::create_vm (args=0xbfffd9e8, canTryAgain=0xbfffd88b)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3405
#6  0xacb49d4d in JNI_CreateJavaVM (vm=0xbfffd950, penv=0xbfffdc44, 
    args=0xbfffd9e8)
    at /usr/src/debug/java-1.8.0-openjdk-1.8.0.71-1.b15.i586/openjdk/hotspot/src/share/vm/prims/jni.cpp:5196
#7  0xb525c5f0 in ?? () from /usr/lib/LibreOffice/program/libjvmfwklo.so
---Type <return> to continue, or q <return> to quit--- 
#8  0xb5268833 in jfw_startVM(JavaInfo const*, JavaVMOption*, long, JavaVM_**, JNIEnv_**) () from /usr/lib/LibreOffice/program/libjvmfwklo.so
#9  0xad550bb3 in ?? () from /usr/lib/LibreOffice/program/libjavavmlo.so
#10 0xad5623ca in ?? () from /usr/lib/LibreOffice/program/libjavaloaderlo.so
#11 0xad5631cd in ?? () from /usr/lib/LibreOffice/program/libjavaloaderlo.so
#12 0xb784ff77 in ?? ()
   from /usr/lib/LibreOffice/program/libuno_cppuhelpergcc3.so.3
#13 0xb78504e7 in ?? ()
   from /usr/lib/LibreOffice/program/libuno_cppuhelpergcc3.so.3
#14 0xb7850567 in ?? ()
   from /usr/lib/LibreOffice/program/libuno_cppuhelpergcc3.so.3
#15 0xb784cfc8 in ?? ()
   from /usr/lib/LibreOffice/program/libuno_cppuhelpergcc3.so.3
#16 0xafed5ff3 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#17 0xafed723b in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#18 0xafed7496 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#19 0xadf166a1 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libswlo.so
#20 0xafed8bab in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#21 0xaff37264 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#22 0xb69db0c5 in svt::ToolboxController::bindListener() ()
   from /usr/lib/LibreOffice/program/libsvtlo.so
---Type <return> to continue, or q <return> to quit---
#23 0xb69db2ab in svt::ToolboxController::update() ()
   from /usr/lib/LibreOffice/program/libsvtlo.so
#24 0xaff6eea2 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#25 0xaff7085d in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#26 0xaffacd1d in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#27 0xaffb42af in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#28 0xaff0cc44 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#29 0xaff136d4 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#30 0xafefd6a8 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#31 0xaff025b5 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#32 0xaff35695 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#33 0xaff3ab1c in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#34 0xb73c59e8 in ?? () from /usr/lib/LibreOffice/program/libsfxlo.so
#35 0xaff1c232 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#36 0xaff1c5ea in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
---Type <return> to continue, or q <return> to quit---
#37 0xafedb502 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#38 0xafedb8b4 in ?? ()
   from /usr/lib/LibreOffice/program/../program/libfwklo.so
#39 0xb7295e87 in ?? () from /usr/lib/LibreOffice/program/libsfxlo.so
#40 0xb60e1b12 in ?? () from /usr/lib/LibreOffice/program/libvcllo.so
#41 0xb62cb1f8 in ?? () from /usr/lib/LibreOffice/program/libvcllo.so
#42 0xb62d016f in SalGenericDisplay::DispatchInternalEvent() ()
   from /usr/lib/LibreOffice/program/libvcllo.so
#43 0xb1a625cf in SalX11Display::Yield() ()
   from /usr/lib/LibreOffice/program/libvclplug_genlo.so
#44 0xb1a62789 in ?? ()
   from /usr/lib/LibreOffice/program/libvclplug_genlo.so
#45 0xb1a623bf in ?? ()
   from /usr/lib/LibreOffice/program/libvclplug_genlo.so
#46 0xb1a61e2f in SalXLib::Yield(bool, bool) ()
   from /usr/lib/LibreOffice/program/libvclplug_genlo.so
#47 0xb1a68720 in X11SalInstance::DoYield(bool, bool, unsigned long) ()
   from /usr/lib/LibreOffice/program/libvclplug_genlo.so
#48 0xb625c670 in ?? () from /usr/lib/LibreOffice/program/libvcllo.so
#49 0xb6259907 in Application::Yield() ()
   from /usr/lib/LibreOffice/program/libvcllo.so
#50 0xb625ab0f in Application::Execute() ()
   from /usr/lib/LibreOffice/program/libvcllo.so
#51 0xb7f2bf0c in ?? () from /usr/lib/LibreOffice/program/libsofficeapp.so
#52 0xb625e78e in ?? () from /usr/lib/LibreOffice/program/libvcllo.so
#53 0xb625e899 in SVMain() () from /usr/lib/LibreOffice/program/libvcllo.so
---Type <return> to continue, or q <return> to quit---
#54 0xb7f46408 in soffice_main ()
   from /usr/lib/LibreOffice/program/libsofficeapp.so
#55 0x0804858c in ?? ()
#56 0xb7d935a7 in __libc_start_main (main=0x8048560, argc=1, 
    argv=0xbffff584, init=0x80486a0, fini=0x8048700, 
    rtld_fini=0xb7feb330 <_dl_fini>, stack_end=0xbffff57c)
    at ../csu/libc-start.c:289
#57 0x080485c2 in ?? ()
(gdb) 
(gdb)
Comment 3 Dmitry V. Levin 2017-08-06 15:55:55 MSK
https://issues.apache.org/jira/browse/DAEMON-363
Comment 4 nbr 2017-08-06 16:00:05 MSK
(In reply to comment #3)
> https://issues.apache.org/jira/browse/DAEMON-363
Похоже, нет
тут не в guard упирается а в неработающую alloca:
Грохается вот тут, на строчке с присвоением нуля:

static void _expand_stack_to(address bottom) {
  address sp;
  size_t size;
  volatile char *p;

  // Adjust bottom to point to the largest address within the same page, it
  // gives us a one-page buffer if alloca() allocates slightly more memory.
  bottom = (address)align_size_down((uintptr_t)bottom, os::Linux::page_size());
  bottom += os::Linux::page_size() - 1;

  // sp might be slightly above current stack pointer; if that's the case, we
  // will alloca() a little more space than necessary, which is OK. Don't use
  // os::current_stack_pointer(), as its result can be slightly below current
  // stack pointer, causing us to not alloca enough to reach "bottom".
  sp = (address)&sp;

  if (sp > bottom) {
    size = sp - bottom;
    p = (volatile char *)alloca(size);
    assert(p != NULL && p <= (volatile char *)bottom, "alloca problem?");
    p[0] = '\0';
  }
}
Comment 5 nbr 2017-08-07 10:58:00 MSK
(In reply to comment #4)
> (In reply to comment #3)
> > https://issues.apache.org/jira/browse/DAEMON-363
> Похоже, нет
> тут не в guard упирается а в неработающую alloca:
> Грохается вот тут, на строчке с присвоением нуля:
> 
> 
>   if (sp > bottom) {
>     size = sp - bottom;
>     p = (volatile char *)alloca(size);
>     assert(p != NULL && p <= (volatile char *)bottom, "alloca problem?");
>     p[0] = '\0';
>   }
> }
Попробовал собрать с указанием, что extern alloca
(чтобы ее не пыталось инлайнить) - падения прекратились.
Comment 6 Dmitry V. Levin 2017-08-07 13:29:33 MSK
(In reply to comment #5)
> Попробовал собрать с указанием, что extern alloca

Это как? alloca это вообще не функция, а чёрная магия от компилятора.
Comment 7 nbr 2017-08-07 13:32:53 MSK
Обычно магия, но в принципе это функция.
man 3 alloca
 The  alloca()  function  allocates  size bytes of space in the stack frame of the caller.
       This temporary space is automatically  freed  when  the  function  that  called  alloca()
       returns to its caller.
Normally, gcc(1) translates calls to alloca() with inlined code.
но если ей сказать extern, она, насколько я понял, так делать не будет и будет именно вызывать alloca. Что и надо.
Comment 8 Fr. Br. George 2017-08-10 15:58:33 MSK
*** Bug 33716 has been marked as a duplicate of this bug. ***
Comment 9 Dmitry V. Levin 2017-08-10 16:28:31 MSK
(In reply to comment #7)
> Обычно магия, но в принципе это функция.

alloca это в принципе не функция.

В gnulib, конечно, есть реализация alloca для обездоленных с помощью malloc и garbage collector'а, но это уже совсем другая история.

> man 3 alloca
>  The  alloca()  function

Это неправда, alloca это __builtin_alloca.
"calls to 'alloca' may become single instructions which adjust the stack directly".  На самом деле не "may", а "will".

В общем, alloca -- это ложный след.
Comment 10 Fr. Br. George 2019-12-11 17:28:58 MSK
*** Bug 35041 has been marked as a duplicate of this bug. ***