The default bug view has changed. See this FAQ.

"Section [Build] not found" spammed to the terminal




Build Config
7 years ago
6 years ago


(Reporter: RyanVM, Assigned: Justin Lebar (not reading bugmail))




Firefox Tracking Flags

(Not tracked)



(2 attachments)



7 years ago
Something changed in the last day that's causing this to get spammed a lot when building at least on Windows.
This is really obnoxious.
OS: Windows 7 → All
Hardware: x86 → All
Looks like this gets spammed from  Not sure how we're firing that off in every directory.

the export forces BUILDID to be evaluated each pass through which causes this.
Assignee: nobody → ted.mielczarek
Blocks: 607946
Keywords: regression
Summary: Section [Build] not found → "Section [Build] not found" spammed to the terminal
Yeah, lame. I can probably just make that a shell variable setting in the rule command.
Justin, if you wanted an easy-ish build system to work on you could take this one.

Comment 6

6 years ago
This is Windows-only?  If so, I won't be able to hack on it until I get a Windows machine in a few weeks...
(In reply to comment #6)
> This is Windows-only?  If so, I won't be able to hack on it until I get a
> Windows machine in a few weeks...

No -- this happens on Linux & Mac, too.  I see it locally all the time, and it also shows up in build logs on tinderbox. (Just search for "Section [" in any recent TryServer build log, for example.)
It only happens on clobber builds, fwiw

Comment 9

6 years ago
Ah, the reason I didn't see it in comment 6 is that I had my patch for bug 620285 applied, which apparently fixes this problem.  I think I have a fix.

Comment 10

6 years ago
Created attachment 533303 [details] [diff] [review]
Patch v1

This fixes the spam, although I don't know if breaks something else...
Attachment #533303 - Flags: review?(khuey)

Comment 11

6 years ago
Comment on attachment 533303 [details] [diff] [review]
Patch v1

... actually, it only fixes the problem if you don't know how to use grep.

I think it's the right approach, though.
Attachment #533303 - Flags: review?(khuey)

Comment 12

6 years ago
So comments 9 through 11 are wrong. But also, I think, is comment 3 -- if I comment out the SYMBOL_INDEX_NAME definition, I still get the warnings.

Comment 13

6 years ago
Created attachment 533392 [details] [diff] [review]
Patch v2

Okay, this seems to work.  Comment 12 was wrong again -- the problem was what Kyle suggested in comment 3, but my patch queue was messing with things.

How can I test that I didn't mess up  I guess I could push to try, download the build, and make sure that I'm able to retrieve symbols from the symbol server?
Attachment #533392 - Flags: review?(khuey)
Comment on attachment 533392 [details] [diff] [review]
Patch v2

I'm going to give this one to ted since symbol upload scares me.
Attachment #533392 - Flags: review?(khuey) → review?(ted.mielczarek)
Assignee: ted.mielczarek → justin.lebar+bug
Comment on attachment 533392 [details] [diff] [review]
Patch v2

Review of attachment 533392 [details] [diff] [review]:

::: toolkit/crashreporter/tools/
@@ +61,1 @@
>  : ${SYMBOL_SERVER_HOST?} ${SYMBOL_SERVER_USER?} ${SYMBOL_SERVER_PATH?} ${1?"You must specify a symbol archive to upload"}

Move your variable assignments below this block (which errors if things are unset), and change the ${1 there to ${2, and add a new ${1 to error if the symbol index name isn't given.
Attachment #533392 - Flags: review?(ted.mielczarek) → review+

Comment 16

6 years ago
Ah, thanks for catching that!  I totally glossed over that line.

Comment 17

6 years ago
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.