Bug 162935 - ooimpress-creating presentation using wizard crashes in M_reclaim_block
ooimpress-creating presentation using wizard crashes in M_reclaim_block
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
: 162959 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-07-11 14:25 EDT by Sammy
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-14 07:44:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
got a workaround anyway (1.14 KB, patch)
2005-07-12 09:27 EDT, Caolan McNamara
no flags Details | Diff
reproducable testcase (699 bytes, application/x-gzip)
2005-07-14 05:25 EDT, Caolan McNamara
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 22482 None None None Never

  None (edit)
Description Sammy 2005-07-11 14:25:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux; X11; en_US) KHTML/3.4.2 (like Gecko)

Description of problem:
If you start ooimpress and try to create a "empty presentation" using allways the defaults  
at the end when you say Create. it crashes.  
If you start an old presentation and choose New from the File menu and create one  
that way it works.  
crash log is attached. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start ooimpress 
2. create an empty presentation using the wizard 

Additional info:
Comment 1 Sammy 2005-07-11 14:29:04 EDT
$ ooimpress

---start copy and paste here---
0x8a4c46: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1dc46
0x8a5494: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e494
0x2b6420:  + 0x420 (__kernel_sigreturn + 0x0)
0x24a508c: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x3108c
0x24a50b8: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x310b8
0x24a51d2: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x311d2
0x24a5219: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x31219
0x24a523f: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x3123f
0x249d743: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x29743
0x249acad: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x26cad
0x24926ad: /usr/lib/openoffice.org2.0/program/libsdui680li.so + 0x1e6ad
0xb520ae07: /usr/lib/openoffice.org2.0/program/libsd680li.so + 0x13be07
0xb5208b1a: /usr/lib/openoffice.org2.0/program/libsd680li.so + 0x139b1a
0x3ef0bb6: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x19dbb6
0x3ef65d7: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1a35d7
(SfxShell::ExecuteSlot(SfxRequest&, SfxInterface const*) + 0x91)
0xb530fe42: /usr/lib/openoffice.org2.0/program/libsd680li.so + 0x240e42
0x5b5497a: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0x9297a
0x3dfbda6: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0xa8da6
0x3df3390: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0xa0390
0x3ef0bb6: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x19dbb6
0x3ef65d7: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1a35d7
(SfxShell::ExecuteSlot(SfxRequest&, SfxInterface const*) + 0x91)
0x3ec00fa: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x16d0fa
0x5bb685c: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xf485c
0x5bb7013: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xf5013
0x5bb760a: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xf560a
0x5af6aa7: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0x34aa7
0x8073bc4: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x2bbc4
std::allocator<desktop::DispatchWatcher::DispatchRequest> > const&) + 0xf6a)
0x806d4b9: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x254b9
+ 0x123)
0x8062c3f: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1ac3f
(desktop::Desktop::OpenDefault() + 0x25f)
0x8063cf8: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1bcf8
(desktop::Desktop::OpenClients() + 0x43c)
0x8067b23: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1fb23
(desktop::Desktop::OpenClients_Impl(void*) + 0x25)
0xaf3736: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x7a736
0xc6bcd3: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x1f2cd3
0x60960f4: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x1f0f4
0x60be543: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x47543
(SalDisplay::DispatchInternalEvent() + 0xad)
0x66110b7: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xb0b7
0x6493de0: /usr/lib/libglib-2.0.so.0 + 0x26de0
0x6491b7e: /usr/lib/libglib-2.0.so.0 + 0x24b7e (g_main_context_dispatch + 0x1dc)
0x6494b86: /usr/lib/libglib-2.0.so.0 + 0x27b86
0x6495068: /usr/lib/libglib-2.0.so.0 + 0x28068 (g_main_context_iteration + 0x66)
0x6610ce9: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xace9
0x60c1871: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x4a871
(X11SalInstance::Yield(unsigned char) + 0x29)
0xaf9acc: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x80acc
(Application::Yield() + 0x50)
0xaf9b0a: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x80b0a
(Application::Execute() + 0x26)
0x806790d: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1f90d
(desktop::Desktop::Main() + 0x14a1)
0xaff201: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x86201 (SVMain()
+ 0x45)
0x80625eb: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1a5eb (sal_main +
0x6271f2f: /lib/libc.so.6 + 0x14f2f (__libc_start_main + 0xdf)
0x8062521: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1a521
(Window::RequestHelp(HelpEvent const&) + 0x31)
---end copy and paste here---
paste the above into your bug report
Comment 2 Caolan McNamara 2005-07-12 03:15:08 EDT
*** Bug 162959 has been marked as a duplicate of this bug. ***
Comment 3 Caolan McNamara 2005-07-12 09:06:07 EDT
caolanm->jakub: it's a crash in the dtor of a vector, I'd suspect programmer
error, but for the life of me it looks like perfectly fine code. Any known
errors in libstdc++ allocators/deallocators ?

#0  0x00d98dab in __gnu_cxx::__pool<true>::_M_reclaim_block ()
   from /usr/lib/libstdc++.so.6
#1  0x02f34841 in __gnu_cxx::__mt_alloc<sd::TemplateEntry*,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate
    __p=0x36b9da8, __n=2)
#2  0x02f3487b in std::_Vector_base<sd::TemplateEntry*,
std::allocator<sd::TemplateEntry*> >::_M_deallocate (this=0x36b4b40,
__p=0x36b9da8, __n=2)
#3  0x02f348c5 in ~_Vector_base (this=0x36b4b40)
#4  0x02f3495f in ~vector (this=0x36b4b40)
#5  0x02f34985 in ~TemplateDir (this=0x36b4b38)
    at ../inc/TemplateScanner.hxx:119
#6  0x02f258ec in ~AssistentDlgImpl (this=0x2e624e8)
    at /usr/src/redhat/BUILD/SRC680_m116/sd/source/ui/dlg/dlgass.cxx:806
#7  0x02f21c80 in ~AssistentDlg (this=0x2e55768)
    at /usr/src/redhat/BUILD/SRC680_m116/sd/source/ui/dlg/dlgass.cxx:1996
#8  0x02f1872d in ~AbstractAssistentDlg_Impl (this=0x2373438)
    at /usr/src/redhat/BUILD/SRC680_m116/sd/source/ui/dlg/sddlgfact.cxx:130
#9  0xb48a159b in SdModule::Execute (this=0x2e24248, rReq=@0xbf8ce740)
    at /usr/src/redhat/BUILD/SRC680_m116/sd/source/ui/app/sdmod1.cxx:459
#10 0xb489f2ae in SfxStubSdModuleExecute (pShell=0x2e24248, rReq=@0xbf8ce740)
    at ../../../unxlngi6.pro/inc/sdslots.hxx:659
#11 0x029c4bb6 in SfxShell::CallExec (this=0x2e24248,
    pFunc=0xb489f294 <SfxStubSdModuleExecute(SfxShell*, SfxRequest&)>,
    rReq=@0xbf8ce740) at ../../inc/shell.hxx:258
#12 0x029ca5d7 in SfxShell::ExecuteSlot (this=0x2e24248, rReq=@0xbf8ce740,
    at /usr/src/redhat/BUILD/SRC680_m116/sfx2/source/control/shell.cxx:1231
#13 0xb49ad466 in SdUnoModule::dispatchWithNotification (this=0x2e32510,
    aURL=@0xbf8ce7b0, aArgs=@0xbf8ce808, xListener=@0x8)
    at /usr/src/redhat/BUILD/SRC680_m116/sd/source/ui/unoidl/unomodule.cxx:124
#14 0x0312197a in framework::DispatchHelper::executeDispatch (this=0x2df7940,
    xDispatchProvider=@0xbf8cebc4, sURL=@0xbf8cebc0,
    sTargetFrameName=@0xbf8cec34, nSearchFlags=0, lArguments=@0xbf8cebd0)
#15 0x028cfda6 in SfxApplication::OfaExec_Impl (this=0x1880e20,
    at /usr/src/redhat/BUILD/SRC680_m116/sfx2/source/appl/appserv.cxx:1188
Comment 4 Caolan McNamara 2005-07-12 09:09:20 EDT

==32594== Thread 1:
==32594== Invalid read of size 2
==32594==    at 0xB88DAB: __gnu_cxx::__pool<true>::_M_reclaim_block(char*,
unsigned) (in /usr/lib/libstdc++.so.6.0.5)
==32594==    by 0x23DAA840: __gnu_cxx::__mt_alloc<sd::TemplateEntry*,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>::deallocate(sd::TemplateEntry**, unsigned) (mt_allocator.h:746)
==32594==    by 0x23DAA87A: std::_Vector_base<sd::TemplateEntry*,
std::allocator<sd::TemplateEntry*> >::_M_deallocate(sd::TemplateEntry**,
unsigned) (stl_vector.h:123)
==32594==    by 0x23DAA8C4: std::_Vector_base<sd::TemplateEntry*,
std::allocator<sd::TemplateEntry*> >::~_Vector_base() (stl_vector.h:109)
==32594==    by 0x23DAA95E: std::vector<sd::TemplateEntry*,
std::allocator<sd::TemplateEntry*> >::~vector() (stl_vector.h:273)
==32594==    by 0x23DAA984: sd::TemplateDir::~TemplateDir()
==32594==    by 0x23D9B8EB: AssistentDlgImpl::~AssistentDlgImpl() (dlgass.cxx:806)
==32594==    by 0x23D97C7F: AssistentDlg::~AssistentDlg() (dlgass.cxx:1996)
==32594==    by 0x23D8E72C:
AbstractAssistentDlg_Impl::~AbstractAssistentDlg_Impl() (sddlgfact.cxx:130)
==32594==    by 0x229CB59A: SdModule::Execute(SfxRequest&) (sdmod1.cxx:459)
==32594==    by 0x229C92AD: SfxStubSdModuleExecute(SfxShell*, SfxRequest&)
==32594==    by 0x207ABBB5: SfxShell::CallExec(void (*)(SfxShell*, SfxRequest&),
SfxRequest&) (shell.hxx:258)
==32594==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
Comment 5 Jakub Jelinek 2005-07-12 09:15:56 EDT
The only known bug (at least to me) of the mt allocator is a crash when
you dlclose libstdc++ and afterwards terminate some thread.  You can install
gcc-debuginfo to see where in _M_reclaim_block this is crashing.  Either it could
be a memory management bug in the application (as soon as control structures
of the allocator are overwritten, it is likely the allocator will be upset about
that), or it can be a mt allocator bug.
Comment 6 Caolan McNamara 2005-07-12 09:27:50 EDT
Created attachment 116653 [details]
got a workaround anyway

hmm, half an half-assed workaround anyway... logically the same but doesn't

The initial vector is new'ed from a different shared lib to which it's deleted,
maybe that's relevent
Comment 7 Jakub Jelinek 2005-07-12 10:19:29 EDT
new'ing in one DSO and deleting in another one certainly should work just fine
and I don't see how mt allocator would care about that, unless the libraries
are using a different allocator.
What library is the allocation happening in and what library frees it?
Do those libraries have any _Z*N9__gnu_cxx20__common_pool_policy* symbols
hidden via a version script?
Comment 8 Caolan McNamara 2005-07-13 15:00:39 EDT
yeah, but without using them, or with disabling the visibility suppose it still
fails. It's a headscratcher, the only thing is that I only recently began using
the g++ stl instead of OOo's stlport copy like everyone else does. I think I'll
revert to stlport for a while and dig into this seperately from the user problem.
Comment 9 Caolan McNamara 2005-07-14 05:25:12 EDT
Created attachment 116739 [details]
reproducable testcase

seems to be because of the visibility stuff, have a small test case attached

->jakub: should my testcase run ?
Comment 10 Caolan McNamara 2005-07-14 07:44:10 EDT
workaround in OOo 1.9.117-1, testcase submitted as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22482 for the usual humiliation
where the obvious will be pointed out to me :-)

Note You need to log in before you can comment on or make changes to this bug.