415422 - Fix gqi dep build (crash on startup)

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Hideo Oshima]

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

[Jo Hermans]

fallout from bug 414894 ?

Comment 2

[Hideo Oshima]

(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

[[e-mail]]

are they your own builds, or nightlies?

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

Comment 4

[Hideo Oshima]

(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.

Comment 5

[[e-mail]]

(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 :)

Comment 6

[Hideo Oshima]

(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

[[e-mail]]

ok, thanks. hopefully this won't be a problem anymore once the dependency problem in bug 412320 gets fixed.

Comment 9

[[e-mail]]

let's reopen this to get some dependency fixes in for gqi.

Comment 11

[jag (Peter Annema)]

mddepend.pl chokes on \r on continuation lines. Easy fix, patch coming up.

Comment 12

[jag (Peter Annema)]

Attachment: 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.

Comment 13

[(not currently active) 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...)

Comment 14

[jag (Peter Annema)]

Attachment: I think I like this better.

Comment 15

[jag (Peter Annema)]

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.

Comment 16

[jag (Peter Annema)]

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 17

[(not currently active) Ted Mielczarek]

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

Fine with me.

Comment 18

[jag (Peter Annema)]

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.

Comment 19

[Damon Sicore (:damons)]

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

a1.9+=damons

Comment 20

[jag (Peter Annema)]

Checking in mddepend.pl;
/cvsroot/mozilla/build/unix/mddepend.pl,v  <--  mddepend.pl
new revision: 1.10; previous revision: 1.9
done