138766 - gtk2 build segfaults on startup. rc1 source tree

Status: RESOLVED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[David Flynn]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
BuildID:    rc1

Compiled the mozilla rc1 source tree [see aditional info], changed into
dist/bin, exported LD_LIBRARY_PATH=/path/to/dist/bin, ./mozilla

Reproducible: Always
Steps to Reproduce:
1. changed into dist/bin
2. exported LD_LIBRARY_PATH=/path/to/dist/bin
3../mozilla

Actual Results:  davidf@svr0:/home/davidf/diskless/mozilla/dist/bin$ ./mozilla
Type Manifest File: /home/davidf/diskless/mozilla/dist/bin/compentents/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
warning: property cp1256 already exists
/home/davidf/diskless/mozilla/dist/bin/run-mozilla.sh: line 72: 29669
Segmentation fault     $prog ${1+"@"}

Expected Results:  started

I had to kludgen the configure script slightly in order to configure correctly.
  For i use autoconf 2.5; and glib-2 and gtk+2 and even though you have the
option for using pkg-config for gtk+2 it is not there for glib-2 (which gtk2 is
dependant on); however the changes were trivial[please see attatched].

Also enclosed are gdb stack traces and other potentially relevant information.

Note, the mozilla-viewer works with no problems

Comment 1

[David Flynn]

Attachment: gdb stack traces

contains two stack traces

Comment 2

[Bradley Baetz (:bbaetz)]

autoconf 2.5 is not supported, and gtk2 is experimental, at best

Its segfaulting in what should ammount to fprintf, which is very odd. Can you
try this with autoconf2.13?

Comment 3

[David Flynn]

Attachment: diff file on configure script to enable use of pkg-config for glib2

this patch is for reference only, it shows what i had to change in the actual
configure script as due to only having autoconf 2.5 i could not alter
configure.in to enable the changes

Comment 4

[David Flynn]

Attachment: details for configure options and xserver settings

Comment 5

[David Flynn]

Okay, i have just been grepping through the source for LOG, and found:

./widget/src/gtk2/nsCommonWidget.h:54:#define LOG(args) PR_LOG(gWidgetLog, 4, args)

Going back to the core dumps, in the bottom most frame:

(gdb) print gWidgetLog
$1 = (PRLogModuleInfo *) 0x0

which would nicely explain the sigsegv in fprintf

Comment 6

[Kai Lahmann (is there, where MNG is)]

unsupported libs, so invalid...?

Comment 7

[David Flynn]

Kai,

How dare you have the audacity to say "invalid"; The code base to use gtk2+ is
included in part of the mozilla source tree, so unsupported in terms of code,
definitley not; unsupported in that it is not maintainted, or users given
support there of, possibly.

Taking the bigoted view and saying that the bug report is invalid is ridiculous.
 The bug report was submitted for two reasons: 1) so that it was made aware that
there is a problem, 2) that it could possibly be fixed.

I have done some poking to find that for some reason the file handle is never
created, thus causing fprintf to cause a segmentation fault.  I have also foud
out that there is a mistake in one of the header files, for when one dissables
logging, compile errors exist for the unrsolved symbol of the file handle.  This
is a trivial fix.

However what i have not yet investigated is why the file handle is not being
created. nor is there any checking that it was created.  Call me old fashioned,
but wenever one allocates something, it is good and proper check that what you
wanted to happen actually happened, hence:

int fd = open(...);
if (!fd)
{ error condition, either dissable feature, or REPORT the error }

Now as for a useful way forward, i shall do some investigation, however if
anyone has any suggestions, or knows this code, then please speak up!

Many Thanks,

Dave

Comment 8

[Matthias Versen [:Matti]]

-> Build Config (?)

Comment 9

[hacker formerly known as [e-mail]]

Blizzard, 

   So it's bugs like this one and bug 140628 that make we want to rip those
build options out of the tree and go on a rampage in GTA3.

> The code base to use gtk2+ is
> included in part of the mozilla source tree, so unsupported in terms of code,
> definitley not; unsupported in that it is not maintainted, or users given
> support there of, possibly.

Given that an guestimated 90% of the developer base is building and testing
against gtk only, gtk2 (xlib & qt for that matter) is for all intents and
purposes unsupported.  I can see how an user could get irate when they told that
this build option, which is listed in the configure --help output, is
unsupported.  However, Kai is correct.  As far as what is being shipped and what
is being tested, a gtk2-based build isn't on the majority of the development
teams' list and is therefore, unsupported by majority rule and mozilla.org's
decision to use gtk or however you decide to term it.

Having build options and choices are good, however, they need to tested and
maintained by someone if you're going to let the public see them.  Otherwise,
make it a hidden maintainer option to be triggered by env variables instead of
configure options.  Get a tinderbox up at the minimum.

gtk2 --> blizzard

Comment 10

[Christopher Blizzard (:blizzard)]

Can we just mark it as "EXPIREMENTAL" in the configure help output?  That might
be enough.

By the way, I don't expect that RC1 will work with gtk2.  Works on the tip but I
have zero interest in backporting anything to the 1.0 tree at this point.

Comment 11

[David Flynn]

It works wonderfully with glib2 and gtk2.

I have no problem with it not being supported by the developers by and large,
nor have I an issue with that.

I will create a patch and find out why the particular area i was having problems
with was broken, however if there are other plans, then there may be little need.

I also agree on saying that it is EXPERIMENTAL

Comment 12

[alge]

anyway, this can't possibly be a blocker bug? if rc1 won't have gtk2, rc1 won't
have gtk2. sounds more like a trivial bug to me, or WONTFIX

Comment 13

[Azrael AOD]

if this is indeed a bug then it should be at least moved to new. Whether or not
it is a wontfix is another issue. Marking 'new' to get it out of unconfirmed..
doesn't belong there.

Comment 14

[Bjoern Voigt]

Attachment: GTK2-Crash "assertion `GDK_IS_SCREEN (screen)' failed"

My Mozilla-1.5RC1 (cvs MOZILLA_1_5_BRANCH from Sep 19 2003) crashes on startup.
It seems to be an other error than the already reported ones. 

My System:
- gcc 3.3.1
- GNOME 2.4: gtk+ 2.2.4, glib-2.2.3
- Mozilla 1.5-branch
- Linux 2.4

Comment 15

[Simon Paquet [:sipaq]]

David, is this still an issue?
Not a blocker.

Comment 16

[Christopher Blizzard (:blizzard)]

This has been working for a long time, as least in the context of when this was
filed.  Marking WORKSFORME.