Fix gqi dep build (crash on startup)

RESOLVED FIXED

Status

()

RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: hidenosuke, Assigned: jag+mozilla)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
Firefox crashes at loading first page on start up.

I created debug build and ran it on GDB.

Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0xb63eb4ad in XULContentSinkImpl::OpenScript (this=0xb716f734, 
    aAttributes=0xb7dc45dc, aLineNumber=5)
    at /home/hideo/develop/mozilla/content/xul/document/src/nsXULContentSink.cpp:1094
1094	                                               value);

2008020215(JST) build didn't have this problem.

Comment 1

11 years ago
fallout from bug 414894 ?
(Reporter)

Comment 2

11 years ago
(In reply to comment #1)
> fallout from bug 414894 ?

Thanks for your information.
 
I tried to build without the patch of bug 414894
and cannot see this problem.

Comment 3

11 years ago
are they your own builds, or nightlies?

if they're your own, can you try clobbering your objdir, rebuilding, and testing?
(Reporter)

Comment 4

11 years ago
(In reply to comment #3)
> are they your own builds, or nightlies?

My own build.
2008020305-nightly trunk build doesn't have this problem.
 
> if they're your own, can you try clobbering your objdir, rebuilding, and
> testing?
 
I tried 'make distclean' and rebuild but the problem still occurs.
Component: General → General
Product: Firefox → Core
QA Contact: general → general

Comment 5

11 years ago
(In reply to comment #4)
> I tried 'make distclean' and rebuild but the problem still occurs.

can you try again with |rm -rf objdir|? there might be problems with the dependencies relating to gqi (see https://bugzilla.mozilla.org/show_bug.cgi?id=412320#c61), so i wouldn't trust anything less than a complete clobber here.

the fact that today's nightly works, would seem to support this, but you never know :)
(Reporter)

Comment 6

11 years ago
(In reply to comment #5)
> (In reply to comment #4)
> > I tried 'make distclean' and rebuild but the problem still occurs.
> 
> can you try again with |rm -rf objdir|? there might be problems with the
> dependencies relating to gqi (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=412320#c61), so i wouldn't trust
> anything less than a complete clobber here.

You are right.
I tried rm -rf objdir and rebuild.
I cannot reproduce the problem any more.
Thanks for your advice.

Comment 7

11 years ago
ok, thanks. hopefully this won't be a problem anymore once the dependency problem in bug 412320 gets fixed.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
Duplicate of this bug: 415435

Comment 9

11 years ago
let's reopen this to get some dependency fixes in for gqi.
Blocks: 412320
Status: RESOLVED → REOPENED
Component: General → XPCOM
OS: Linux → All
Hardware: PC → All
Resolution: INVALID → ---
Summary: Crash at loading first page. → Fix gqi dep build (crash on startup)
Version: unspecified → Trunk

Updated

11 years ago
Status: REOPENED → NEW
QA Contact: general → xpcom

Updated

11 years ago
Duplicate of this bug: 415740
(Assignee)

Comment 11

11 years ago
mddepend.pl chokes on \r on continuation lines. Easy fix, patch coming up.
Assignee: nobody → jag
(Assignee)

Comment 12

11 years ago
Created attachment 301840 [details] [diff] [review]
Also chop \r for continuation lines, skip lines that don't match the expected "source: dependency" pattern.

So gcc on Windows puts "# DO NOT DELETE" at the top of the .pp files it generates (hence the $rest eq '' check), and the format doesn't use continuations, just "source: dependency", one line for each dependency. Oh, and the file seems to use unix style line endings. It's the combination of dos style line endings and continuations that triggers the bug in mddepend.pl.
(Assignee)

Updated

11 years ago
Attachment #301840 - Flags: review?(ted.mielczarek)
Comment on attachment 301840 [details] [diff] [review]
Also chop \r for continuation lines, skip lines that don't match the expected "source: dependency" pattern.

+    # Remove extra ^M caused by using dos-mode line-endings
+    chop $line if (substr($line, -1, 1) eq "\r");

Would just |chomp $line;| work here?  (I'm getting rusty in my Perl...)
Attachment #301840 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 14

11 years ago
Created attachment 301882 [details] [diff] [review]
I think I like this better.
Attachment #301840 - Attachment is obsolete: true
Attachment #301882 - Flags: review?
(Assignee)

Updated

11 years ago
Attachment #301882 - Flags: review? → review?(ted.mielczarek)
(Assignee)

Comment 15

11 years ago
So yeah, in theory chomp should work, and I'm not quite sure why it isn't for some people. I wonder if that depends on what line-ending mode they have selected for their cygwin / msys / ??? install.
(Assignee)

Comment 16

11 years ago
Right, so what I completely left out in comment 12 is that the depend files generated by gqi.py write out with \r\n on Windows, using continuations (\ at end of line), which is what confuses mddepend.pl on Windows on certain installs (msys, at least).
Comment on attachment 301882 [details] [diff] [review]
I think I like this better.

Fine with me.
Attachment #301882 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 18

11 years ago
Comment on attachment 301882 [details] [diff] [review]
I think I like this better.

This makes it so we update bQI.cpp when a.gqi (imported from b.gqi) is touched.
Attachment #301882 - Flags: approval1.9?
Comment on attachment 301882 [details] [diff] [review]
I think I like this better.

a1.9+=damons
Attachment #301882 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 20

11 years ago
Checking in mddepend.pl;
/cvsroot/mozilla/build/unix/mddepend.pl,v  <--  mddepend.pl
new revision: 1.10; previous revision: 1.9
done
Status: NEW → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.