I agree with Emily replacing our logging with a new framework might introduce its own set of problems. Maybe reducing the logging and moving the logging to a background thread (when in production) might help. It's really not directly fixing the problem but it could help.
In the case of reducing the logging there are cases where logging happens very frequently ( try slowly displaying/hiding the urlbar) in this case hundreds of events are logged to the logger. On Tue, Apr 12, 2016 at 10:06 AM, Stefan Arentz <sare...@mozilla.com> wrote: > Cool now we have two choices for a better logging framework :-) > > Farhan, do you want to work on this? Lets decide which one is good for us > and migrate to it? > > XCGLogger is currently in the top three of crashes, we would love to > replace it with something that is better maintained and less buggy. > > S. > > On Apr 12, 2016, at 9:38 AM, Farhan Patel <fpa...@mozilla.com> wrote: > > There is also https://github.com/emaloney/CleanroomLogger which does a > few optimizations to make sure performance in Production is good. It is > also written in swift. We also still get different levels of logging. But > it could also bring its own set of bugs. > The thing with using nslog is that because it runs on the main thread > there can be a small performance hit. I think most people recommend not > running nslog in production. > > On Tue, Apr 12, 2016 at 9:28 AM, Steph Leroux <sler...@mozilla.com> wrote: > >> What I am thinking now is this: we are having a lot of problems (crahses) >>> with XCGLogger. I’m thinkiing we should kill it completely. >> >> >> I agree. We seem to have crashes every release related to XCGLogger. >> >> Instead we will write logs with NSLog(), which is managed by the OS and >>> can be easily downloaded with the tool I just linked to >>> >> >> On the downside, we'll lose a couple of things such as: >> >> 1. File/console logging >> 2. Different levels of logging which we use extensively (debug, info, >> error, etc) >> 3. Our abstractions on top of XCGLogger such as the RollingFileLogger. >> >> I think either way we'll need something more than just NSLog to handle >> our logging needs. >> >> Another option I've used in the past is Lumberjack ( >> https://github.com/CocoaLumberjack/CocoaLumberjack). It not only >> contains a similar feature set as XCGLogger but is widely used, maintained, >> and even contains a more complex rolling file logger than we've built. It's >> also Carthage compliant so it could be pulled in with ease. >> >> On Mon, Apr 11, 2016 at 10:56 PM, Stefan Arentz <sare...@mozilla.com> >> wrote: >> >>> I just found http://lemonjar.com/iosconsole/ which is a wonderful >>> little tool that people can use to download both the console log and crash >>> reports from their devices. >>> >>> What I am thinking now is this: we are having a lot of problems >>> (crahses) with XCGLogger. I’m thinkiing we should kill it completely. >>> Instead we will write logs with NSLog(), which is managed by the OS and can >>> be easily downloaded with the tool I just linked to. No more special hacks >>> to get people to submit log files. All we need to do is use the standard >>> logger and tell people to run the app to grab them in case we need >>> diagnostics. >>> >>> S. >>> >>> >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> mobile-firefox-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >>> >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> mobile-firefox-dev@mozilla.org >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
