Closed Bug 1221194 Opened 9 years ago Closed 9 years ago

Intermittent B2G L Emulator build failing with nsHTTPCompressConv.cpp:111: error: undefined reference to 'gHttpLog'

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
45 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox45 --- affected

People

(Reporter: KWierso, Unassigned)

References

Details

(Keywords: intermittent-failure) 

I'm a little unclear on what can cause intermittent build failures. is unified sources not deterministic perhaps?
potentially related to this in the log:
16:23:03     INFO -  /home/worker/workspace/B2G/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld: error: /home/worker/objdir-gecko/objdir/toolkit/library/../../netwerk/streamconv/converters/Unified_cpp_converters0.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
and in the compressor code

extern LazyLogModule gHttpLog;
#define LOG(args) MOZ_LOG(mozilla::net::gHttpLog, mozilla::LogLevel::Debug, args)

then lots of uses of LOG(("foo"))
nick - do you have any insight here? thanks if you do! (and thanks if you don't, come to think of it..)
Flags: needinfo?(n.nethercote)
No insight, sorry. If you're after LazyLogModule knowledge erahm might be a better bet.
Flags: needinfo?(n.nethercote) → needinfo?(erahm)
I suspect this might be a corner of c++ I'm not familiar with...
I get the feeling we just need to add 'static' the LazyLogModule definitions that are being externed. Presumably this was okay b/c the sources were unified (so in the same compilation unit), but I guess that's not always true for the Android L build.

The interesting errors:
> 16:23:03    ERROR -  /home/worker/workspace/gecko/netwerk/streamconv/converters/nsHTTPCompressConv.cpp:111: error: undefined reference to 'gHttpLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/netwerk/streamconv/converters/nsHTTPCompressConv.cpp:77: error: undefined reference to 'gHttpLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/netwerk/streamconv/converters/nsHTTPCompressConv.cpp:118: error: undefined reference to 'gHttpLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/netwerk/streamconv/converters/nsHTTPCompressConv.cpp:59: error: undefined reference to 'gHttpLog'
> 16:23:03    ERROR -  ../../../../../workspace/gecko/netwerk/protocol/rtsp/rtsp/AAMRAssembler.cpp:231: error: undefined reference to 'gRtspLog'
> 16:23:03    ERROR -  ../../../../../workspace/gecko/netwerk/protocol/rtsp/rtsp/AAMRAssembler.cpp:231: error: undefined reference to 'gRtspLog'
> 16:23:03    ERROR -  ../../../../../workspace/gecko/netwerk/protocol/rtsp/rtsp/AAMRAssembler.cpp:231: error: undefined reference to 'gRtspLog'
> 16:23:03    ERROR -  ../../../../../workspace/gecko/netwerk/protocol/rtsp/rtsp/AAMRAssembler.cpp:231: error: undefined reference to 'gRtspLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/dom/base/nsDOMDataChannel.cpp:49: error: undefined reference to 'mozilla::gDataChannelLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/dom/base/nsDOMDataChannel.cpp:472: error: undefined reference to 'mozilla::gDataChannelLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/dom/base/nsDOMDataChannel.cpp:480: error: undefined reference to 'mozilla::gDataChannelLog'
> 16:23:03    ERROR -  /home/worker/workspace/gecko/dom/base/nsDOMDataChannel.cpp:488: error: undefined reference to 'mozilla::gDataChannelLog'

Indicates the following need to be fixed:
- gHttpLog
- gRtspLog
- gDataChannelLog

I can do a try push to see if this fixes things.
Flags: needinfo?(erahm)
Eric, thanks for this

(In reply to Eric Rahm [:erahm] from comment #7)
> I get the feeling we just need to add 'static' the LazyLogModule definitions
> that are being externed. Presumably this was okay b/c the sources were
> unified (so in the same compilation unit), but I guess that's not always
> true for the Android L build.

I fear I'm about to say something dumb, but I have a couple built in excuses: my head is full of cold meds and I'm 12 hours out of sync with my normal timezone. Interpret accordingly.

those vars were not declared static because they are used in more than one file.. thus the externs in the headers for them. (the other new LazyLogModules are used in one file and are indeed declared static - these were the exceptions). Doesn't making them static make them unreachable from the other files?

of course s/file/compilation-scope so unified sources can play a role but I don't exactly see how in this case.
Flags: needinfo?(erahm)
hmm and a local build with that patch (clang linux) throws the following errors - which makes sense to me

 0:06.47 ../../../../gecko-dev/netwerk/protocol/http/nsHttpHandler.cpp:106:22: error: static declaration of 'gHttpLog' follows non-static declaration
 0:06.47 static LazyLogModule gHttpLog("nsHttp");
 0:06.47                      ^
 0:06.47 ../../../../gecko-dev/netwerk/protocol/http/HttpBaseChannel.h:55:31: note: previous definition is here
 0:06.47 extern mozilla::LazyLogModule gHttpLog;
 0:06.47                               ^
(In reply to Patrick McManus [:mcmanus] from comment #9)
> Eric, thanks for this
> 
> (In reply to Eric Rahm [:erahm] from comment #7)
> > I get the feeling we just need to add 'static' the LazyLogModule definitions
> > that are being externed. Presumably this was okay b/c the sources were
> > unified (so in the same compilation unit), but I guess that's not always
> > true for the Android L build.
> 
> I fear I'm about to say something dumb, but I have a couple built in
> excuses: my head is full of cold meds and I'm 12 hours out of sync with my
> normal timezone. Interpret accordingly.

Fear not, I was wrong and had it backwards.

> those vars were not declared static because they are used in more than one
> file.. thus the externs in the headers for them. (the other new
> LazyLogModules are used in one file and are indeed declared static - these
> were the exceptions). Doesn't making them static make them unreachable from
> the other files?

Yes, you are correct.

> of course s/file/compilation-scope so unified sources can play a role but I
> don't exactly see how in this case.

Yes, I agree. I think this might be a job for the build crew to interpret.
Flags: needinfo?(erahm)
(In reply to Patrick McManus [:mcmanus] from comment #10)
> hmm and a local build with that patch (clang linux) throws the following
> errors - which makes sense to me
> 
>  0:06.47
> ../../../../gecko-dev/netwerk/protocol/http/nsHttpHandler.cpp:106:22: error:
> static declaration of 'gHttpLog' follows non-static declaration
>  0:06.47 static LazyLogModule gHttpLog("nsHttp");
>  0:06.47                      ^
>  0:06.47
> ../../../../gecko-dev/netwerk/protocol/http/HttpBaseChannel.h:55:31: note:
> previous definition is here
>  0:06.47 extern mozilla::LazyLogModule gHttpLog;
>  0:06.47                               ^

Yes, the patch fails. I aborted the try run but didn't update here.
Mike, I'm just grasping at straws - any thoughts on what could be going on here? Thanks if you do! (or don't.)
Flags: needinfo?(mh+mozilla)
The fact that the error for nsHTTPCompressConv.cpp talks about gHttpLog instead of mozilla::net::gHttpLog makes me think the build is just borked for some reason. I wouldn't be entirely surprised if the way the source tree and/or the objdir are being handled by taskcluster is involved in this, combined with the recent move of gHttpLog from the global namespace to mozilla::net (bug 1219466). I haven't looked but I guess the others g*Log have similar stories.
Flags: needinfo?(mh+mozilla)
does this still intermittently happen?
Flags: needinfo?(wkocher)
This appears to have only happened three times on the day I filed this bug:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1221194&endday=2015-12-17&startday=2015-08-01&tree=trunk

Unsure if something fixed it or if it was just a fluke.
Flags: needinfo?(wkocher)
thanks
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.