Bug 105452

Summary:	Acroread crashes
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Tobias Burnus <burnus>
Component:	X11 Applications	Assignee:	George Horlacher <ghorlacher>
Status:	RESOLVED FIXED	QA Contact:	Stefan Dirsch <sndirsch>
Severity:	Normal
Priority:	P5 - None	CC:	sndirsch
Version:	Beta 2
Target Milestone:	---
Hardware:	Other
OS:	All
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Tobias Burnus 2005-08-18 10:33:00 UTC

I'm not sure whether I'm here at the right component. Anyway:

Both the SL 9.3 (via YOU i.e. acroread-7.0.0-4.4.i586.rpm) shipped acroread.rpm
as well as the Adobe distributed AdobeReader_enu-7.0.1-1.i386.rpm crash on 10.0b2.

Using AdobeReader_enu-7.0.1-1.i386.rpm with:

PSRESOURCEPATH=$HOME/psres:$HOME/fonts:/usr/psres::
ACRO_INSTALL_DIR=/usr/local/Adobe/Acrobat7.0/Reader
ACRO_RES_DIR=/usr/local/Adobe/Acrobat7.0/Reader/../Resource
ACRO_CONFIG=intellinux
ACRO_EXEC_CMD=/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread
LD_LIBRARY_PATH=/usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib:/usr/local/Adobe/Acrobat7.0/Reader/intellinux/sidecars
ACRO_ARG0=/usr/bin/acroread ACRO_AT_ACTIVE=false
/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread

I cannot see anything useful.

Expected: They simply run.
I will try to find out more why they crash. gdb only shows:

[Thread debugging using libthread_db enabled]
[New Thread 1093428448 (LWP 24015)]
---Type <return> to continue, or q <return> to quit---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1093428448 (LWP 24015)]
0x08a33396 in std::locale::operator= ()

Comment 1 Stefan Dirsch 2005-08-18 10:37:08 UTC

Possibly related to scim. Please try

  GTK_IM_MODULE=xim acroread

What's the output of

  echo $GTK_IM_MODULE

Comment 2 Tobias Burnus 2005-08-18 10:47:14 UTC

Gratulation: You have won the washing machine!

  GTK_IM_MODULE=xim acroread
Works!

  echo $GTK_IM_MODULE
scim

(I start to dislike scim: In 9.3 it blocked any input in Tk, in 10.0 special
input in Tk is still not possible & acroread crashes :-( Somehow it is not yet
completely mature.)

Comment 3 Stefan Dirsch 2005-08-18 12:09:34 UTC

This problem will be fixed for Beta3.

Comment 4 Mike Fabian 2005-08-18 12:18:44 UTC

Tobias> (I start to dislike scim: In 9.3 it blocked any input in Tk, in 10.0
Tobias> special input in Tk is still not possible & acroread crashes :-(
Tobias> Somehow it is not yet completely mature.)

Both is not the fault of scim.

By the way, the Tk problem still exists!  But the Tk problem is
clearly a Tk bug, the XIM support in Tk is *very* broken, even with
kinput2 it works only partly.  As a workaround you can use

     XMODIFIERS=@im=local tk-application

when starting a tk application. 

The acroread problem occurs because acroread is a binary only
commercial software which has been compiled against an older version
of libstdc++. scim of course is compiled against the current version
of libstdc++. When scim is loaded as a plugin by Acroread, different
versions of libstdc++ are used in the same binary which causes the
problems. The best fix would be to recompile acroread against a
current version of libstdc++, but this impossible because we do not
have the sources.

For the gory details of the acroread problem see bug #85416.  See
comment #40 in that bug, I have submitted the "export
GTK_IM_MODULE=xim" workaround in the startscript for Beta3.