Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 227245

Summary: [a11y] segfaults on exit in at-spi atexit
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mclasen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: 2.2.0-5.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-02-06 11:09:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
OOo bandaid none

Description Michal Jaegermann 2007-02-03 22:12:26 UTC
Description of problem:

Running in a terminal window one gets:
/usr/lib64/ line 222: 23556 Segmentation fault
which happens every time when program exits.

I did not check what happens if exiting the program exits with anything
but an empty writer window; the above was "open-and-exit".

To see this with more detail one can try:
$ sh -x /usr/lib64/ -writer
+ '[' -z ']'
+ export SAL_USE_VCLPLUGIN=gtk
++ uname -s
+ sd_platform=Linux
++ uname -m
+ '[' Linux = Linux -a x86_64 = ppc ']'
++ pwd
+ sd_cwd=/root
+ '[' -h /usr/lib64/ ']'
++ dirname /usr/lib64/
+ cd /usr/lib64/
++ pwd
+ sd_prog=/usr/lib64/
+ cd ..
++ basename /usr/lib64/
+ sd_binary=soffice.bin
++ pwd
+ sd_inst=/usr/lib64/
+ cd /root
+ case $sd_platform in
+ '[' ']'
+ LD_LIBRARY_PATH=/usr/lib64/
+ for arg in '$@'
+ case "$arg" in
+ '[' -x /usr/lib64/ ']'
++ /usr/lib64/
+ java_ld_library_path=
+ '[' '' '!=' '' ']'
+ for sd_arg in '${1+"$@"}'
+ case ${sd_arg} in
+ sd_binary=swriter.bin
+ break
+ '['
+ export PATH
+ /usr/lib64/ -writer
+ trap 'kill -9 $!' TERM
+ wait 23556
GTK Accessibility Module initialized
libGL warning: 3D driver claims to not support visual 0x4b
GTK Accessibility Module shutdown
/usr/lib64/ line 222: 23556 Segmentation fault  
 "$sd_prog/$sd_binary" "$@"
+ '[' 139 -eq 79 ']'
+ exit

The above does not dump core even if 'ulimit' for the account sets
core size to unlimited.

With a script modified to run binaries under gdb this is not much more

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496327472 (LWP 23841)]
0x00002aaaaaf0225e in main ()
   from /usr/lib64/
(gdb) where
#0  0x00002aaaaaf0225e in main ()
   from /usr/lib64/
(gdb) c

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q

I have no idea of a 32-bit version does the same or not.

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

How reproducible:

Comment 1 Caolan McNamara 2007-02-05 12:01:01 UTC
This is triggered by an at-spi change where there are some glib thread stuff is
now called in an atexit function. OOo has overridden the g_thread lock functions
and OOo tried to shutdown a11y before shutting down it's gtk vcl plugin which
destroys stuff which the g_thread_lock overrides requires but OOo can't cancel
the execution of the registered at-spi atexit which will try and use the thread
lockers. I can hack around this in the thread lockers to check to see if their
requirements have disappeared when they get called after the fact in the at-spi
shutdown but it's ugly.

caolanm->mclasen: I suspect you'll begin seeing upstream bugreports about
vanilla OOo crashing against the newer at-spis.

Comment 2 Caolan McNamara 2007-02-05 12:03:27 UTC
Created attachment 147348 [details]
OOo bandaid

Comment 3 Matthias Clasen 2007-02-05 13:47:33 UTC
the atexit function in atk-bridge/bridge.c has the following comment:

   *  FIXME: this may be incorrect for apps that do their own bonobo
   *  shutdown, until we can explicitly shutdown to get the ordering
   *  right.

So at least there is some awareness of ordering issues. Did you file
an upstream bug for this ?

Comment 4 Caolan McNamara 2007-02-05 14:06:12 UTC
logged as

Comment 5 Caolan McNamara 2007-02-06 11:09:02 UTC
Should be a non-crasher in