87582 - Xlib-toolkit Mozilla crashes while printing via Xprint

Status: VERIFIED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[Roland Mainz]

Xlib-toolkit Mozilla5 crashes while printing via Xprint module due shared use of
xlibrgb.so - two modules are overwriting global variables in that module...

Sharing xlibrgb.so between two modules is currently not possible as it has
global variables which cannot be shared between two modules (bug 85527 ("Turn
xlibrgb into a shared library") will fix that by introducing a new API which
uses a "handle" to reference these global variables - this allows to share the
xlibrgb.so library by using different handles for different ${DISPLAY}s ...).

Comment 1

[Roland Mainz]

Swapping QA<-->bug owner...

Comment 2

[Roland Mainz]

Accepting bug...

Comment 3

[Roland Mainz]

Attachment: Patch for 2001-06-24-08-trunk

Comment 4

[Roland Mainz]

Attached patch for mozilla/gfx/src/xprint/Makefile.in - this patch solves this
issue and adds a warning (for _me_) to that file to avoid that mistake a 3rd
time...

Requesting r=[e-mail]

Comment 5

[cls]

r=cls

Comment 6

[Roland Mainz]

CC:'ing mkaply for checkin into tree...

Comment 7

[Mike Kaply [:mkaply]]

Fix checked in

Comment 8

[Mike Kaply [:mkaply]]

No really, I checked it in.

Comment 9

[Mike Kaply [:mkaply]]

This broke on HPUX. Here is the error:

aCC -ext +p +DA1.1 +DS2.0    -DNDEBUG -DTRIMMED -I/opt/gtk+/include 
-I/opt/glib/lib/glib/include -I/opt/glib/include -I/usr/include/X11R6 -b -Wl,+s 
-L../../../dist/bin -o libgfxxprint.sl  xlibrgb.o xprintutil.o 
xprintutil_printtofile.o nsDeviceContextXP.o nsFontMetricsXlib.o 
nsRenderingContextXP.o nsGfxFactoryXP.o nsXPrintContext.o nsRegionXlib.o 
nsGCCache.o    -lXp -lXext -lX11 -L../../../dist/bin -lxpcom -L../../../dist/bin 
-L/builds/tinderbox/SeaMonkey/HP-UX_B.10.20_Clobber/mozilla/dist/lib -lplds4 
-lplc4 -lnspr4    -Wl,-Bsymbolic -L../../../dist/bin -L../../../dist/lib -lgkgfx 
-L../../../dist/bin -lxpcom -L../../../dist/bin 
-L/builds/tinderbox/SeaMonkey/HP-UX_B.10.20_Clobber/mozilla/dist/lib -lplds4 
-lplc4 -lnspr4   -lm -lc_r    
aCC: error 1913: `xlibrgb.o' does not exist or cannot be read

Comment 10

[Roland Mainz]

OK... I do not understand this. Why does every platform except HP-UX find that
xlibrgb.o ??

CC:'ing jdunn as the HP-UX guru - and as a _cry_ for help...

Comment 11

[Jim Dunn]

You use VPATH for xlibrgb, and in config/rules.mk they mention
that VPATH doesn't work on all platforms.  I am looking now
but can't figure out why HP doesn't like it.  If I find anything 
I will let u know

Comment 12

[Jim Dunn]

oops ignore that last comment.  I am looking at this

Comment 13

[Jim Dunn]

Ok, I still don't fully understand what is going on, but maybe
one of you will.

When we make, we go into xlibrgb and xlibrgb.o is created.
We then go into xprint and based on VPATH we check to see
if xlibrgb.o is up to date... since it was just built in
../xlibrgb it is so we don't rebuild it.  We then go to link
and aCC can't find xlibrgb.o because it wasn't made in ./

Now if you delete ../xlibrgb/xlibrgb.o and do a gmake in xprint
xlibrgb.o is NOT up to date, it rebuilds xlibrgb but it does
it in the xprint directory and then the lib is linked correctly.

So that is it in a nutshell but don't ask me why it isn't
doing what you guys want it to do.

Comment 14

[Roland Mainz]

jdunn wrote:
> We then go into xprint and based on VPATH we check to see
> if xlibrgb.o is up to date... since it was just built in
> ../xlibrgb it is so we don't rebuild it

Ohh... yes... BING!! :-)
This is the problem. It should never gmake in xlibrgb/ unless Xprint uses
xlibrgb.so (e.g. xlibrgb shared library). Very tricky... ;-(

cls - do you have any idea how to avoid that gmake looks into the "wrong" (e.g.
xlibrgb/) dir instead of the "right" (xprint/) dir for *.o files ?

Comment 15

[Roland Mainz]

Attachment: Better patch for 2001-06-25-08-trunk

Comment 16

[Roland Mainz]

Attached a new patch. This time I am using ../xlibrgb/xlibrgb.c instead of
xlibrgb.c+VPATH
This is only a workaround until bug 85527 get's implemented or someone finds a
solution for this linker-picks-wrong-*.o-file-via-VPATH-issue...

Requesting r=cls or r=jdunn

Comment 17

[Jim Dunn]

This works for me (on hpux)... r=[e-mail]

The only thing I am going to ask (cuz I don't know) is,
should xprint/Makefile.in be something like...
CSRCS =\
          $(srcdir)/../xlibrgb/xlibrgb.c \
          ^^^^^^^^^^

Probably not, but just thought I would ask

Comment 18

[cls]

sr=cls for lack of a better alternative.  I still don't like the patch and I
think  that xlib's use of global symbols needs to be fixed independent of
becoming a shared lib.

jdunn,  the additional $(srcdir) is not necessary (and can cause problems) as
it's really the OBJS that we care about (CSRCS with a .o suffix) and the .o will
always be relative to the current build directory. 

Comment 19

[Roland Mainz]

cls:
Thanks !!

I agree with you - this is a hack until I'll "land" a better solution for this
issue. This is the next item on my list after I am "done" with MathML-support in
Xlib-toolkit/Xprint(=soon, ~~ next week)...

Comment 20

[Mike Kaply [:mkaply]]

OK fix is in again

Comment 21

[Masaki Katakai]

I've succeeded to build Mozilla with xlib...
Verified today.