gtk2 build segfaults on startup. rc1 source tree



17 years ago
12 years ago


(Reporter: dave, Assigned: blizzard)




Firefox Tracking Flags

(Not tracked)




(4 attachments)



17 years ago
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

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/ 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

17 years ago
Created attachment 80179 [details]
gdb stack traces

contains two stack traces
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

17 years ago
Created attachment 80180 [details]
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 to enable the changes

Comment 4

17 years ago
Created attachment 80181 [details]
details for configure options and xserver settings

Comment 5

17 years ago
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
unsupported libs, so invalid...?

Comment 7

17 years ago

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,



17 years ago
Keywords: crash
-> Build Config (?)
Assignee: Matti → seawood
Component: Browser-General → Build Config
QA Contact: imajes-qa → granrose

   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'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

Assignee: seawood → blizzard
Summary: Segmentation fault upon startup of self compiled rc1 source tree → gtk2 build segfaults on startup. rc1 source tree

Comment 10

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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.
Ever confirmed: true

Comment 14

16 years ago
Created attachment 131737 [details]
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
David, is this still an issue?
Not a blocker.
Severity: blocker → critical

Comment 16

16 years ago
This has been working for a long time, as least in the context of when this was
filed.  Marking WORKSFORME.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.