I run libreoffice writer (master) on the attached document, I print both pages, and three copies of them (collated). When I do that, I get this in valgrind: ==28051== Invalid read of size 4 ==28051== at 0x140D0AC1: PyObject_Free (obmalloc.c:969) ==28051== by 0x1414D417: PyObject_GC_Del (gcmodule.c:1507) ==28051== by 0x140A48A4: code_dealloc (codeobject.c:317) ==28051== by 0x14132EF0: load_source_module (import.c:1022) ==28051== by 0x14133C18: import_submodule (import.c:2596) ==28051== by 0x14133EDC: load_next (import.c:2416) ==28051== by 0x14134821: import_module_level.isra.3 (import.c:2137) ==28051== by 0x14134AD0: PyImport_ImportModuleLevel (import.c:2189) ==28051== by 0x1411C20E: builtin___import__ (bltinmodule.c:49) ==28051== by 0x140CCD74: PyCFunction_Call (methodobject.c:85) ==28051== by 0x140950F3: PyObject_Call (abstract.c:2529) ==28051== by 0x1411D619: PyEval_CallObjectWithKeywords (ceval.c:3882) ==28051== Address 0xe178010 is 8 bytes after a block of size 40 alloc'd ==28051== at 0x4029C24: malloc (vg_replace_malloc.c:236) ==28051== by 0x512E704: rtl_allocateMemory_SYSTEM(unsigned long) (alloc_global.cxx:278) ==28051== by 0x512E819: rtl_allocateMemory (alloc_global.cxx:311) ==28051== by 0x64A829C: ??? (in /data/opt/libreoffice/master/solver/unxlngi6.pro/lib/libtllo.so) ==28051== by 0x64A8B49: String::Erase(unsigned short, unsigned short) (in /data/opt/libreoffice/master/solver/unxlngi6.pro/lib/libtllo.so) ==28051== by 0x65D1C7D: GetEnglishSearchFontName(String&) (in /data/opt/libreoffice/master/solver/unxlngi6.pro/lib/libutllo.so) ==28051== by 0x6A28EE2: ImplDevFontList::Add(ImplFontData*) (outdev3.cxx:1495) ==28051== by 0x6C68265: GenPspGraphics::AnnounceFonts(ImplDevFontList*, psp::FastPrintFontInfo const&) (genpspgraphics.cxx:1230) ==28051== by 0x6C67519: GenPspGraphics::GetDevFontList(ImplDevFontList*) (genpspgraphics.cxx:904) ==28051== by 0x6B2B9DC: Printer::ImplInit(SalPrinterQueueInfo*) (print.cxx:538) ==28051== by 0x6B2C430: Printer::Printer(rtl::OUString const&) (print.cxx:685) ==28051== by 0x5B43821: SfxPrinter::SfxPrinter(SfxItemSet*, JobSetup const&) (in /data/opt/libreoffice/master/solver/unxlngi6.pro/lib/libsfxlo.so) ==28051== ==28051== Conditional jump or move depends on uninitialised value(s) ==28051== at 0x140D0ACA: PyObject_Free (obmalloc.c:969) ==28051== by 0x1408B3A6: string_dealloc (stringobject.c:597) ==28051== by 0x140A47C1: code_dealloc (codeobject.c:307) ==28051== by 0x14132EF0: load_source_module (import.c:1022) ==28051== by 0x14133C18: import_submodule (import.c:2596) ==28051== by 0x14133EDC: load_next (import.c:2416) ==28051== by 0x14134821: import_module_level.isra.3 (import.c:2137) ==28051== by 0x14134AD0: PyImport_ImportModuleLevel (import.c:2189) ==28051== by 0x1411C20E: builtin___import__ (bltinmodule.c:49) ==28051== by 0x140CCD74: PyCFunction_Call (methodobject.c:85) ==28051== by 0x140950F3: PyObject_Call (abstract.c:2529) ==28051== by 0x1411D619: PyEval_CallObjectWithKeywords (ceval.c:3882) ==28051== ==28051== Invalid read of size 4 ==28051== at 0x140D0AC1: PyObject_Free (obmalloc.c:969) ==28051== by 0x1414D417: PyObject_GC_Del (gcmodule.c:1507) ==28051== by 0x140A48A4: code_dealloc (codeobject.c:317) ==28051== by 0x140E0633: tupledealloc (tupleobject.c:220) ==28051== by 0x140A47DF: code_dealloc (codeobject.c:308) ==28051== by 0x14132EF0: load_source_module (import.c:1022) ==28051== by 0x14133C18: import_submodule (import.c:2596) ==28051== by 0x14133EDC: load_next (import.c:2416) ==28051== by 0x14134821: import_module_level.isra.3 (import.c:2137) ==28051== by 0x14134AD0: PyImport_ImportModuleLevel (import.c:2189) ==28051== by 0x1411C20E: builtin___import__ (bltinmodule.c:49) ==28051== by 0x140CCD74: PyCFunction_Call (methodobject.c:85) ==28051== Address 0xf89f010 is not stack'd, malloc'd or (recently) free'd ==28051== And much more badness. Looks pretty scary to me :-)
Created attachment 56220 [details] sample document (prolly unrelated)
I saw this log in the master build around 6th/Jan as well. But couldn't see the similar thing in 3.5 rc2 pre-release build.
(In reply to comment #2) > I saw this log in the master build around 6th/Jan as well. As a complementary, in my master build the "Invalid read of size 4" errors were logged, but soffice.bin still survived without crash.
FWIW, just had a related-looking abort (--enable-dbgutil glibc "double free or corruption (fasttop)") from within pyuno::GCThread during sw_complex test; appears to only happen sporadically, as subsequent runs of sw_complex succeeded again. Core was generated by `/data/lo/core/solver/unxlngx6/installation/opt/program/soffice.bin -env:UserIns'. Program terminated with signal 6, Aborted. #0 0x00000037e6836285 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Thread 5 (Thread 0x7f792affd700 (LWP 15902)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 #1 0x00007f794ec2add9 in osl_waitCondition (Condition=0x7f792020f0d0, pTimeout=0x7f792affca50) at /data/lo/core/sal/osl/unx/conditn.cxx:264 #2 0x00007f794dc3470a in cppu_threadpool::ThreadPool::waitInPool (this=0x7f7930004660, pThread=0x7f791c000db0) at /data/lo/core/cppu/source/threadpool/threadpool.cxx:197 #3 0x00007f794dc3105a in cppu_threadpool::ORequestThread::run (this=0x7f791c000db0) at /data/lo/core/cppu/source/threadpool/thread.cxx:240 #4 0x00007f794dc30740 in cppu_requestThreadWorker (pVoid=0x7f791c000db0) at /data/lo/core/cppu/source/threadpool/thread.cxx:57 #5 0x00007f794ebe53c3 in osl_thread_start_Impl (pData=0x7f791c001040) at /data/lo/core/sal/osl/unx/thread.c:292 #6 0x00000037e6c07d90 in start_thread (arg=0x7f792affd700) at pthread_create.c:309 #7 0x00000037e68ef48d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 4 (Thread 0x7f790ffff700 (LWP 15913)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 #1 0x00007f794ec2add9 in osl_waitCondition (Condition=0x7f79080333d0, pTimeout=0x7f790fffea50) at /data/lo/core/sal/osl/unx/conditn.cxx:264 #2 0x00007f794dc3470a in cppu_threadpool::ThreadPool::waitInPool (this=0x7f7930004660, pThread=0x7f791c0028b0) at /data/lo/core/cppu/source/threadpool/threadpool.cxx:197 #3 0x00007f794dc3105a in cppu_threadpool::ORequestThread::run (this=0x7f791c0028b0) at /data/lo/core/cppu/source/threadpool/thread.cxx:240 #4 0x00007f794dc30740 in cppu_requestThreadWorker (pVoid=0x7f791c0028b0) at /data/lo/core/cppu/source/threadpool/thread.cxx:57 #5 0x00007f794ebe53c3 in osl_thread_start_Impl (pData=0x7f791c002910) at /data/lo/core/sal/osl/unx/thread.c:292 #6 0x00000037e6c07d90 in start_thread (arg=0x7f790ffff700) at pthread_create.c:309 #7 0x00000037e68ef48d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 3 (Thread 0x7f79457b3700 (LWP 15894)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 #1 0x00007f794ebfa7ae in rtl_cache_wsupdate_wait (seconds=10) at /data/lo/core/sal/rtl/source/alloc_cache.cxx:1411 #2 0x00007f794ebfa985 in rtl_cache_wsupdate_all (arg=0xa) at /data/lo/core/sal/rtl/source/alloc_cache.cxx:1551 #3 0x00000037e6c07d90 in start_thread (arg=0x7f79457b3700) at pthread_create.c:309 #4 0x00000037e68ef48d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 2 (Thread 0x7f79457c58c0 (LWP 15893)): #0 0x00000037e687c69a in malloc_consolidate (av=0x7f7920000020) at malloc.c:4264 #1 0x00000037e687d3c9 in malloc_consolidate (av=0x7f7920000020) at malloc.c:4227 #2 _int_free (av=0x7f7920000020, p=<optimized out>, have_lock=0) at malloc.c:4158 #3 0x00007f794ac1c7fe in __gnu_cxx::new_allocator<utl::FontNameAttr>::deallocate (this=0x7f792007d950, __p=0x7f792007da00) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/ext/new_allocator.h:98 #4 0x00007f794ac19030 in std::__cxx1998::_Vector_base<utl::FontNameAttr, std::allocator<utl::FontNameAttr> >::_M_deallocate (this=0x7f792007d950, __p=0x7f792007da00, __n=352) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_vector.h:156 #5 0x00007f794ac180b2 in std::__cxx1998::_Vector_base<utl::FontNameAttr, std::allocator<utl::FontNameAttr> >::~_Vector_base (this=0x7f792007d950, __in_chrg=<optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_vector.h:142 #6 0x00007f794ac1596c in std::__cxx1998::vector<utl::FontNameAttr, std::allocator<utl::FontNameAttr> >::~vector (this=0x7f792007d950, __in_chrg=<optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_vector.h:351 #7 0x00007f794ac1446d in std::__debug::vector<utl::FontNameAttr, std::allocator<utl::FontNameAttr> >::~vector (this=0x7f792007d950, __in_chrg=<optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/debug/vector:126 #8 0x00007f794ac1408d in utl::FontSubstConfiguration::LocaleSubst::~LocaleSubst (this=0x7f792007d940, __in_chrg=<optimized out>) at /data/lo/core/solver/unxlngx6/inc/unotools/fontcfg.hxx:183 #9 0x00007f794ac1bfd7 in std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst>::~pair (this=0x7f792007d928, __in_chrg=<optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_pair.h:87 #10 0x00007f794ac1c01c in boost::unordered_detail::destroy<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> > (x=0x7f792007d928) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/fwd.hpp:86 #11 0x00007f794ac23582 in boost::unordered_detail::hash_buckets<std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> >, boost::unordered_detail::ungrouped>::delete_node (this=0x7f794af5d550, b=0x7f792007d920) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/buckets.hpp:67 #12 0x00007f794ac219a0 in boost::unordered_detail::hash_buckets<std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> >, boost::unordered_detail::ungrouped>::clear_bucket (this=0x7f794af5d550, b=0x7f792007d9c8) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/buckets.hpp:82 #13 0x00007f794ac1f034 in boost::unordered_detail::hash_buckets<std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> >, boost::unordered_detail::ungrouped>::delete_buckets (this=0x7f794af5d550) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/buckets.hpp:92 #14 0x00007f794ac1be41 in boost::unordered_detail::hash_buckets<std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> >, boost::unordered_detail::ungrouped>::~hash_buckets (this=0x7f794af5d550, __in_chrg=<optimized out>) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/buckets.hpp:135 #15 0x00007f794ac18905 in boost::unordered_detail::hash_table<boost::unordered_detail::map<com::sun::star::lang::Locale, utl::LocaleHash, std::equal_to<com::sun::star::lang::Locale>, std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> > > >::~hash_table (this=0x7f794af5d550, __in_chrg=<optimized out>) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/fwd.hpp:494 #16 0x00007f794ac15fdc in boost::unordered_detail::hash_unique_table<boost::unordered_detail::map<com::sun::star::lang::Locale, utl::LocaleHash, std::equal_to<com::sun::star::lang::Locale>, std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> > > >::~hash_unique_table (this=0x7f794af5d550, __in_chrg=<optimized out>) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/detail/unique.hpp:49 #17 0x00007f794ac147ee in boost::unordered_map<com::sun::star::lang::Locale, utl::FontSubstConfiguration::LocaleSubst, utl::LocaleHash, std::equal_to<com::sun::star::lang::Locale>, std::allocator<std::pair<com::sun::star::lang::Locale const, utl::FontSubstConfiguration::LocaleSubst> > >::~unordered_map (this=0x7f794af5d550, __in_chrg=<optimized out>) at /data/lo/core/solver/unxlngx6/inc/boost/unordered/unordered_map.hpp:160 #18 0x00007f794ac11b7b in utl::FontSubstConfiguration::~FontSubstConfiguration (this=0x7f794af5d540, __in_chrg=<optimized out>) at /data/lo/core/unotools/source/config/fontcfg.cxx:474 #19 0x00000037e6839931 in __run_exit_handlers (status=0, listp=0x37e6baf668, run_list_atexit=true) at exit.c:78 #20 0x00000037e68399b5 in __GI_exit (status=<optimized out>) at exit.c:100 #21 0x00000037e68216a4 in __libc_start_main (main=0x4006f4 <main>, argc=9, ubp_av=0x7fff2cbf9648, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff2cbf9638) at libc-start.c:258 #22 0x0000000000400639 in _start () Thread 1 (Thread 0x7f7914d4e700 (LWP 15918)): #0 0x00000037e6836285 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000037e6837b9b in __GI_abort () at abort.c:91 #2 0x00000037e6875fae in __libc_message (do_abort=2, fmt=0x37e6974b98 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 #3 0x00000037e687c2d6 in malloc_printerr (action=3, str=0x37e6974cd0 "double free or corruption (fasttop)", ptr=<optimized out>) at malloc.c:5021 #4 0x00007f790f5c7684 in __gnu_cxx::new_allocator<rtl::OString>::deallocate (this=0x7f790f7fec40, __p=0x7f79100715d0) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/ext/new_allocator.h:98 #5 0x00007f790f5c69a2 in std::__cxx1998::_Vector_base<rtl::OString, std::allocator<rtl::OString> >::_M_deallocate (this=0x7f790f7fec40, __p=0x7f79100715d0, __n=1) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_vector.h:156 #6 0x00007f790f5c6cbc in std::__cxx1998::vector<rtl::OString, std::allocator<rtl::OString> >::_M_insert_aux<rtl::OString>(__gnu_cxx::__normal_iterator<rtl::OString*, std::__cxx1998::vector<rtl::OString, std::allocator<rtl::OString> > >, rtl::OString&&) (this=0x7f790f7fec40, __position="") at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/vector.tcc:366 #7 0x00007f790f5c5c7a in std::__cxx1998::vector<rtl::OString, std::allocator<rtl::OString> >::emplace_back<rtl::OString>(rtl::OString&&) (this=0x7f790f7fec40) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/bits/vector.tcc:102 #8 0x00007f790f5c4ebe in std::__debug::vector<rtl::OString, std::allocator<rtl::OString> >::emplace_back<rtl::OString>(rtl::OString&&) (this=0x7f790f7fec40) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/debug/vector:381 #9 0x00007f790f5c39ca in std::__debug::vector<rtl::OString, std::allocator<rtl::OString> >::push_back<rtl::OString>(rtl::OString&&) (this=0x7f790f7fec40, __x=<unknown type in /data/lo/core/solver/unxlngx6/installation/opt/program/../program/libpyuno.so, CU 0xd2, DIE 0x2bb65>) at /usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/debug/vector:374 #10 0x00007f790f5bb7e6 in pyuno::ensureUnlimitedLifetime (str=0x37e6972148 "C") at /data/lo/core/pyuno/source/module/pyuno_runtime.cxx:1035 #11 0x00007f790f5bb912 in pyuno::PyThreadAttach::PyThreadAttach (this=0x7f7914d4db50, interp=0x7f7910005450) at /data/lo/core/pyuno/source/module/pyuno_runtime.cxx:1052 #12 0x00007f790f5e2f0e in pyuno::GCThread::run (this=0x7f793c19d998) at /data/lo/core/pyuno/source/module/pyuno_gc.cxx:75 #13 0x00007f790f5e3573 in osl::threadFunc (param=0x7f793c19d998) at /data/lo/core/solver/unxlngx6/inc/osl/thread.hxx:190 #14 0x00007f794ebe53c3 in osl_thread_start_Impl (pData=0x1b6db00) at /data/lo/core/sal/osl/unx/thread.c:292 #15 0x00000037e6c07d90 in start_thread (arg=0x7f7914d4e700) at pthread_create.c:309 #16 0x00000037e68ef48d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
Any update with more recent LO version? (knowing that we use now Python 3.X)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.3 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results; 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
Any update on this 4-years-old bug? Is the bug still exist in the recent versions?
Let's put this one to NEEDINFO meanwhile.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170131
Dear Bug Submitter, 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-20170301