All that debugging logging - more tracing than logging - code in a release version smells of lame developer. IMHO when a developer is so obsessed in tracking his own steps, it's because he doesn't trust his own code. Don't get me wrong. Well placed logs and trace code are good, people "printfing" every damned steps of their code should never leave high school.
WhatsApp, Apple and a hidden source code F-bomb: THE TRUTH
Facebook-owned chat app WhatsApp says viral screenshots of rude messages to Apple buried deep within its mobile application's code are not real. A spokesperson told The Register on Friday afternoon that the screenshots posted to Reddit showing log strings with the phrase "Fuck Apple" spread throughout were not taken from its …
COMMENTS
-
-
Friday 9th September 2016 07:21 GMT Adam 52
On the other hand I try to single-step every single line of my code before release. I'm not arrogant enough to think I write perfect code and I've found lots of subtle errors this way.
This used to be a common tactic 15 years ago, when graphical IDEs made it easy, but seems to have fallen out of favour these days.
There used to be a C library/preprocessor that logged every single line as it executed. You'd hate that but it was incredibly useful for finding bugs that couldn't be reproduced. I couldn't find it, so would love a link if anyone's got one.
-
Friday 9th September 2016 08:57 GMT Anonymous Coward
Using a profiler to profile code (different type of profiling) is good. Identifying code that is never executed and write tests that exercise it is good. Writing tests to ensure code performs as designed is good.
Littering the code with "log" calls is evil - especially if it writes to a single file because 1) it's slow 2) it needs locks to serialize 3) it may inadvertently leave around sensitive information 4) it makes code far less readable when you encounter a log call every line or so.
I know I'll got downvotes because I know there are lots of "developers" out there who never learnt how to code truly, and need to leave breadcrumbs around to understand where they are and what they did, and they do in the most outdated way still around.
Especially those who looks they can't understand how to use exceptions properly to gracefully handle and log what went wrong. Or those who refuses to use a proper IDE because "true programmers" don't.
Anyway this just confirms my opinion WhatsApp is something cobbled together by lame developers who were just very lucky they got enough PR to become widely used.
-
-
Friday 9th September 2016 07:23 GMT OliverJ
So, coding for the Apple ecosystem was a little bit more demanding ....
... and the coder was a little bit stressed out? That doesn't exactly increases my confidence into the technical competence of WhatsApp. And I agree that this "debug log" has no place in shipped code.
While I agree that Apple may not provide the ideal environment for dev's (which ecosystem does?), I think that this discovery is more revealing regarding WhatsApp, their QA, and the maturity of their staff.
-
Friday 9th September 2016 07:25 GMT Hans 1
1. This is most likely the work of an undergrad.
2. Pretty sure he wanted to work on the iOS team to get the latest shiny iPhone, however, since he was not good enough, was sent over to work on the Android port.
As for the guyz complaining about dev environments, can Visual Studio not be used to create iOS apps, last time I checked, that was the case, I know, I know, Visual Studio sucks, but, you are NOT limited to Mac OS X POS, you can also use Play D'Oh OS. Then again, it might just be marketing on MS' part, like, you can write the code, yet, you need OS X to compile ... I dunno, have NOT tried, I do not care about iOS, PlayD'Oh OS, or VisualStudio.
Now, don't get me wrong, I am NOT an Apple fanboy ... Apple is just mehhhhh
-
Friday 9th September 2016 07:46 GMT Warm Braw
"can Visual Studio not be used to create iOS apps" [?]
Provided that you wish to rely on Xamarin''s cross-platform middleware, you can write iOS applications using Visual Studio. However, you still need at minimum a Mac "build host" because you can't build an iOS application except on a Mac.
I dunno, have NOT tried, I do not care
An excellent basis for posting, then.
-
Friday 9th September 2016 12:02 GMT Hans 1
Re: "can Visual Studio not be used to create iOS apps" [?]
Indeed, I hereby apologize, been mislead by MS marketing ... should have looked closer and at least tried it.
The other part of my post, however, could be true ... I mean, this guy must have some reason to hate Apple which I cannot make sense of - remember, he writes the Android port, so Apple should not bother him ... EXCEPT, maybe, if he is jealous.
-
-
-
Friday 9th September 2016 22:14 GMT Anonymous Coward
Re: Visual Studio sucks
"the best Linux can offer is QTCreator"
... and yet somehow the Linux kernel devs manage to scrape by on a project that is rather large and complex:
$ find /usr/src/linux/ -name "*.[ch]" | nl finds 44,444 files
$ find /usr/src/linux/ -name "*.[ch]" -exec cat {} \; | nl spits out 17,032,797 lines
Not very scientific ...
-
-
-
Friday 9th September 2016 07:39 GMT Anonymous Coward
Are you saying you go through your code and remove all of the debug logging from your code instead of just having a config flag to switch it on or off at run time?
Your comment makes you sound like you're not actually supporting any live software, hint, the option to switch debug logging on in a live system can be a life saver, it's not like you can attach a debugger and step through, and not everything is repeatable in different environments. Setting DEBUG=true in a config file and asking the user to retrace their steps can be enough to tell you exactly what is going on.
-
Friday 9th September 2016 08:23 GMT OliverJ
The facility used is log.d. Hence my quotes. 'nuff said. And how "FUCK APPLE: Fail to add new user" is supposed to help debugging live code one or two years in the future, or when the dev has left the team, will remain your secret. I had to dig into code from someone who left the company based on such helpful "debug logs" more than once.
-
Friday 9th September 2016 09:05 GMT Anonymous Coward
The 70s and 80s are over, if you still need that kind of "debugging" believe me you're need to update your programming and debugging skills. Also, any application that has a "debug" switch somewhere you can easily turn on just risks to dump a lot of sensitive information. I've seen some happily writing passwords and so on to files.... which nobody then deleted.
Anyway, remember there is a difference between "tracing" and "logging". And even with a live system you can use separate debug symbols and remote debugging to attach a running application and see what is doing and where it breaks - with far better inspection capabilities than a text log. Or analyze exception or crash dumps. Yes, it's a little more complex than opening a log with a text editor, but it usually points you at an issue much more quickly, once you learnt how to use the proper tools. But keep on with printf(), if it makes you feel better...
-
Friday 9th September 2016 09:24 GMT Dan 55
Yes, you don't log passwords in the same way as you don't log "FUCK APPLE". Both are not good ways of logging. I think most people would agree with that.
Now back to debugging, I bet you work at RBS if you compile a release build with debug symbols set and think having a live system or a thread in it grind to a halt while you step through it is in any way acceptable.
You might claim you can get all possible errors all sorted out by the QA stage. When this doesn't happen because you can't set everything up to perfectly match the live system (e.g. scale), logging helps.
-
Friday 9th September 2016 10:56 GMT Anonymous Coward
When you start "logging" that way, you will end to log also sensitive information. I already seen it.
You can strip debug symbols for executables, and use them only when needed. You don't also need to step manually through code but in extreme conditions - and usually means your tests were utterly inefficient. But you can get error traces - and only error traces - with enough information to tell you what is happening without any need to log every other line. If you don't know how to implement more modern error tracing techniques than old "printf()", you will take ages to resolve issues on a live, critical system.
-
Friday 9th September 2016 14:35 GMT HmmmYes
OK, A problem has occurred. Ive replaced the production executable with a debug version - all debug remain unstripped.
I run the system up and - wow! - no problem.
so why does the production version not work but the debug does?
Again, a very naive and limited version on what can go wrong.
No imagine we talking about a system running many 100s or 1000s of binaries. NOw you'll see why application logging becomes essential.
-
Monday 12th September 2016 09:12 GMT Displacement Activity
> I run the system up and - wow! - no problem.
> so why does the production version not work but the debug does?
If the logging version works, and the production one doesn't, the answer is almost certainly that you have an issue with uninitialised data, or memory over-writes. You can (and should) find and fix all these on your dev system with Valgrind/Purify/etc. before it gets anywhere near production.
-
-
-
-
This post has been deleted by its author
-
-
Friday 9th September 2016 10:13 GMT HmmmYes
No. Not in this case. Not in a lot of cases.
This application needs to run on a number of similar but not identical platforms.
At a guess, its also working its way through a FSM against some sort of remote entity which may or may implement a protocol. Maybe that protocol has been 'optimised' by a 3rd party.
There's a world of difference writing a single application that runs on one or two platforms, to writing a very large - think telecom switch - that has to interface to a large number of 3rd parties which may or may not implement a protocol correctly. Then there's different version of protocols.
Large system live and die by their logging. Tools like Dtrace give you some help for free.
-
Friday 9th September 2016 13:51 GMT Anonymous Coward
DTrace is exactly one of those dynamic tools you can use to debug code on a production system. It does work by "instrumenting" (patching) code at run-time by identifying and replacing some well known code sequences (you can also use static "probes", but DTrace can work without) in the kernel, user space libraries and application code.
It will not depend on logs data defined at compile time, it will let you inspect exactly what you need at runtime.
Anyway, user logging is not developer tracing. For example, a network admin will need logs only with information useful for his monitoring and troubleshooting of the systems. Bury them into a lot of data useless to him, and you'll have an unhappy admin.
-
-
Friday 9th September 2016 16:21 GMT Anonymous Coward
"with a live system you can use separate debug symbols and remote debugging to attach a running application"
Well that clinches it.
No fucking idea what your doing. If you have access to your live environment to do ANYTHING (Never mind attach a remote debugger) then your doing it wrong.
Never mind the fact that the live system that you are debugging is potentially multi user and you dont want 1500 people all sitting waiting for you to read a line of code and press F10 because your remote debugger has paused execution of a thread on a live server.
"'ve seen some happily writing passwords and so on to files.... which nobody then deleted."
To be fair, thats not an issue with logging, thats people putting too much infotmation in the logs that they are writing. You should not write sensitive information out to a log, this does not mean that you should not write the log in the first place.
Going back to the remote debugger - would you care to enlighten me as to how the whatsapp developers could remote debug the app on an end users phone?
I'd probably report bugs and send logs, I'd certainly not let a third party access my phone to attach a debugger to it.
-
-
Friday 9th September 2016 09:22 GMT Anonymous Coward
"Are you saying you go through your code and remove all of the debug logging "
No. I don't use that kind of outdated techniques dating back to an era when debugger, profilers and exceptions didn't exits at all. Yes, I did it too in BASIC many years ago, 150 PRINT "I'm here!!!". No need to do it today in production code.
First, my code is written following a "defensive programming" approach to identify anomalous situations early - and raise proper exceptions when it happens, never log and go on, executing code in unsafe states that often can lead to exploitable vulnerabilities. Oh, and never catch an exception, log it, and then clear it without properly and wholly handling it.
I'm much more confident thereby in the code I write, especially I also write tests to check it works as designed.
Then I use exceptions properly to handle errors - creating for example dumps with stack traces, system state, etc. etc. Much more useful to reconstruct quickly what lead to an error than a text log with too few information. And you get a centralized way to report issues without littering the code with log calls and hardcoded strings (a good help to reverse engineers, believe me).
Profilers will tell me what I need to inspect further.
I use logs for what they are designed to - tell the end users their system is working as they configured it for, and report errors if they happen. Also, I use the system log facilities for that, because in a live system you'll be using monitoring systems which need to be able to spot errors in logs, and warn those in charge.
-
Friday 9th September 2016 14:07 GMT Doctor_Wibble
> Yes, I did it too in BASIC many years ago, 150 PRINT "I'm here!!!"
I really hope you didn't actually do such a shockingly amateurish thing, and that it's just shorthand for 'got here 1', 'got here 2'... like proper professionals do.
Especially when trying to figure out why that 3000 line mega-program from C&VG we just slavishly typed in isn't working, before the grand revelation that the semicolon was actually a comma with a speck of dirt and 'thwack' 'ow' 'just run it' 'I told you it would be rubbish' etc.
-
Friday 9th September 2016 16:29 GMT Anonymous Coward
@Anon
"No. I don't use that kind of outdated techniques dating back to an era when debugger, profilers and exceptions didn't exits at all. Yes, I did it too in BASIC many years ago, 150 PRINT "I'm here!!!". No need to do it today in production code."
You might as well have said "I just write my code without bugs to start with" that way we could have all skipped reading the rest and got the laughing at you over with that little bit sooner.
"I use logs for what they are designed to - tell the end users their system is working as they configured it for, and report errors if they happen. Also, I use the system log facilities for that, because in a live system you'll be using monitoring systems which need to be able to spot errors in logs, and warn those in charge."
I think that you have misunderstood what logging we are talking about here, this isnt a message that the user will see unless they go looking for it, its a file burred away somewhere ready to be sent to/inspected by the developers in the event of an error.
Its all well and good saying that you write robust software and its all unit tested and goes through QA etc... NONE of that has any impact on the fact that logging what your application is doing at any given time is immensely useful, you might want to be able to go back and see what the app was doing at a given time last tuesday - maybe there were no errors, maybe you just want to know if user X was in there and called function Y (This isnt a great example, but you get the idea)
-
Friday 9th September 2016 19:35 GMT Wensleydale Cheese
"Setting DEBUG=true in a config file and asking the user to retrace their steps can be enough to tell you exactly what is going on."
Many years ago I discovered a similar debug mechanism lurking in the code I was given to fix as my first task in a new job.
Whoosh! I managed to identify some bad data on file in less than an hour on a system I'd never seen before.
This can be a seriously productive means of identifying problems.
-
-
-
Friday 9th September 2016 07:41 GMT Anonymous Coward
Debug logging
Just a thought, but does the Log.d method actually do anything in the released version?
In a .NET application (and I appreciate this is different but am assuming the runtime environment is capable of JIT compilation), if Log.d doesn't actually do anything (e.g. if the code in that method is surrounded by a preprocessor if block), the compiler should optimise out all the calls. Much more efficient from a time perspective than adding and removing debug log lines as you need them, and to some extent they serve to document the code as well...?
-
Friday 9th September 2016 13:41 GMT deftelf
Re: Debug logging
Log.d() doesn't do any logging on a release build, but the code isn't stripped out of the package that is distributed. That's what happened here (despite all the comments on here by non-Android devs that don't know what they're talking about), the code has been decompiled to expose these calls but they don't actually write anywhere in the released package.
-
Friday 9th September 2016 14:10 GMT Anonymous Coward
Re: Debug logging
Is this code ever executed? It looks it has several issues. Just look at the first useless if(), the unconditional continue statement, the use of the i variables to access the array, the infinite loop in the catch, the second method that does nothing but logging despite its parameters...
Looks like something forgotten there. No coverage tests?
-
-
Friday 9th September 2016 09:20 GMT Anonymous Coward
The best thing about this is that someone else actually checked the code.
Yes, but it would be a lot better if that person worked for WhatsApp, because this seems to suggest either a lack of code audit, or a worryingly juvenile attitude to something that is supposed to keep communication safe (well, not anymore, Facebook bought it :) ).
-
Friday 9th September 2016 09:28 GMT Anonymous Coward
"I see Apple try to actively fuck with standard ways of doing things all the fucking time, like they want to see the world burn and cause headaches for companies/devs everywhere, like the lamest fucking Bond villain ever," writes user CanadianBadass.
LOL. Integration iOS with a Linux backend is exactly easy because Apple are pretty good standards compliant with anything that has to communicate with others outside their own eco system.
"Let alone the inability to compile code except on their machines, which greatly limits my ability to do CI, automation or anything else efficient except on their overpriced POS hardware."
If you can't be bothered to buy a machine for the platform you're developing for (you know, to just test that things actually work as emulators are never perfect) than maybe you should not be developing for that platform.
"As someone who has had to upload an app to the app store, I completely understand," writes user xantxant. "If their store process is indication, Apple hates developers and wants us to die, so 'Fuck Apple' is a completely rational response."
I have some sympathy with that, especially if you want to go international or in different languages there is a learning curve involved, also because Apple tend to test and enforce their rules far more rigorously than Google. It is, however, not that much of a chore if you write following the guidelines instead of trying to force the code into compliance afterwards. I reckon WhatsApp must have been thrown back quite a few times because of their desire to access so much customer data (which has now turned out quite an accurate objection)..
That said, collecting hate messages on anything and anyone is rather easy on the Web..
-
Friday 9th September 2016 11:23 GMT The Indomitable Gall
" "Let alone the inability to compile code except on their machines, which greatly limits my ability to do CI, automation or anything else efficient except on their overpriced POS hardware."
If you can't be bothered to buy a machine for the platform you're developing for (you know, to just test that things actually work as emulators are never perfect) than maybe you should not be developing for that platform. "
The problem is you have to buy a Mac to develop for iOS. OS X is not iOS, a Mac is not an iOS device. The Mac has the best iOS emulator, but as you said, "emulators are never perfect".
It's a massive frustration for a lot of would-be app developers that even experimenting with iOS development has initial costs in the region of a grand. (Well, there's the Mac Mini as the "cheap" option, but most folk skip that and go for one of the portables.)
-
Friday 9th September 2016 17:50 GMT Anonymous Coward
"It's a massive frustration for a lot of would-be app developers that even experimenting with iOS development has initial costs in the region of a grand. (Well, there's the Mac Mini as the "cheap" option, but most folk skip that and go for one of the portables.)"
So, you've never heard of eBay then?
-
-
-
Friday 9th September 2016 10:30 GMT sabroni
What's with all the ACs going on about how cool they are
Why hide your identity if you're so confident of your abilities?
AC is for business sensitive posting. It's not really appropriate if all you have to say is "I code better than you" or "you're old fashioned".....
Put a name to your posts or fuck off.
-
Friday 9th September 2016 16:36 GMT Anonymous Coward
Re: What's with all the ACs going on about how cool they are
AC is for business sensitive posting.
According to whom? Maybe for you, but you cannot speak for all El Reg members.
I always post as AC because I am not invested in maintaining an online persona/posting history, badges, and generally prefer anonymity.
-
Friday 9th September 2016 19:44 GMT Anonymous Coward
Re: What's with all the ACs going on about how cool they are
Why hide your identity if you're so confident of your abilities?
Because that way I can offer an opinion without distractions such as name - as a matter of fact, it will force you to better look at the argument, not at the person. Secondly, I am not hiding my identity, I am protecting it. Slight, but rather important difference. If you knew who I was you would understand, but that would create a somewhat circular problem :). Besides, having a name is no guarantee either as some change it almost every day..
AC is for business sensitive posting.
Really? Who put you in charge? AC is simply a decision of the poster not to pollute the debate with track record, badge or who they work for - whatever the reason is, it's their decision to post AC rather than with a handle, not yours. You don't get to vote on that. It's IMHO also more honest than pretending, for instance, you're Linus Torvalds when offering an opinion about kernel programming - AC's will at least not use a false magical cloak to amplify their argument.
It's not really appropriate if all you have to say is "I code better than you" or "you're old fashioned".....
Oh, it is. And I do. And you are. Joking aside, I'm actually with you on a "I'm better than you" post that lacks substantive arguments to back up such an assertion. I like facts, and the facts I like best are the ones that brook independent validation - side effect of the work I do. Work, I must add, which pretty much compels me to post AC :).
Put a name to your posts or fuck off.
No, and no. Annoying, isn't it?
-
Friday 9th September 2016 11:33 GMT Anonymous Coward
Hehehehehe
I once worked for a company selling cheap Chinese made Android media centres which had a nice boot screen showing the name of the build machine.... forget having to look in the source code, this thing booted up calling everyone a 'c**tbox'.
So this is quite mild by comparison.
Anon to protect the innocent...
-
Friday 9th September 2016 12:03 GMT heyrick
Having read all these comments
I'll throw my own penny into the well.
You're obviously not a "real programmer" (whatever that may mean) if you omit the ability to output logging diagnostics. Yes, on a live system. Why? Because unless you are working with a locked down design that your own company manufactures; it is worth remembering that because it works on your setup is no guarantee that it will perform flawlessly on others. Different hardware? Different processor implementation (which could be as simple and silly as the Pi3's lack of SWP in 32 bit mode), different memory, different drivers, blah blah.
My flabber is also gasted at the idea of catching the error and continuing regardless. Obviously a program should not just crash upon an error, but it probably ought to stop and await direction on how to proceed. After all - transaction is finished, write results to disc, device not responding, bugger it let's just pretend it worked who's gonna look? - is that how it should be? Programs generally do stuff out of necessity, not because the programmer was bored and wanted to string together keywords in amusing patterns...if the operation fails, it could well have knock on effects.
-
Friday 9th September 2016 12:43 GMT Anonymous Coward
Re: Having read all these comments
"logging diagnostic" != "printf() every other line". The fact many of you believe to be "real programmers" just because you make your code spend more time writing what it does instead of actually doing it is the issue.
Exceptions are there to take a different execution path when errors occurs - handle it properly, or record the error and stop. Still, I find programmer who can't understand exceptions and don't want to use them - or hide them under the carpet. Or programmers who don't check for return codes for languages still without exception, and act accordingly.
As I often say "Good programmers always set proper return codes. Bad programmers never check them."
Logging is not error handling, is just error recording, or worse, "hey, I got here, I can't believe it!". Usually because their code can easily take wrong and unexpected execution paths - because they don't code in a safe way. So they need a lot of "execution logging" - not "diagnostic logging" - to understand what unexpected path their code took. Just, that is unsafe code. In the best case it will just crash your application, in the worst one it will silently corrupt data or create vulnerabilities. And you can add as much "printf()" you like, still your code is dangerous. And the more verbose the log with lots of useless information, the more difficult to process it and find what's really wrong.
Do you test only on your development system? You have an issue. Don't you check if the system supports the features and the resources you need? You have an issue. You first aim is to *prevent* issues, not happen for them to wait, and just to be sure, write "I'm here!" every other line.
Then, yes, if something goes wrong record enough information to understand what went wrong. Can't you obtain a stack trace yoursefl? There are libraries that will help you. Have facilities so error handlers can obtain and dump "object" states you need. I by far prefer to analyze a crash dump with GDB than going through thousand of lines of usually badly uninformative logs - which often require the developer to upload yet another version with added logging...
-
Friday 9th September 2016 17:00 GMT d3vy
Re: Having read all these comments
"Exceptions are there to take a different execution path when errors occurs - handle it properly, or record the error and stop."
It becomes more and more apparent the more that you post that you dont understand what is being discussed, we are not talking about logging errors, we are talking about logging what the application is doing, not just when something fails, but at any time, I can jump on my (READ ONLY) Log file share on the prod server right now and tell you exactly what user X was doing this morning at 10:03 I can tell you what forms they submitted, what web service was hit, how long it took to respond and what its response was, I probably dont need that information, but the minute overhead for generating it is far outweighed by the additional tool that I have for debugging issues that may crop up in the future.
"As I often say "Good programmers always set proper return codes. Bad programmers never check them."
Catchy.
-
-
-
Friday 9th September 2016 14:36 GMT Tikimon
I'd rather not F*** Apple, thanks
She looks all pretty, but the experience is never as good as promised. You have to pay for dinner and do all the hard work, and she won't even answer your call the next day.
(sorry, not quite sure what I was thinking, there was a budding joke in there somewhere)
-
Friday 9th September 2016 18:34 GMT gnasher729
I don't quite see what's the news year.
So some Android developer hates Apple, hasn't reached any level of maturity yet, and puts "**** Apple" into logging statements. So what? One day he (very few female developers manage to have that level of immaturity) will grow up and realise what an idiot they have been. One day the company will implement mature development processes including code reviews and all his f***ing will disappear.
-
Friday 9th September 2016 23:16 GMT ThomH
Agreed; this developer happens to have taken offence at a particular company, many others have done basically the same thing with all the other companies, their colleagues, other software components, software patterns, actors, footballers, varieties of plant...
Other than suggesting, if true, that WhatsApp has a poor peer review system, the news is that at least one developer doesn't like Apple?
-