Bug 214904 - "Avert a fatal crash" message appears
"Avert a fatal crash" message appears
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
6
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Caolan McNamara
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-09 17:07 EST by Vlado Potisk
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.0.4-5.5.10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-22 05:22:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vlado Potisk 2006-11-09 17:07:23 EST
Description of problem:
The mentioned message is displayed without any additional info.

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

How reproducible:
Always

Steps to Reproduce:
1.from a terminal start  oowriter somefile.odt  or  oocalc somefile.ods
2.exit the application
  
Actual results:
"Avert a fatal crash" message is displayed on the terminal screen

Expected results:
There should be no imminent fatal crash to avert.

Additional info:
I'm setting the severity to low, because there seems to be no real impact.
Comment 1 Caolan McNamara 2006-11-10 04:17:37 EST
Indeed, I added this and a workaround for a problem where apparently static
class data isn't being fully initialized. i.e. the last member of ...

    template< typename Ifc1, typename Ifc2, typename Ifc3, typename Ifc4,
typename Ifc5, typename Ifc6, typename Ifc7, typename Ifc8, typename Impl >
    struct ImplClassData8
    {
        class_data* operator ()()
        {
            static class_data8 s_cd =
            {
                8 +1, sal_False, sal_False,
                { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
                {
                    { { Ifc1::static_type }, ((sal_IntPtr)(Ifc1 *) (Impl *) 16)
- 16 },
                    { { Ifc2::static_type }, ((sal_IntPtr)(Ifc2 *) (Impl *) 16)
- 16 },
                    { { Ifc3::static_type }, ((sal_IntPtr)(Ifc3 *) (Impl *) 16)
- 16 },
                    { { Ifc4::static_type }, ((sal_IntPtr)(Ifc4 *) (Impl *) 16)
- 16 },
                    { { Ifc5::static_type }, ((sal_IntPtr)(Ifc5 *) (Impl *) 16)
- 16 },
                    { { Ifc6::static_type }, ((sal_IntPtr)(Ifc6 *) (Impl *) 16)
- 16 },
                    { { Ifc7::static_type }, ((sal_IntPtr)(Ifc7 *) (Impl *) 16)
- 16 },
                    { { Ifc8::static_type }, ((sal_IntPtr)(Ifc8 *) (Impl *) 16)
- 16 },
                    { { ::com::sun::star::lang::XTypeProvider::static_type },
((sal_IntPtr)(::com::sun::star::lang::XTypeProvider *) (Impl *) 16) - 16 }
                }
            };
            return class_data_fixup<Impl>(reinterpret_cast< class_data * >(&s_cd));
        }
    };

the static_type field isn't getting initialized. I need to create a standalone
test case to run by gcc, but I haven't been able to nail it down yet.
Comment 2 Caolan McNamara 2006-11-24 11:19:52 EST
I suspect http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00563.html in which case
adjusting the visibility to be "default" of the inline method which contains the
local static might clear it, a test build required...
Comment 3 Caolan McNamara 2007-01-22 05:22:12 EST
silenced in last fc-6 update

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