[opensuse] 15.2 and libreoffice
I have 2 machines doing this. I cant open .xls files. These 2 machines were updated from 15.1 via "zypper dup". The 15.1 systems worked. Maybe this strace will shed some light? markh@harley:~> strace ooffice Weekly\ Expense\ Report-Form\ ER-000-rev9.xls execve("/usr/bin/ooffice", ["ooffice", "Weekly Expense Report-Form ER-00"...], 0x7ffc9ba127b8 /* 120 vars */) = 0 brk(NULL) = 0x55e5d7391000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/x86_64/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls/x86_64/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/x86_64/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/x86_64/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=222001, ...}) = 0 mmap(NULL, 222001, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f868180d000 close(3) = 0 openat(AT_FDCWD, "/lib64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \213\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=317432, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f868180b000 mmap(NULL, 2417928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f86813d5000 mprotect(0x7f868141b000, 2093056, PROT_NONE) = 0 mmap(0x7f868161a000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x45000) = 0x7f868161a000 mmap(0x7f8681622000, 5384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8681622000 close(3) = 0 openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\20\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=18392, ...}) = 0 mmap(NULL, 2109584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f86811d1000 mprotect(0x7f86811d4000, 2093056, PROT_NONE) = 0 mmap(0x7f86813d3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f86813d3000 close(3) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`D\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=2038480, ...}) = 0 mmap(NULL, 3909496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8680e16000 mprotect(0x7f8680fc7000, 2097152, PROT_NONE) = 0 mmap(0x7f86811c7000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b1000) = 0x7f86811c7000 mmap(0x7f86811cd000, 14200, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f86811cd000 close(3) = 0 openat(AT_FDCWD, "/lib64/libtinfo.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\225\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=189296, ...}) = 0 mmap(NULL, 2285344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8680be8000 mprotect(0x7f8680c0e000, 2093056, PROT_NONE) = 0 mmap(0x7f8680e0d000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f8680e0d000 close(3) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8681809000 arch_prctl(ARCH_SET_FS, 0x7f8681809b80) = 0 mprotect(0x7f86811c7000, 12288, PROT_READ) = 0 mprotect(0x7f8680e0d000, 4096, PROT_READ) = 0 mprotect(0x7f86813d3000, 4096, PROT_READ) = 0 mprotect(0x7f868161a000, 8192, PROT_READ) = 0 mprotect(0x55e5d6200000, 8192, PROT_READ) = 0 mprotect(0x7f8681849000, 4096, PROT_READ) = 0 munmap(0x7f868180d000, 222001) = 0 openat(AT_FDCWD, "/dev/tty", O_RDWR|O_NONBLOCK) = 3 close(3) = 0 stat("/usr/lib/locale/locale-archive", 0x7ffe761f5500) = -1 ENOENT (No such file or directory) brk(NULL) = 0x55e5d7391000 brk(0x55e5d73b2000) = 0x55e5d73b2000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2939, ...}) = 0 read(3, "# Locale name alias data base.\n#"..., 4096) = 2939 read(3, "", 4096) = 0 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=368, ...}) = 0 mmap(NULL, 368, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681843000 close(3) = 0 open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26244, ...}) = 0 mmap(NULL, 26244, PROT_READ, MAP_SHARED, 3, 0) = 0x7f868183c000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0 mmap(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f868183b000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0 mmap(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f868183a000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=167, ...}) = 0 mmap(NULL, 167, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681839000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_NAME", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=77, ...}) = 0 mmap(NULL, 77, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681838000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_PAPER", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_PAPER", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=34, ...}) = 0 mmap(NULL, 34, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681837000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 close(3) = 0 open("/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0 mmap(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681836000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=286, ...}) = 0 mmap(NULL, 286, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681835000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1244054, ...}) = 0 mmap(NULL, 1244054, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f86816d9000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2454, ...}) = 0 mmap(NULL, 2454, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681834000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0 mmap(NULL, 54, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681833000 close(3) = 0 open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=330604, ...}) = 0 mmap(NULL, 330604, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681688000 close(3) = 0 getuid() = 5076 getgid() = 100 geteuid() = 5076 getegid() = 100 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor) sysinfo({uptime=384, loads=[5280, 18752, 11328], totalram=16805945344, freeram=13552128000, sharedram=96616448, bufferram=108920832, totalswap=17179865088, freeswap=17179865088, procs=1142, totalhigh=0, freehigh=0, mem_unit=1}) = 0 rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, 8) = 0 rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 rt_sigaction(SIGTSTP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGTSTP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 rt_sigaction(SIGTTIN, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGTTIN, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 rt_sigaction(SIGTTOU, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGTTOU, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_NODEFER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGQUIT, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 uname({sysname="Linux", nodename="harley", ...}) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 stat("/home/markh", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 stat(".", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/home/markh", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 getpid() = 6852 getppid() = 6849 getpid() = 6852 getpgrp() = 6849 ioctl(2, TIOCGPGRP, [6849]) = 0 rt_sigaction(SIGCHLD, {sa_handler=0x55e5d5fcca40, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, 8) = 0 prlimit64(0, RLIMIT_NPROC, NULL, {rlim_cur=63782, rlim_max=63782}) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 openat(AT_FDCWD, "/usr/bin/ooffice", O_RDONLY) = 3 stat("/usr/bin/ooffice", {st_mode=S_IFREG|0755, st_size=55, ...}) = 0 ioctl(3, TCGETS, 0x7ffe761f5510) = -1 ENOTTY (Inappropriate ioctl for device) lseek(3, 0, SEEK_CUR) = 0 read(3, "#!/bin/sh\n/usr/lib64/libreoffice"..., 80) = 55 lseek(3, 0, SEEK_SET) = 0 prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) = 0 fcntl(255, F_GETFD) = -1 EBADF (Bad file descriptor) dup2(3, 255) = 255 close(3) = 0 fcntl(255, F_SETFD, FD_CLOEXEC) = 0 fcntl(255, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fstat(255, {st_mode=S_IFREG|0755, st_size=55, ...}) = 0 lseek(255, 0, SEEK_CUR) = 0 read(255, "#!/bin/sh\n/usr/lib64/libreoffice"..., 55) = 55 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f8681809e50) = 6853 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGINT, {sa_handler=0x55e5d5fc7d10, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 wait4(-1, KCrash: Application 'soffice.bin' crashing... KCrash: Attempting to start /usr/lib64/libexec/drkonqi QSocketNotifier: Invalid socket 11 and type 'Read', disabling... QSocketNotifier: Invalid socket 12 and type 'Read', disabling... Unable to start Dr. Konqi Re-raising signal for core dump handling. [{WIFEXITED(s) && WEXITSTATUS(s) == 139}], 0, NULL) = 6853 rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=0x55e5d5fc7d10, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 ioctl(2, TIOCGWINSZ, {ws_row=66, ws_col=197, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 getuid() = 5076 geteuid() = 5076 getgid() = 100 getegid() = 100 getuid() = 5076 geteuid() = 5076 getuid() = 5076 geteuid() = 5076 getgid() = 100 getegid() = 100 getuid() = 5076 geteuid() = 5076 stat("/home/markh/.terminfo", 0x55e5d73ab730) = -1 ENOENT (No such file or directory) stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 getuid() = 5076 setfsuid(5076) = 5076 getgid() = 100 setfsgid(100) = 100 access("/etc/terminfo/x/xterm-256color", R_OK) = -1 ENOENT (No such file or directory) geteuid() = 5076 setfsuid(5076) = 5076 getegid() = 100 setfsgid(100) = 100 getuid() = 5076 setfsuid(5076) = 5076 getgid() = 100 setfsgid(100) = 100 access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0 openat(AT_FDCWD, "/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=3713, ...}) = 0 read(3, "\36\2%\0&\0\17\0\235\1\2\6xterm-256color|xterm"..., 32768) = 3713 read(3, "", 28672) = 0 close(3) = 0 geteuid() = 5076 setfsuid(5076) = 5076 getegid() = 100 setfsgid(100) = 100 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=66, ws_col=197, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(0, TIOCGWINSZ, {ws_row=66, ws_col=197, ws_xpixel=0, ws_ypixel=0}) = 0 brk(0x55e5d73d3000) = 0x55e5d73d3000 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6853, si_uid=5076, si_status=139, si_utime=1, si_stime=0} --- wait4(-1, 0x7ffe761f4cd0, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigreturn({mask=[]}) = 0 read(255, "", 55) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(139) = ? +++ exited with 139 +++ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2020-08-13 at 06:39 -0400, Mark Hounschell wrote:
I have 2 machines doing this. I cant open .xls files. These 2 machines were updated from 15.1 via "zypper dup". The 15.1 systems worked. Maybe this strace will shed some light?
I think most of it is trying to report the problem, starting "Dr. Konqi"...
markh@harley:~> strace ooffice Weekly\ Expense\ Report-Form\ ER-000-rev9.xls execve("/usr/bin/ooffice", ["ooffice", "Weekly Expense Report-Form ER-00"...], 0x7ffc9ba127b8 /* 120 vars */) = 0 brk(NULL) = 0x55e5d7391000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/x86_64/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
I think this is the starting of it. libreadline.so.7 is at /lib64/libreadline.so.7. It inserts "/bash".
stat("/lib64/bash/tls/x86_64/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/tls/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/tls", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/x86_64/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/x86_64/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/x86_64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash/x86_64", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib64/bash/libreadline.so.7", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib64/bash", 0x7ffe761f4ef0) = -1 ENOENT (No such file or directory)
I think here it gives up.
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=222001, ...}) = 0 mmap(NULL, 222001, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f868180d000 close(3) = 0 openat(AT_FDCWD, "/lib64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \213\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=317432, ...}) = 0
Ah, no, here it finds the library. Then it open other files. Trimming. ... signals handling and things
stat("/home/markh", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 stat(".", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/home/markh", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 getpid() = 6852 getppid() = 6849 getpid() = 6852 getpgrp() = 6849 ioctl(2, TIOCGPGRP, [6849]) = 0 rt_sigaction(SIGCHLD, {sa_handler=0x55e5d5fcca40, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8680e4f5a0}, 8) = 0 prlimit64(0, RLIMIT_NPROC, NULL, {rlim_cur=63782, rlim_max=63782}) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 openat(AT_FDCWD, "/usr/bin/ooffice", O_RDONLY) = 3 stat("/usr/bin/ooffice", {st_mode=S_IFREG|0755, st_size=55, ...}) = 0 ioctl(3, TCGETS, 0x7ffe761f5510) = -1 ENOTTY (Inappropriate ioctl for device) lseek(3, 0, SEEK_CUR) = 0 read(3, "#!/bin/sh\n/usr/lib64/libreoffice"..., 80) = 55 lseek(3, 0, SEEK_SET) = 0 prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) = 0 fcntl(255, F_GETFD) = -1 EBADF (Bad file descriptor) dup2(3, 255) = 255 close(3) = 0 fcntl(255, F_SETFD, FD_CLOEXEC) = 0 fcntl(255, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fstat(255, {st_mode=S_IFREG|0755, st_size=55, ...}) = 0 lseek(255, 0, SEEK_CUR) = 0 read(255, "#!/bin/sh\n/usr/lib64/libreoffice"..., 55) = 55 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f8681809e50) = 6853 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGINT, {sa_handler=0x55e5d5fc7d10, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f8680e4f5a0}, 8) = 0 wait4(-1, KCrash: Application 'soffice.bin' crashing...
Here it crashes. I don't see why, I don't know enough. Is it a child?
KCrash: Attempting to start /usr/lib64/libexec/drkonqi QSocketNotifier: Invalid socket 11 and type 'Read', disabling... QSocketNotifier: Invalid socket 12 and type 'Read', disabling... Unable to start Dr. Konqi Re-raising signal for core dump handling.
...
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(139) = ? +++ exited with 139 +++
- -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXzUfjhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVG94AmwQKYk+f7LRpMq0bWGyo FfrgmOVtAJ4/b1ZXN0IpbN2c7TM+Fhj3indEYw== =PiP+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 13 Aug 2020 06:39:43 -0400 Mark Hounschell <dmarkh@cfl.rr.com> wrote:
I have 2 machines doing this. I cant open .xls files. These 2 machines were updated from 15.1 via "zypper dup". The 15.1 systems worked. Maybe this strace will shed some light?
markh@harley:~> strace ooffice Weekly\ Expense\ Report-Form\ ER-000-rev9.xls execve("/usr/bin/ooffice", ["ooffice", "Weekly [snip lots of stuff]
What happens if you start soffice first and then try to open a .xls file? What version of LO is it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/20 7:29 AM, Dave Howorth wrote:
On Thu, 13 Aug 2020 06:39:43 -0400 Mark Hounschell <dmarkh@cfl.rr.com> wrote:
I have 2 machines doing this. I cant open .xls files. These 2 machines were updated from 15.1 via "zypper dup". The 15.1 systems worked. Maybe this strace will shed some light?
markh@harley:~> strace ooffice Weekly\ Expense\ Report-Form\ ER-000-rev9.xls execve("/usr/bin/ooffice", ["ooffice", "Weekly [snip lots of stuff]
What happens if you start soffice first and then try to open a .xls file?
Same thing.
What version of LO is it?
libreoffice-6.4.4.2-lp152.1.2.x86_64 Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/13/20 5:39 AM, Mark Hounschell wrote: The strace looks fairly normal until
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
Up to that point it's just the normal checking all path locations for where files like libreadline.so.7 are located (which is found at /lib64/libreadline.so.7. The problem is the call to ioctl (see: man 2 ioctl) int ioctl(int fd, unsigned long request, ...); The file descriptor passed is `-1` which raises EBADF (Bad file descriptor) because -1 is a bad file descriptor. Why that is happening is the question to answer. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/08/2020 00.29, David C. Rankin wrote:
On 8/13/20 5:39 AM, Mark Hounschell wrote:
The strace looks fairly normal until
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
Up to that point it's just the normal checking all path locations for where files like libreadline.so.7 are located (which is found at /lib64/libreadline.so.7.
The problem is the call to ioctl (see: man 2 ioctl)
int ioctl(int fd, unsigned long request, ...);
The file descriptor passed is `-1` which raises EBADF (Bad file descriptor) because -1 is a bad file descriptor. Why that is happening is the question to answer.
Interesting. open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=330604, ...}) = 0 mmap(NULL, 330604, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8681688000 close(3) = 0 getuid() = 5076 getgid() = 100 geteuid() = 5076 getegid() = 100 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor) The last file handle was "3", but the file was closed. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 8/13/20 8:47 PM, Carlos E. R. wrote:
ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
The last file handle was "3", but the file was close Yes,
That is odd. There is a close() following every open() when the program is loading files, so that part is normal. The -1 on the file descriptor is hosed. I'm not sure what the request 'TIOCGPGRP' but I suspect it is some group ownership related request. The address, 0x7ffe761f5584 doesn't correspond to any other mapped region shown in the posted strace output -- so I'm lost there. Somebody who looks at strace output more often than I do will have to chime in with further thoughts. Unfortunately, you can't just read the strace sequentially, especially for programs making use of pthreads. The ioctl call may be from a completely unrelated thread from what is generating the normal file loads that are coming immediately before it. Since it is .xls related, there may be a corrupt Mime-type for excel spreadsheets, or some similar related part of what goes into opening .xls files that is going wrong. I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace. -- David C. Rankin, J.D.,P.E.
On 14/08/2020 06.25, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
The last file handle was "3", but the file was close Yes,
That is odd. There is a close() following every open() when the program is loading files, so that part is normal. The -1 on the file descriptor is hosed. I'm not sure what the request 'TIOCGPGRP' but I suspect it is some group ownership related request. The address, 0x7ffe761f5584 doesn't correspond to any other mapped region shown in the posted strace output -- so I'm lost there.
Somebody who looks at strace output more often than I do will have to chime in with further thoughts. Unfortunately, you can't just read the strace sequentially, especially for programs making use of pthreads. The ioctl call may be from a completely unrelated thread from what is generating the normal file loads that are coming immediately before it.
Since it is .xls related, there may be a corrupt Mime-type for excel spreadsheets, or some similar related part of what goes into opening .xls files that is going wrong.
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Yes. And possibly there is also a coredump. If the situation is reproducible, there is a procedure (with the debugger) to get way more information. I can explain if wanted. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 14/08/2020 12.09, Carlos E. R. wrote:
On 14/08/2020 06.25, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
...
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Yes.
And possibly there is also a coredump. If the situation is reproducible, there is a procedure (with the debugger) to get way more information. I can explain if wanted.
Huh, no need to repeat situation, I forgot. The info is extracted from the coredump. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 8/14/20 6:10 AM, Carlos E. R. wrote:
On 14/08/2020 12.09, Carlos E. R. wrote:
On 14/08/2020 06.25, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
...
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Yes.
And possibly there is also a coredump. If the situation is reproducible, there is a procedure (with the debugger) to get way more information. I can explain if wanted.
Huh, no need to repeat situation, I forgot. The info is extracted from the coredump.
I do not find a core dump? Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/08/2020 14.41, Mark Hounschell wrote:
On 8/14/20 6:10 AM, Carlos E. R. wrote:
On 14/08/2020 12.09, Carlos E. R. wrote:
On 14/08/2020 06.25, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
...
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Yes.
And possibly there is also a coredump. If the situation is reproducible, there is a procedure (with the debugger) to get way more information. I can explain if wanted.
Huh, no need to repeat situation, I forgot. The info is extracted from the coredump.
I do not find a core dump?
Curious, the trace mentions it. You could try the command "coredumpctl" to see what it says. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 8/14/20 1:16 PM, Carlos E. R. wrote:
On 14/08/2020 14.41, Mark Hounschell wrote:
On 8/14/20 6:10 AM, Carlos E. R. wrote:
On 14/08/2020 12.09, Carlos E. R. wrote:
On 14/08/2020 06.25, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
...
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Yes.
And possibly there is also a coredump. If the situation is reproducible, there is a procedure (with the debugger) to get way more information. I can explain if wanted.
Huh, no need to repeat situation, I forgot. The info is extracted from the coredump.
I do not find a core dump?
Curious, the trace mentions it. You could try the command "coredumpctl" to see what it says.
# coredumpctl If 'coredumpctl' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf coredumpctl Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/08/2020 19.50, Mark Hounschell wrote:
On 8/14/20 1:16 PM, Carlos E. R. wrote:
On 14/08/2020 14.41, Mark Hounschell wrote:
On 8/14/20 6:10 AM, Carlos E. R. wrote:
On 14/08/2020 12.09, Carlos E. R. wrote:
On 14/08/2020 06.25, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
...
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Yes.
And possibly there is also a coredump. If the situation is reproducible, there is a procedure (with the debugger) to get way more information. I can explain if wanted.
Huh, no need to repeat situation, I forgot. The info is extracted from the coredump.
I do not find a core dump?
Curious, the trace mentions it. You could try the command "coredumpctl" to see what it says.
# coredumpctl If 'coredumpctl' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf coredumpctl
I did not know/remember it was not installed by default. Well, it is giving you the hint of what to do, "cnf coredumpctl", which will tell you to run "zypper install systemd-coredump" -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 14/08/2020 19.56, Carlos E. R. wrote:
On 14/08/2020 19.50, Mark Hounschell wrote:
On 8/14/20 1:16 PM, Carlos E. R. wrote:
On 14/08/2020 14.41, Mark Hounschell wrote:
On 8/14/20 6:10 AM, Carlos E. R. wrote:
On 14/08/2020 12.09, Carlos E. R. wrote:
On 14/08/2020 06.25, David C. Rankin wrote: > On 8/13/20 8:47 PM, Carlos E. R. wrote:
...
Curious, the trace mentions it. You could try the command "coredumpctl" to see what it says.
# coredumpctl If 'coredumpctl' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf coredumpctl
I did not know/remember it was not installed by default. Well, it is giving you the hint of what to do, "cnf coredumpctl", which will tell you to run "zypper install systemd-coredump"
Of course, if that was not installed previously, it is possible that the coredump was not collected. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hello, On Thu, 13 Aug 2020, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
The last file handle was "3", but the file was close Yes,
That is odd. There is a close() following every open() when the program is loading files, so that part is normal. The -1 on the file descriptor is hosed. I'm not sure what the request 'TIOCGPGRP' but I suspect it is some group ownership related request. The address, 0x7ffe761f5584 doesn't correspond to any other mapped region shown in the posted strace output -- so I'm lost there.
You're right, that should be a valid fd to a tty. See 'man 2 ioctl' and 'man 2 ioctl_tty' and 'man 3 tcgetpgrp'. ==== TIOCGPGRP pid_t *argp When successful, equivalent to *argp = tcgetpgrp(fd). Get the process group ID of the foreground process group on this terminal. ==== As this whole thing is just a strace of the shell running the script /usr/bin/ooffice, this is rather useless. The OP should try: $ strace -f -s 128 -o ooffice.strace /usr/bin/ooffice ... or maybe: $ ltrace -f -S -s 128 -o ooffice.ltrace /usr/bin/ooffice ... HTH, -dnh -- hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. -- bash.org/?top -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/14/20 7:12 AM, David Haller wrote:
Hello,
On Thu, 13 Aug 2020, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
The last file handle was "3", but the file was close Yes,
That is odd. There is a close() following every open() when the program is loading files, so that part is normal. The -1 on the file descriptor is hosed. I'm not sure what the request 'TIOCGPGRP' but I suspect it is some group ownership related request. The address, 0x7ffe761f5584 doesn't correspond to any other mapped region shown in the posted strace output -- so I'm lost there.
You're right, that should be a valid fd to a tty. See 'man 2 ioctl' and 'man 2 ioctl_tty' and 'man 3 tcgetpgrp'.
==== TIOCGPGRP pid_t *argp When successful, equivalent to *argp = tcgetpgrp(fd). Get the process group ID of the foreground process group on this terminal. ====
As this whole thing is just a strace of the shell running the script /usr/bin/ooffice, this is rather useless. The OP should try:
$ strace -f -s 128 -o ooffice.strace /usr/bin/ooffice ...
or maybe:
$ ltrace -f -S -s 128 -o ooffice.ltrace /usr/bin/ooffice ...
Both of those create quite large ooffice.strace files. Should I post them somewhere? Or maybe add them to the filed bug report? Thanks Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/14/20 9:08 AM, Mark Hounschell wrote:
On 8/14/20 7:12 AM, David Haller wrote:
Hello,
On Thu, 13 Aug 2020, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
The last file handle was "3", but the file was close Yes,
That is odd. There is a close() following every open() when the program is loading files, so that part is normal. The -1 on the file descriptor is hosed. I'm not sure what the request 'TIOCGPGRP' but I suspect it is some group ownership related request. The address, 0x7ffe761f5584 doesn't correspond to any other mapped region shown in the posted strace output -- so I'm lost there.
You're right, that should be a valid fd to a tty. See 'man 2 ioctl' and 'man 2 ioctl_tty' and 'man 3 tcgetpgrp'.
==== TIOCGPGRP pid_t *argp When successful, equivalent to *argp = tcgetpgrp(fd). Get the process group ID of the foreground process group on this terminal. ====
As this whole thing is just a strace of the shell running the script /usr/bin/ooffice, this is rather useless. The OP should try:
$ strace -f -s 128 -o ooffice.strace /usr/bin/ooffice ...
or maybe:
$ ltrace -f -S -s 128 -o ooffice.ltrace /usr/bin/ooffice ...
Both of those create quite large ooffice.strace files. Should I post them somewhere? Or maybe add them to the filed bug report?
Actually the ltrace one doesn't work. It complains about ooffice being a script not an ELF file. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Fri, 14 Aug 2020, Mark Hounschell wrote:
On 8/14/20 9:08 AM, Mark Hounschell wrote:
On 8/14/20 7:12 AM, David Haller wrote: [..]
$ strace -f -s 128 -o ooffice.strace /usr/bin/ooffice ...
or maybe:
$ ltrace -f -S -s 128 -o ooffice.ltrace /usr/bin/ooffice ...
Both of those create quite large ooffice.strace files. Should I post them somewhere?
Yes. Or send them directly to me (gzipped).
Or maybe add them to the filed bug report?
Actually the ltrace one doesn't work. It complains about ooffice being a script not an ELF file.
Use 'ltrace ... bash /usr/bin/ooffice ...' HTH, -dnh -- panic("CPU too expensive - making holiday in the ANDES!"); linux-2.2.16/arch/mips/kernel/traps.c -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 14 Aug 2020 16:13:32 +0200 David Haller <dnh@opensuse.org> wrote:
Hello,
On Fri, 14 Aug 2020, Mark Hounschell wrote:
On 8/14/20 9:08 AM, Mark Hounschell wrote:
On 8/14/20 7:12 AM, David Haller wrote: [..]
$ strace -f -s 128 -o ooffice.strace /usr/bin/ooffice ...
or maybe:
$ ltrace -f -S -s 128 -o ooffice.ltrace /usr/bin/ooffice ...
Both of those create quite large ooffice.strace files. Should I post them somewhere?
Yes. Or send them directly to me (gzipped).
Or maybe add them to the filed bug report?
Actually the ltrace one doesn't work. It complains about ooffice being a script not an ELF file.
Use 'ltrace ... bash /usr/bin/ooffice ...'
HTH, -dnh
loffice already includes it's own command-line options (e.g. --strace) to set up appropriate diagnostic commands. It's probably better to RTFM and use those when reporting bugs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Fri, 14 Aug 2020, Dave Howorth wrote:
loffice already includes it's own command-line options (e.g. --strace) to set up appropriate diagnostic commands. It's probably better to RTFM and use those when reporting bugs.
==== --strace) if which strace >/dev/null 2>&1 ; then STRACECHECK="strace -o strace.log -f -tt -s 256" checks="c$checks" ==== It's better to read scripts and use what is used anyway. -dnh -- "I treat shops as military objectives to be penetrated and stripped of needed resources in as little time as possible. She has adventures in them." -- Joe Thompson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/14/20 10:13 AM, David Haller wrote:
Hello,
On Fri, 14 Aug 2020, Mark Hounschell wrote:
On 8/14/20 9:08 AM, Mark Hounschell wrote:
On 8/14/20 7:12 AM, David Haller wrote: [..]
$ strace -f -s 128 -o ooffice.strace /usr/bin/ooffice ...
or maybe:
$ ltrace -f -S -s 128 -o ooffice.ltrace /usr/bin/ooffice ...
Both of those create quite large ooffice.strace files. Should I post them somewhere?
Yes. Or send them directly to me (gzipped).
Done. Regards Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/14/20 12:25 AM, David C. Rankin wrote:
On 8/13/20 8:47 PM, Carlos E. R. wrote:
ioctl(-1, TIOCGPGRP, 0x7ffe761f5584) = -1 EBADF (Bad file descriptor)
The last file handle was "3", but the file was close Yes,
That is odd. There is a close() following every open() when the program is loading files, so that part is normal. The -1 on the file descriptor is hosed. I'm not sure what the request 'TIOCGPGRP' but I suspect it is some group ownership related request. The address, 0x7ffe761f5584 doesn't correspond to any other mapped region shown in the posted strace output -- so I'm lost there.
Somebody who looks at strace output more often than I do will have to chime in with further thoughts. Unfortunately, you can't just read the strace sequentially, especially for programs making use of pthreads. The ioctl call may be from a completely unrelated thread from what is generating the normal file loads that are coming immediately before it.
Since it is .xls related, there may be a corrupt Mime-type for excel spreadsheets, or some similar related part of what goes into opening .xls files that is going wrong.
It does not seem to be .xls related as I cannot start ooffice with no file specified.
I would open a bug against libreoffice with the openSUSE bugzilla and include the strace output as an attachment. The devs there are much more fluent in strace.
Bugzilla – Bug 1175285 Submitted Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Carlos E. R.
-
Carlos E.R.
-
Dave Howorth
-
David C. Rankin
-
David Haller
-
Mark Hounschell
-
Mark Hounschell