1219468 - Replace PRLogModuleInfo usage with LazyLogModule in webrtc

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P3)

Description

[Eric Rahm [:erahm]]

This covers replacing PRLogModuleInfo w/ LazyLogModule in the 'media/' directory.

Current usage:
> ./media/mtransport/logging.h:25:      log = PR_NewLogModule(n);                 \
> ./media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp:24:    gLogModuleInfo = PR_NewLogModule("signaling");
> ./media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp:34:    gWebRTCLogModuleInfo = PR_NewLogModule("webrtc_trace");
> ./media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp:42:    sLog = PR_NewLogModule("webrtc_trace");
> ./media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp:51:    sLog = PR_NewLogModule("AEC");
> ./media/webrtc/signaling/src/media-conduit/WebrtcGmpVideoCodec.cpp:44:    sLog = PR_NewLogModule("GMP");
> ./media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp:305:    logModuleInfo = PR_NewLogModule("signaling");

Comment 1

[Raulie Raulerson]

Hi Eric,

Can you assign this bug to me?  

Thank you,

Raulie

Comment 2

[Eric Rahm [:erahm]]

(In reply to Raulie Raulerson from comment #1)
> Hi Eric,
> 
> Can you assign this bug to me?  
> 
> Thank you,
> 
> Raulie

Assigned! Let me know if you have any questions, the parent bug 1219461, comment 0 provides a bit more detail on the conversion if that helps.

Comment 3

[Raulie Raulerson]

I am not certain if I am doing this right.  Below is my replacement of the GetWebRTCLogInfo() method:

static LazyLogModule gWebRTCLogModule = nullptr;

LazyLogModule GetWebRTCLogInfo()
{
  if (gWebRTCLogModule == nullptr)
    gWebRTCLogModule = new LazyLogModule("webrtc_trace");

  return gWebRTCLogModule;
}

I don't want to alter or remove any existing methods as they could be called by other classes.  Is the call to the LazyLogModule constructor correct or do I just need to do the following in the if statement:

gWebRTCLogModule("webrtc_trace");

Thanks.

Comment 4

[Eric Rahm [:erahm]]

Good question. A quick search on dxr [1] indicates this function is never used. As part of this cleanup you can just delete it and the static variable completely.

For other cases where the function is only used locally you can follow the suggestion from the parent bug:

File Scoped Getter Function
===========================
> PR_LogModuleInfo* GetFooLogger() {
>  static (s|g)?(F|f)ooLogger = nullptr;
>  if (!fooLogger) fooLogger = PR_NewLog("FooLogger");
>  return fooLogger;
> }
> ...
> void blah() { MOZ_LOG(GetFooLogger(), ...); }

This would become:
> static LazyLogModule sFooLogger("FooLogger");
> ...
> void blah() { MOZ_LOG(sFooLogger, ...); }

Let me know if you have any other questions!

[1] https://dxr.mozilla.org/mozilla-central/search?q=GetWebRTCLogInfo&case=true

Comment 5

[Raulie Raulerson]

Attachment: bug1219468_replacePRLogModuleInfo.diff

I am sure there are deficiencies in the attached patch file.  I was unsure what to do when existing functions were called locally in the source code files you mentioned and a reference to a LogModule was used to perform a function.  For example, in WebRtcLog.cpp, the method CheckOverrides uses a pointer to a PRLogModuleInfo object.  I subsequently replaced that call with "LazyLogModule *log_info = GetWebRtcTraceLog();".  The GetWebRtcTraceLog method returns a reference to a LazyLogModule instead of a PRLogModuleInfo reference.  

Not sure if this is the proper way to do things.  Please let me know where any changes are needed.  Thanks!!

Comment 6

[Eric Rahm [:erahm]]

Comment on attachment 8731935 [details] [diff] [review]
bug1219468_replacePRLogModuleInfo.diff

Review of attachment 8731935 [details] [diff] [review]:
-----------------------------------------------------------------

This is a great start, I've made a few comments below. Also it looks like unfortunately we won't be able to convert a few of these due to how they are used.

For the next iteration can you please try building before posting your patches?

::: media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp
@@ +20,2 @@
>  
> +LazyLogModule *GetSignalingLogInfo()

This function is never used, we can just remove it here and in the header.

::: media/webrtc/signaling/src/common/browser_logging/CSFLog.h
@@ +39,5 @@
>  ;
>  
>  void CSFLogV( CSFLogLevel priority, const char* sourceFile, int sourceLine, const char* tag , const char* format, va_list args);
>  
> +struct LazyLogModule *GetSignalingLogInfo();

This can be removed too.

::: media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp
@@ -32,5 @@
>  #else // Assume a POSIX environment
>  NS_NAMED_LITERAL_CSTRING(default_log_name, "WebRTC.log");
>  #endif
>  
> -static PRLogModuleInfo* GetWebRtcTraceLog()

I think unfortunately we can't convert this one, I'll double-check with a member of the media team.

@@ -42,4 @@
>    return sLog;
>  }
>  
> -static PRLogModuleInfo* GetWebRtcAECLog()

Same here.

::: media/webrtc/signaling/src/media-conduit/WebrtcGmpVideoCodec.cpp
@@ -34,5 @@
>  #ifdef MOZILLA_INTERNAL_API
>  extern mozilla::LogModule* GetGMPLog();
>  #else
>  // For CPP unit tests
> -PRLogModuleInfo*

It looks like this needs to remain the same for now.

::: media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp
@@ +307,5 @@
>  }
>  
>  class nsIDOMDataChannel;
>  
> +LazyLogModule *signalingLogInfo() {

Lets just replace this whole function with a static variable, ie: 

> static LazyLogModule sSignalingLogInfo("signaling");

And then update any references to the function to just use the variable directly.

Comment 7

[Eric Rahm [:erahm]]

:jesup it looks like |GetWebRtcTraceLog| and |GetWebRtcAECLog| are used to set some sort of mask [1]. Do you know if these are using legit log levels (Disabled - Verbose) or is it arbitrary value?

[1] https://dxr.mozilla.org/mozilla-central/rev/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp#85-94

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Eric Rahm [:erahm] from comment #7)
> :jesup it looks like |GetWebRtcTraceLog| and |GetWebRtcAECLog| are used to
> set some sort of mask [1]. Do you know if these are using legit log levels
> (Disabled - Verbose) or is it arbitrary value?

webrtc_trace is in fact a mask that's passed down to an internal WebRTC.org-specific logging code that we need a control surface for.  We have a separate env var for where those internal logs go, with "nspr" porting those realtime log messages to NSPR logs (at a perf penalty).

AEC logs are basically a flag to turn on AEC dumping of data

Comment 9

[Raulie Raulerson]

(In reply to Eric Rahm [:erahm] from comment #6)
> Comment on attachment 8731935 [details] [diff] [review]
> bug1219468_replacePRLogModuleInfo.diff
> 
> Review of attachment 8731935 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This is a great start, I've made a few comments below. Also it looks like
> unfortunately we won't be able to convert a few of these due to how they are
> used.
> 
> For the next iteration can you please try building before posting your
> patches?
> 
> ::: media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp
> @@ +20,2 @@
> >  
> > +LazyLogModule *GetSignalingLogInfo()
> 
> This function is never used, we can just remove it here and in the header.
> 
> ::: media/webrtc/signaling/src/common/browser_logging/CSFLog.h
> @@ +39,5 @@
> >  ;
> >  
> >  void CSFLogV( CSFLogLevel priority, const char* sourceFile, int sourceLine, const char* tag , const char* format, va_list args);
> >  
> > +struct LazyLogModule *GetSignalingLogInfo();
> 
> This can be removed too.
> 
> ::: media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp
> @@ -32,5 @@
> >  #else // Assume a POSIX environment
> >  NS_NAMED_LITERAL_CSTRING(default_log_name, "WebRTC.log");
> >  #endif
> >  
> > -static PRLogModuleInfo* GetWebRtcTraceLog()
> 
> I think unfortunately we can't convert this one, I'll double-check with a
> member of the media team.
> 
> @@ -42,4 @@
> >    return sLog;
> >  }
> >  
> > -static PRLogModuleInfo* GetWebRtcAECLog()
> 
> Same here.
> 
> ::: media/webrtc/signaling/src/media-conduit/WebrtcGmpVideoCodec.cpp
> @@ -34,5 @@
> >  #ifdef MOZILLA_INTERNAL_API
> >  extern mozilla::LogModule* GetGMPLog();
> >  #else
> >  // For CPP unit tests
> > -PRLogModuleInfo*
> 
> It looks like this needs to remain the same for now.
> 
> ::: media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp
> @@ +307,5 @@
> >  }
> >  
> >  class nsIDOMDataChannel;
> >  
> > +LazyLogModule *signalingLogInfo() {
> 
> Lets just replace this whole function with a static variable, ie: 
> 
> > static LazyLogModule sSignalingLogInfo("signaling");
> 
> And then update any references to the function to just use the variable
> directly.

Thank you for the comments.  I am working on addressing the issues you noted. 

I am running into the following errors when I build the changes:

Undefined symbols for architecture x86_64:
      "mozilla::detail::log_print(mozilla::LogModule const*, mozilla::LogLevel, char const*, ...)", referenced from:
        _CSFLogV in CSFLog.o

      "mozilla::LogModule::Get(char const*)", referenced from:
        _CSFLogV in CSFLog.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I will try to straighten this out tomorrow, but may ask for help if I get stuck.

Thanks.

Comment 10

[Raulie Raulerson]

> 
> Thank you for the comments.  I am working on addressing the issues you
> noted. 
> 
> I am running into the following errors when I build the changes:
> 
> Undefined symbols for architecture x86_64:
>       "mozilla::detail::log_print(mozilla::LogModule const*,
> mozilla::LogLevel, char const*, ...)", referenced from:
>         _CSFLogV in CSFLog.o
> 
>       "mozilla::LogModule::Get(char const*)", referenced from:
>         _CSFLogV in CSFLog.o
> 
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> 
> I will try to straighten this out tomorrow, but may ask for help if I get
> stuck.
> 
> Thanks.

I haven't been able to figure out why I am still getting for the errors above.  The best I can figure is that the call to MOZ_LOG is causing the issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to a LogModule instead of the object itself (passed by value).  That's why the compiler cannot match the existing function headers with the call from MOZ_LOG.  

Do you have any recommendations on how to deal with this issue?

Comment 11

[Raulie Raulerson]

Attachment: CSFLog.cpp

Attached are the changes to CSFLog.cpp that are causing build errors.

Comment 12

[Eric Rahm [:erahm]]

 > I haven't been able to figure out why I am still getting for the errors
> above.  The best I can figure is that the call to MOZ_LOG is causing the
> issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because
> MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to
> a LogModule instead of the object itself (passed by value).  That's why the
> compiler cannot match the existing function headers with the call from
> MOZ_LOG.  
> 
> Do you have any recommendations on how to deal with this issue?

Ugh this has been a bit more complicated than I had hoped. It looks like the issue is that this code is used in the signaling unit tests [1] which don't link with libxul (that's where mozilla::LazyLogModule lives). I filed bug 1257713 to fix the unit tests, but for now we can just leave the "signaling" log as-is.

[1] Running |./mach build -j1 binaries| (limiting our build system to one thing at a time) helped me identify that it was during the building of a unit test that it failed.

Comment 13

[Eric Rahm [:erahm]]

(In reply to Eric Rahm [:erahm] from comment #6
> > -static PRLogModuleInfo* GetWebRtcAECLog()
> 
> Same here. 

It looks like we *can* change this one given :jesup's response in comment 8.

Comment 14

[Raulie Raulerson]

(In reply to Eric Rahm [:erahm] from comment #12)
>  > I haven't been able to figure out why I am still getting for the errors
> > above.  The best I can figure is that the call to MOZ_LOG is causing the
> > issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because
> > MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to
> > a LogModule instead of the object itself (passed by value).  That's why the
> > compiler cannot match the existing function headers with the call from
> > MOZ_LOG.  
> > 
> > Do you have any recommendations on how to deal with this issue?
> 
> Ugh this has been a bit more complicated than I had hoped. It looks like the
> issue is that this code is used in the signaling unit tests [1] which don't
> link with libxul (that's where mozilla::LazyLogModule lives). I filed bug
> 1257713 to fix the unit tests, but for now we can just leave the "signaling"
> log as-is.
> 
> [1] Running |./mach build -j1 binaries| (limiting our build system to one
> thing at a time) helped me identify that it was during the building of a
> unit test that it failed.

Does this mean that CSFLog.h and CSFLog.cpp need to remain the same for now and all other file changes can proceed?

Comment 15

[Eric Rahm [:erahm]]

(In reply to Raulie Raulerson from comment #14)
> (In reply to Eric Rahm [:erahm] from comment #12)
> >  > I haven't been able to figure out why I am still getting for the errors
> > > above.  The best I can figure is that the call to MOZ_LOG is causing the
> > > issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because
> > > MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to
> > > a LogModule instead of the object itself (passed by value).  That's why the
> > > compiler cannot match the existing function headers with the call from
> > > MOZ_LOG.  
> > > 
> > > Do you have any recommendations on how to deal with this issue?
> > 
> > Ugh this has been a bit more complicated than I had hoped. It looks like the
> > issue is that this code is used in the signaling unit tests [1] which don't
> > link with libxul (that's where mozilla::LazyLogModule lives). I filed bug
> > 1257713 to fix the unit tests, but for now we can just leave the "signaling"
> > log as-is.
> > 
> > [1] Running |./mach build -j1 binaries| (limiting our build system to one
> > thing at a time) helped me identify that it was during the building of a
> > unit test that it failed.
> 
> Does this mean that CSFLog.h and CSFLog.cpp need to remain the same for now
> and all other file changes can proceed?

I think you can still remove |gWebRTCLogModuleInfo| and |GetWebRTCLogInfo()| [1] as they are unused.

[1] https://dxr.mozilla.org/mozilla-central/rev/f14898695ee0dd14615914f3e1401f17df57fdd7/media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp#29-37

Comment 16

[Raulie Raulerson]

I am still working on this bug.  I just ran into some problems with my Mozilla setup.  Hope to have a patch committed in the next few days.

Comment 17

[Eric Rahm [:erahm]]

(In reply to Raulie Raulerson from comment #16)
> I am still working on this bug.  I just ran into some problems with my
> Mozilla setup.  Hope to have a patch committed in the next few days.

Thanks for the update, let me know if you have any questions. Our IRC server [1] can be a useful resource for getting started, feel free to hop on there if you need any assistance.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Need_help

Comment 18

[Raulie Raulerson]

Attachment: bug1219468_replacePRLogModuleInfo.diff

I have made all changes except to ./media/mtransport/logging.h (this creates more errors and I need .  The changes I have made will be posted as a patch, though I know I still have some work to do.  When I try to build with these changes, I get the error below:

../../../mtransport/testlib/transportlayerprsock.o

 Undefined symbols for architecture x86_64:
   "mozilla::LogModule::Get(char const*)", referenced from:
        CheckOverrides(unsigned int*, nsACString*, bool*) in Unified_cpp_webrtc_signaling0.o

    ld: symbol(s) not found for architecture x86_64 
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[2]: *** [sdp_unittests] Error 1
    make[1]: *** [media/webrtc/signaling/test/target] Error 2
    make: *** [binaries] Error 2

Can you provide any insight on how I might be able to fix this error?  I haven't had much luck in determining why mozilla::LogModule::Get() is being called from CheckOverrides().  Any help you could provide would be greatly appreciated.

Comment 19

[Eric Rahm [:erahm]]

(In reply to Raulie Raulerson from comment #18)
> Created attachment 8736082 [details] [diff] [review]
> bug1219468_replacePRLogModuleInfo.diff
> 
> I have made all changes except to ./media/mtransport/logging.h (this creates
> more errors and I need .  The changes I have made will be posted as a patch,
> though I know I still have some work to do.  When I try to build with these
> changes, I get the error below:
> 
> ../../../mtransport/testlib/transportlayerprsock.o
> 
>  Undefined symbols for architecture x86_64:
>    "mozilla::LogModule::Get(char const*)", referenced from:
>         CheckOverrides(unsigned int*, nsACString*, bool*) in
> Unified_cpp_webrtc_signaling0.o
> 
>     ld: symbol(s) not found for architecture x86_64 
>     clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>     make[2]: *** [sdp_unittests] Error 1
>     make[1]: *** [media/webrtc/signaling/test/target] Error 2
>     make: *** [binaries] Error 2
> 
> Can you provide any insight on how I might be able to fix this error?  I
> haven't had much luck in determining why mozilla::LogModule::Get() is being
> called from CheckOverrides().  Any help you could provide would be greatly
> appreciated.

This is good progress, let's just leave GetWebRtcAECLog() as-is for now, it can be fixed when we fix the signaling unit tests.

Comment 20

[Raulie Raulerson]

(In reply to Eric Rahm [:erahm] from comment #19)
> (In reply to Raulie Raulerson from comment #18)
> > Created attachment 8736082 [details] [diff] [review]
> > bug1219468_replacePRLogModuleInfo.diff
> > 
> > I have made all changes except to ./media/mtransport/logging.h (this creates
> > more errors and I need .  The changes I have made will be posted as a patch,
> > though I know I still have some work to do.  When I try to build with these
> > changes, I get the error below:
> > 
> > ../../../mtransport/testlib/transportlayerprsock.o
> > 
> >  Undefined symbols for architecture x86_64:
> >    "mozilla::LogModule::Get(char const*)", referenced from:
> >         CheckOverrides(unsigned int*, nsACString*, bool*) in
> > Unified_cpp_webrtc_signaling0.o
> > 
> >     ld: symbol(s) not found for architecture x86_64 
> >     clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> >     make[2]: *** [sdp_unittests] Error 1
> >     make[1]: *** [media/webrtc/signaling/test/target] Error 2
> >     make: *** [binaries] Error 2
> > 
> > Can you provide any insight on how I might be able to fix this error?  I
> > haven't had much luck in determining why mozilla::LogModule::Get() is being
> > called from CheckOverrides().  Any help you could provide would be greatly
> > appreciated.
> 
> This is good progress, let's just leave GetWebRtcAECLog() as-is for now, it
> can be fixed when we fix the signaling unit tests.

I left GetWebRtcAECLog() as it is for now.  I keep running into an error very similar to the ones I have previously posted about. This time it has to do with PeerConnectionImpl.cpp (please note that I have not altered ./media/mtransport/logging.h yet -- I have tried, but I get similar errors; for now, I am trying to fix each error when I encounter it).  Again, the error manifests itself when executing the signaling unit tests:

0:25.98 Undefined symbols for architecture x86_64:
 0:25.98   "mozilla::LogModule::Get(char const*)", referenced from:
 0:25.98       mozilla::PeerConnectionImpl::PeerConnectionImpl(mozilla::dom::GlobalObject const*) in PeerConnectionImpl.o
 0:25.99 ld: symbol(s) not found for architecture x86_64
 0:25.99 clang: error: linker command failed with exit code 1 (use -v to see invocation)
 0:25.99 make[2]: *** [signaling_unittests] Error 1
 0:25.99 make[1]: *** [media/webrtc/signaling/test/target] Error 2
 0:25.99 make: *** [binaries] Error 2

Should I wait to resume working on this bug until the signaling tests are fixed?  Thank you for being patient with me.

Comment 21

[Raulie Raulerson]

Have the signaling unit tests been fixed?  I would like to resolve this bug if possible.

Comment 22

[Nils Ohlmeier [:drno]]

Hi Raulie,

I don't see the signaling unit tests being broken for compilation, which I understand is the problem you are facing. So they compile fine for me without your change. So I'm guessing this is caused by your patch then.
Note: the signaling_unittest does not start for me right now, but looks like a different error to me.

My guess is that the problem arises from the fact the unit tests under mtransport link in big parts of XUL.

Comment 23

[Eric Rahm [:erahm]]

Nils the issue mentioned is from comment 12. The signaling unit tests are still standalone so using mozlog is problematic.

Comment 24

[Raulie Raulerson]

(In reply to Eric Rahm [:erahm] from comment #23)
> Nils the issue mentioned is from comment 12. The signaling unit tests are
> still standalone so using mozlog is problematic.

Thanks for the response Eric and Nils.  Sounds like I will have to wait for the signaling unit tests to be converted before this bug can be resolved.  Please let me know if I misinterpreted your comments.  Thanks!

Comment 25

[Raulie Raulerson]

Eric, have the signaling unit tests been fixed?  I would like to try to resolve this bug, but am aware that I will have a difficult time doing so until the signaling unit tests are fixed.  Thanks!

Comment 26

[Nils Ohlmeier [:drno]]

Raulie as you can see in bug 1316611 there was some progress made in other bugs. But I think it is not totally resolved yet.

Comment 27

[Randell Jesup [:jesup] (needinfo me)]

Until bug 1316611 is fixed, can't we just do:
#if MOZILLA_INTERNAL_API
  use LazyLog
#else
  use PR_NewLogModule
#endif

Comment 28

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Replace PRLogModuleInfo usage with LazyLogModule in webrtc

rebased

Comment 29

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests

Extends the previous patch to remove the rest of the PRLogModuleInfos except when building c++ unit tests.  Also fixes that webrtc.org LOG(...) << ... usages were going to stderr in Debug builds - now they go to nspr (and in Debug builds, they still also go to stderr).  MOZ_LOG logging levels are now translated to webrtc trace masks with 5 (verbose) mapping to 65535, the most commonly-used webrtc trace value.  The mapping can be overridden by a env var.

Comment 30

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests

one minor change I forgot to save

Comment 31

[Eric Rahm [:erahm]]

Comment on attachment 8831041 [details] [diff] [review]
Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests

Review of attachment 8831041 [details] [diff] [review]:
-----------------------------------------------------------------

Great to see this finally getting wrapped up!

Comment 32

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Comment on attachment 8831041 [details] [diff] [review]
Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests

Review of attachment 8831041 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great.

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a2aba1ecb3c
Replace PRLogModuleInfo usage with LazyLogModule in webrtc r=jesup
https://hg.mozilla.org/integration/mozilla-inbound/rev/a83751c7946f
Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests r=erahm,ng

Comment 34

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/1a2aba1ecb3c
https://hg.mozilla.org/mozilla-central/rev/a83751c7946f