application logging

[mnguyen]

Is anybody against using a formal package for logging inside the application? Currently we are writing debug statements out onto the console. It would be nice to be able to log things according to severity levels into files for debugging crashes that seem to be occurring more and more. Especially for those errors that people are finding hard to reproduce.

I don't know of many packages or libraries in C++ but perhaps something like Log4Cxx would be a good candidate? I've used log4j and log4net in my other projects with some success.

What is everybody's feeling on this?

mike

[wololo]

We have a "LOG" macro that does that kind of job. It doesn't handle any kind of level for now but that would be simple to adapt. I'm not sure we need more than that. Especially, since it is a macro, it doesn't log at all if the macro is not defined, which is what we want in "production" mode.

Edit: of course logging to a file in the release version on the PSP is out of question given the performance hit this would cause.
We can think of enabling it for the Alpha or Beta though, or maybe get a "Debug" version out for people who want to help with bug fixing

[mnguyen]

using log4cc if it's like log4j does this level transparently. For instance, log.DEBUG will only write anything if DEBUG is enabled. Plus the configuration can be modified to not log anything at all, we just turn off the root logger in the conf file. I think that's one benefit over the macro since it doesn't require a special build for it to run or not run.

[wololo]

If it's configuration/runtime driven it will be slightly slower. I'm not a huge fan of "over optimization", but I am surely happy to be able to remove all log related code at compile time. I assume this library has options to do that, let's maybe see what the others think about the idea. if it's more than one header and one cpp file though, I'd be against the idea.

[MootPoint]

I don't think a separate package is necessary for logging either - if there's anything missing, it's certainly easy enough to implement. I like the idea of being able to turn on logging as an option, but it's a performance hit that is particularly painful on the psp, as the i/o isn't very fast.

What I'd prefer (and the reason you're probably interested in better logging): I'd like something that could write out a (legible) call stack when a crash occurs on the psp. Now that would be worth its weight in gold...

[mnguyen]

yes. The reason for the logging tooling is for determining when, where and why a crash happens. right now it's like shooting in the dark since it not guaranteed to occur on Windows. Unless there is a PSP simulator out there somewhere where we can load and debug the app with, I feel this kind of logging is necessary. I'm really against writing our own code when a package already exists that has been fully tested and supported. However, I do understand the performance considerations and will yield if the performance does suffer with the package. If you don't mind, I'll try it out. How do you want to measure performance? Is there some kind metric you use to gauge performance (aside from obvious load times)? I do have a PSP-1001, which by all accounts I think is the slowest of all the PSPs.

what do you think?

--

[abrasax]

Hi,

Unless there is a PSP simulator out there somewhere where we can load and debug the app with,

just for info there is PSP emulator although I never tried it and I have no idea if it would be of any use, but just for the record : http://www.qj.net/qjnet/psp/psp-homebre ... r1814.html

Grü

Abra

[wololo]

yes. The reason for the logging tooling is for determining when, where and why a crash happens. right now it's like shooting in the dark since it not guaranteed to occur on Windows. Unless there is a PSP simulator out there somewhere where we can load and debug the app with, I feel this kind of logging is necessary.

The tool you are looking for has been existing since the creation of man, and is called PSPLink. This is what everybody uses to debug on the PSP. Not a log file on the user's machine.
PSPLink is very easy to set up, and to use it, you just fprintf(stderr, stuff)
It also ships with gdb.

also, bugs that occur on the PSP only but not on windows are 99% a cache problem. you can compile the game with DEBUG_CACHE (double check the name of the variable, not entirely sure) and you'll get a bunch of information.

I'm really against writing our own code when a package already exists that has been fully tested and supported.

Agreed, but we have a very specific use case. We run on a machine that is not powerful enough to do efficient logging. The chances of an external package taking that into account are very slim.
Also, one of my points was that we should leverage the existing code rather than adding yet another logging system. It's not like we don't have an existing logging mechanism.

However, I do understand the performance considerations and will yield if the performance does suffer with the package. If you don't mind, I'll try it out. How do you want to measure performance? Is there some kind metric you use to gauge performance (aside from obvious load times)? I do have a PSP-1001, which by all accounts I think is the slowest of all the PSPs.

Display the framerate of the game.
I think there are options to do that in JGE, but they might be broken, so maybe they need to be updated.
Ideally, the framerate should be 30fps or above, occasional drops to 10fps are acceptable.

There is also a free profiling application (by AMD) that you can use on windows. I have some documentation on profiling on the PSP, I'll post it here if it is needed.

Most likely, with logging turned on, you won't need any kind of metric, you will visually see that the game is unplayable, and/or choppy mp3 playback if you log anything in the "Render" or "Update" sections.
A possibility would be asynchronous logging...but that would require quite a good amount of work. I'm not sure if it would help with performance. Not mentioning, again, the risk of crash before the interesting information gets logged.

The Debug version of HBL, which logs a fair amount of things, is close to 20 times slower than the distrib version.

regarding the configuration on/off switch at runtime, I think the difference between that and distributing two versions of the game (a regular one and a debug one) are not big for the user.

what do you think?

I would question the goal of logging first. I've found logging to be interesting when working on a specific bug. And then, the logging I put in place was never used ever again, so I ended up deleting it. I believe logging is in most cases a "once in a while" thing you do, and because of that, compiling my own debug version and testing it (either through psplink or directly on the psp), then deactivating the debug flags.
As MootPoint said, this is not Java, we don't have a stacktrace. If there was a way to get a stacktrace (again, that would only happen if we compile with the DEBUG flags, so not in the distrib version) that could be interesting.

give a try to the following defines:
DOLOG in Logger.h
DEBUG
DEBUG_CACHE (probably in wResourceManager? or config.h ?)

When a user reports a bug, most likely the won't provide the log file. If they do (maybe after we ask them), the probability that the log doesn't contain any useful information will be high (because it's a new bug, so we don't log what is interesting for this bug). And even if they do, we will want to reproduce the issue by ourselves. In that case, we will compile a debug version that does logging, and track the bug by ourselves. I still don't see the real use case for a runtime log mechanism in the PSP distrib version.

Again, my major concern with that is performance + use case.

[mnguyen]

Understood. I had not known about the existing logging facility. Thanks. Without a stack trace it does become more difficult to track errors.

Thanks for the explanation I've been looking for.