Closed Bug 415422 Opened 12 years ago Closed 12 years ago

Fix gqi dep build (crash on startup)

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: hidenosuke, Assigned: jag+mozilla)

References

Details

(Keywords: crash)

Attachments

(1 file, 1 obsolete file)

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.
fallout from bug 414894 ?
(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.
are they your own builds, or nightlies?

if they're your own, can you try clobbering your objdir, rebuilding, and testing?
(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.
Product: Firefox → Core
QA Contact: general → general
(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 :)
(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.
ok, thanks. hopefully this won't be a problem anymore once the dependency problem in bug 412320 gets fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Duplicate of this bug: 415435
let's reopen this to get some dependency fixes in for gqi.
Blocks: gqi
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
Status: REOPENED → NEW
QA Contact: general → xpcom
Duplicate of this bug: 415740
mddepend.pl chokes on \r on continuation lines. Easy fix, patch coming up.
Assignee: nobody → jag
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.
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+
Attachment #301840 - Attachment is obsolete: true
Attachment #301882 - Flags: review?
Attachment #301882 - Flags: review? → review?(ted.mielczarek)
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.
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+
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+
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
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.