|
honey the codewitch wrote: If there were ever a good case for logging, it's on large incredibly complicated applications running on disparate, possibly remote systems
Exactly our use case, and the reason why we built our own system. It's based on TCP/IP sockets and each software component contains a small server. Our client application can connect to as many of these servers as you like. The servers send messages (printf() on steroids) and the client can send commands back to the servers. The client can save traces to a file, and can be set up for recording continuously over a long term. It's proven invaluable given that our product runs on multiple computers and each component is heavily multithreaded. The client application is our oldest piece of software still in continual development. It got its start in 2000, and gets a new release every now and then as we discover a need for a new feature (or I get bored and want something fun to work on for a change  ).
Software Zen: delete this;
|
|
|
|
|
Right on! and it's encouraging that I'm not actually getting ripped apart in the comments over my remarks.
This place is really heavy on business development, i think because that's what most development is, and logging is big business. 
I'm in the minority it seems, in that I don't do bizdev, at least not anymore. I write commercial software, but it's not b2b or ecom or anything like that.
Logging is useful for me in certain situations, but in a lot of them it just isn't.
Real programmers use butterflies
|
|
|
|
|
In my case, I have embedded systems all over the world. There is no way to attach a debugger.
In addition to having thousands of systems all over, toss in multiple versions of code and a varied mix of connected hardware, all running in different production environments, and we have a real opportunity for understanding what data is necessary to collect to allow us to figure out what is wrong.
I do like the idea of different flavors of logging. We do this now on one side the system, but on mine, I'm just dumping into a text file what I think is useful. I'm going to think about dividing it up.
As for managing the log files, we set a max side and roll across 3 of them.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
|
Thanks, I'll grab them now.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Last company, we logged everything; enter any method, its name and parameters logged.
I prefer mini-dumps.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
charlieg wrote: I'd like to hear from others what they just know they need to log.
I've always found a stack trace and minidump to be very useful. Combining it with a log only helps to find what the user was doing when the exception occured which might not be of interest.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Combining it with a log only helps to find what the user was doing when the exception occured which might not be of interest.
This. I'm so glad you wrote this because it so succinctly describes what logging is for - tracking the user's movements through the app, rather than what the app is doing.
Now in my code on my jtagless embeddeds i have to log what the app is doing too, because i don't have a debugger, but generally - i'd say in most cases, you're right to bring this up.
If you're logging things other than the user's movement through the app you just might be using the wrong tool for the job.
Real programmers use butterflies
|
|
|
|
|
Yeah,
Situational awareness via telemetry is also important though. It helps developers learn what features are being used in your application (or operating system). By tracking the user movements through your application (or operating system) you can easily identify which features are not being used.
In the old days developers would add/design features and have no clue that absolutely nobody used it.
|
|
|
|
|
I'm going to remain hopelessly old fashioned in that regard and it has to do with something I wrote to someone earlier.
I won't take part in writing software that surveils users without their continuous and ongoing consent.
Now, gathering telemetry data doesn't necessarily *always* violate that. Figuring out if a feature is being used is kind of benign, but it all depends i guess on the level of gathering of information (are you trying to pick out their relative's birthdays from their contacts?_ and also what are you trying to do with that information? - telemetry is a muddy area for me and one where I'm wary.
At the end of the day, would I be okay with a neighbor looking at me the way the software is? I guess maybe that's a rule of thumb for me, but I just came up with it and i haven't really put it to the test.
But I will not write software that abuses or harms the people that use it, or makes it easier for other people to harm others, where I can help it. For me that covers a lot of ground, and surveilling without their continuous and ongoing consent comes under abusing others - for me.
I'm making moral arguments here, but I am not a believer in an objective morality - only that there's things I can live with and things I can't.
I haven't said any of this in judgment of others. I personally care elephant-all where other devs draw the line, but for me I have a vicious and fickle conscience and I cross it at my peril.
Real programmers use butterflies
|
|
|
|
|
Randor wrote: In the old days developers would add/design features and have no clue that absolutely nobody used it.
True story from the early 1970s: When I first visited the team that wrote the assembler for the machines we built, I asked about some of the more arcane pseudo-ops. Things like controlling listing width.
Turns out they were "sacrificial". There were features the devs wanted but management didn't grok, and the devs knew there would be pressure to trim the feature list. So they threw in a bunch of useless ones, so they could be noble later and trim the list at management's request (keeping their goodies, of course). The trimming wasn't perfect...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I take a little bit different approach to logging. I work on automation systems and I have multiple levels of logging going on simultaneously. I'll mention just a couple. One is the trace buffer. It's always going and is essentially major events of note. The next one is what I call debug messages. These work like traces but have a mask associated with them that can be changed at run-time. The masks are bit-oriented and each bit is associated with a given functional aspect of the system. There are about two dozen of them defined now and there can be up to 63 because the zero bit is always set on. I wrote a special facility for this that uses shared memory to buffer up a whole bunch of messages and access is controlled by a mutex so multiple processes can use the same buffer. As it turns out, this is really, really fast which was my primary goal. I have measured the overhead for each message to be less than one microsecond on my old laptop. The same test was performed using printf calls to a console and the overhead was measured to be greater than 12uS. Writing directly to a text file is unacceptable for a variety of reasons. I tried that a few decades ago and abandoned it entirely. My systems involve multiple processes, each with multiple threads, and I worked for a long time to come up with a mechanism that solves all the problems and I'm pretty happy with this one. There's a lot more to it but I'll stop there.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
This is similar to what I do. I avoid mutex overhead by using a std::atomic_uint32_t as an index into a circular trace buffer, with each of its entries simply being a pointer to whatever holds the captured information.
|
|
|
|
|
Perhaps "time travel/reverse" debugging would be useful
|
|
|
|
|
That's very useful for debugging but out of the question on a live system. I can't count the number of times I've stepped over a function call, assuming the problem had to be further down, only to discover that I should have stepped into that function, and now the entire scenario has to be rerun from the beginning. 
|
|
|
|
|
Perhaps I do not understand time travel debuggers as I have yet to utilize one. Please permit me to inquire further re your response. Would not a time travel debugger permit stepping backward and entering the function you refer to after having discovering there is where the problem lies without having to restart? Thank You Kindly - Cheerio
|
|
|
|
|
I haven't used one either, but I think your characterization is accurate. My point was intended to mean that I wish I had been using one on many occasions.
|
|
|
|
|
May I please inquire what is meant by a "live" system. Is it that which is in the hands of final users? If so is not the logging performed by a time travel debugger in such a situation equivalent to any logging which might otherwise occur? Best Wishes - Cheerios
|
|
|
|
|
Yes, by "live system", I meant one in the hands of an end user. There's no way anything like a time travel debugger will be running on such a system. For one thing, it would cause it to run way too slow. Even if it didn't, how many users would let you connect to their system to do debugging? Their system would have to sit there, halted at a breakpoint that you were previously allowed to set, until you could do your debugging. And then you'd be dealing with a release build, and they're a total buttpain to debug because of compiler optimizations, no symbol tables, and so forth.
|
|
|
|
|
ah, yes, another religious discussion!!
printf, nothing else than printf.
I'd rather be phishing!
|
|
|
|
|
logging *is* religious which is fine. it's why I asked the question. I'm going to grab all these comments and see how I can fold the ideas into something useful.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Greetings and Kind Regards May I please inquire how you spend your time while your project is building? As for myself I twiddle my thumbs or watch a portion of a Star Trek episode or stream music or merely surf Cheerios
|
|
|
|
|
Well, I work on three other projects, defrag my hard drive, brush my teeth... 
Depending on how big the system is, most of us scratch ourselves. Anyone want to back me up? 
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
What's your build time?
As a C# developer working with Visual Studio it's pretty much instant, so I guess I let out a sigh of relief that I didn't get any build errors 
It takes a little longer on the build server, but I'm not really interested in waiting for that so I just continue to work as usual.
It's not like I'm out of work after every commit I make to my build server 
|
|
|
|
|
It is time you to move on to some serious project...
To check a simple feature the build is instant, but a full version build is almost 15 minutes - fortunately it is done on a build machine so I have time to do other things on my computer...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
