Comment On Please Supply a Test Case

Finally!  Thank you for posting code again!

As long as this is Java, then _inputStream.read() will return -1
when it reaches the end of the stream, so it will be possible for _char
== -1 to be true.

Also, catching an OutOfMemoryError is extremely bad practice, as is catching anything derived from Error...

JDK5.0 API - java.lang.Error

 
An Error is a subclass of Throwable
that indicates serious problems that a reasonable application
should not try to catch.

 
Because OOME is thrown when the JVM is out of memory (suprise suprise...) the JVM cannot handle the catch case and just exits.

 

 

I think the problem is that (char)-1 is *not* -1 as char is an unsigned type.

The catch(OutOfMemoryError) actually made me go 'WTF?' for real 

Bob Janova:

I think the problem is that (char)-1 is *not* -1 as char is an unsigned type.

Ah, too true - Friday afternoon and my mind is no longer here ;-)
 

What is this trying to do?  Read as much data from _inputStream as it will offer, stripping off up to two CR+LF's from the front?  Or any combination of CR+LF's, and the inner pair of if() blocks are completely redundant?  (I figure I could work it out by poking around the net, but why do that when someone who does Java for a living can prolly figure it out in five seconds)

 

Parsing HTTP headers, I suspect.

I suppose they didnt realise the reason they were running out of memory in the first place....

while (true) {
char _char;

Now unless java has some wierdness - im pretty sure thats allocating a new block of memory each loop?

Java does have one unsigned datatype, namely char: its range is 0 to 0xFFFF.

 So char == -1 will in fact return true if char is 0xFFFF.
 

Anonymous:

I suppose they didnt realise the reason they were running out of memory in the first place....

while (true) {
char _char;

Now unless java has some wierdness - im pretty sure thats allocating a new block of memory each loop?

 No, that will create a char on the stack, but it will be reused every loop (or recreated in the same place on teh stack).

This part will allocate a new byte on the heap though, which if it wasnt for Javas magic garbage collection, would leak a lot of memory (being a C++ coder, this line made me go "WTF!")
                                       _inputStream.read(
                                           new byte[_inputStream.available()]);

however, the Java spec states that the garbage collecter *is not guarenteed to run at any time during your programs execution*! So depending on the platform this is running on, those bytes may not get cleaned up till the program quits.
 

Tim Gallagher:

// Somebody must have been smoking hashish when they wrote this

 LOL

I write much better code when I'm smoking hashish, people underestimate its ability to help solve complex problem... 

Cannot believe the HTTP client company is so lazy that they did not even strip out their comments in their code.  That's a serious business (not technical) mistaken.

Ow.  My head.

Anonymous:

Java does have one unsigned datatype, namely char: its range is 0 to 0xFFFF.

 So char == -1 will in fact return true if char is 0xFFFF.
 

No, it won't.  I just checked.

Java only does four types of math: int, long, float, and double.  byte, short, and char all get promoted to an int whenever any math is done with them (including comparisons).  I suppose you could argue that boolean operations count as math so that's a fifth type.

In any case, all math operations involving bytes, shorts, and chars are done with ints.  So the following code:

public class test {
  public static void main(String[] args) {
    char c = (char) -1;
    System.out.println(c == -1);
    System.out.println(-1 == '\uFFFF');
  }
}

Prints:

false
false

I just tested it.  And, yes, it's really annoying that Java has a policy of "no unsigned datatypes" and then treats chars as essentially unsigned shorts.
 

Because OOME is thrown when the JVM is out of memory (suprise suprise...) the JVM cannot handle the catch case and just exits.

Actually, that's not quite true: OOME is thrown when there is not enough memory to honour a request to allocate more. Depending on what you are doing, this may be recoverable (e.g. if you're allocating a 128MB block).
 

In the case of the Sun JVM, objects won't become candidates for GC inside a method - so allocating objects in a long-running loop in a single method is likely to cause you problems.

 We've resolved GC issues in long-running loops (e.g. numerical analysis) by extracting methods out.
 

however, the Java spec states that the garbage collecter *is not
guarenteed to run at any time during your programs execution*! So
depending on the platform this is running on, those bytes may not get
cleaned up till the program quits.

 

On mobile phones it typically runs GC when memory is about to run out. I did a test once, and was like WTF, when showing available memory and it was continually shrinking. I was curious what will happen, when it runs out, but it just ran GC and freed all unused memory. 

Anonymous:

I suppose they didnt realise the reason they were running out of memory in the first place....

while (true) {
char _char;

Now unless java has some wierdness - im pretty sure thats allocating a new block of memory each loop?

It does not. It is a variable local to the loop, same stack slot will be used at each loop. 

@OP: Thanks for the first real headcrash in a long time! I
usuallyskip the xml or other screw-up WTFs because i go here to see
things i do not see on my desk on a daily basis... ;-)

Anonymous:

Cannot believe the HTTP client company
is so lazy that they did not even strip out their comments in their
code.  That's a serious business (not technical) mistaken.

This
reminds me of stripping comments on my own from supplied code, for the
sake of readability. Since i do not have several asian fonts installed
these come out as pure noise.

The real WTF in this part i do not
see in the code, however. The reference to the "we see no problem,
please tell us whats wrong" attitude actually made me cringe as i got
mugged down memory lane.

When i encountered this level of
professionalism with a supplier last time, (something along the level
of "the gfx driver does not start" ->  "We see no problem, what
does the splash screen say?") i first gave my "answer" to the project
manager for a thumb-up. Got an "are you nuts?", which was pretty much
what i hoped for.

captch: captcha. :-)  

The real WTF is that if this is indeed Java Code, that they payed a "huge" amount for a closed source HTTPClient - i dont know if that was like 10 years ago because the jakarta http commons util exists for quiet some time (years)....

Being serious about this stripping comments? WTF.

The real WTF is that there were two WTFs on the same day!

Anonymous:

The real WTF is that there were two WTFs on the same day!

And one disappeared for a while the other day.... Some WTFery is going on at The Daily WTF...

Anonymous:

Anonymous:

I suppose they didnt realise the reason they were running out of memory in the first place....

while (true) {
char _char;

Now unless java has some wierdness - im pretty sure thats allocating a new block of memory each loop?

 No, that will create a char on the stack, but it will be reused every loop (or recreated in the same place on teh stack).

Maybe I get your remark wrong, but a while loop generating a stack?

That's
nonsense,  the assembly equivalent of a while loop would be a
conditional jump, that doesn't create a call on the stack. 

I think the problem is when a read() return -1, it is not detected by the if() (because of the conversion to char), then it sits in the while(true) loop, appending one char (with value 0xFFFF) to the StringBuffer at each iteration until there is no more memory and the processor emits smoke.

They could just read the whole buffer (since they allocate it at the end any way), then search for "\r\n\r\n" in-memory (much more simple to do) and then build a StringBuffer from the first part of byte[] buffer.

As a novice at programming it's no surprise I don't understand everything that is said on here, but what I find very confusing is all the different answers and explainations.  A little help please.

zamies:

Anonymous:

No, that will create a char on the stack, but it will be reused every loop (or recreated in the same place on teh stack).

Maybe I get your remark wrong, but a while loop generating a stack?

That's
nonsense,  the assembly equivalent of a while loop would be a
conditional jump, that doesn't create a call on the stack. 

You're thinking the same thing, just saying it differently. The variable is local to the block, you can't access it outside the scope of the while block. As far as the java language cares, it only exists inside the while block, and the specifications require it to be initialized to zero at the point of declaration.

Now the compiler probably does NOT actually allocate new stack space of it every time it enters the loop, but instead optimizes it by allocating stack space for all variables on function entry. Now all it has to do is zero the value at the beginning of the loop.

Strictly speaking in compiler theory though, you only need to put the variable on the stack inside of the loop. It's the optimizer that will move it back outside :)  
 

Anyway, what was this http client doing on server ? This CodeSOD smells like a J2ME... 

Anonymous:

Because OOME is thrown when the JVM is out of memory (suprise suprise...) the JVM cannot handle the catch case and just exits.

Actually, that's not quite true: OOME is thrown when there is not enough memory to honour a request to allocate more. Depending on what you are doing, this may be recoverable (e.g. if you're allocating a 128MB block).
 

 The OOME in this case really tells the whole story, I'm pretty sure of what's happening here without even trying to understand the conditional logic in there. Something similar has actually happened to me -- except I fixed the loop rather than catching the OOME :)

 
The string buffer has an internal buffer that is being added to with each pass of the loop. When the exit condition for a loop is wrong and the loop runs forever adding one char every time this will very quickly allocate all available memory to the string buffer.

Just think: A processor with a memory bandwidth of gigabytes per second and a computer with maybe a single gigabyte of ram.

StringBuffer sb = new StringBuffer();
while(true) { sb.appendChar('x'); }

will run out of memory within seconds, especially if the VM size is restricted.
 

Fewww... when I start reading, and got to the comments, I was sure that someone had posted MY code. I have put both

// I have no idea what this does but it looks important

and  

 

// Somebody must have been smoking hashish when they wrote this

in piecies of code (yes, I know, I just lost my chances of ever getting hirred by any of you :-) 

'bout time somebody posts a non-WTF version of this code.

 

People just gotta love this Paula HTTP Client. I can imagine management decision.. "WHAT? 100 % CPU usage? We need better hardware!"
 

*Ouch*... My brain... :)

Seriously, the little side note:

<interrupting thought>
I work with a guy who is never satisfied with a, "I dunno it just works."
He always steps through code, or compiles it in his head and figures it out
(I swear he can compile code in his head)  He says, "It's never good enough to know that it works, because if you don't know why or how it works someday it might stop, and then you won't know why, or how to fix it."
</interrupting thought>

Sounds a bit like me, if I do not sound too high on myself... :)  My biggest problem is not that I need to know how something works, but I expect other developers to as well.  My bad... :)

Peace!

jtwine:

*Ouch*... My brain... :)

Seriously, the little side note:

<interrupting thought>
I work with a guy who is never satisfied with a, "I dunno it just works."
He always steps through code, or compiles it in his head and figures it out
(I
swear he can compile code in his head)  He says, "It's never good
enough to know that it works, because if you don't know why or how it
works someday it might stop, and then you won't know why, or how to fix
it."
</interrupting thought>

Sounds a
bit like me, if I do not sound too high on myself... :)  My
biggest problem is not that I need to know how something works, but I
expect other developers to as well.  My bad... :)

Peace!

 

Well maybe you're a computer (did you pass the turing test already) but the phrase :

jtwine:

..., or compiles it in his head and figures it out

Sounds like a load of bollocks to me...

Unless you're a computer compiling shit won't help you understand it.

I precompile it in my head to figure it out. WTF!

 

Nandurius:

Now the compiler probably does NOT actually allocate new stack space of it every time it enters the loop, but instead optimizes it by allocating stack space for all variables on function entry. Now all it has to do is zero the value at the beginning of the loop.

Strictly speaking in compiler theory though, you only need to put the variable on the stack inside of the loop. It's the optimizer that will move it back outside :)   

Actually, in Java, local variables must be explicitly assigned to  (Java Language Specification, chapter 16) before they are read and the compiler must be able to prove it or it refuses to compile.

OK - maybe not "compile" in the sense of doing translation to opcodes...  My fault for copying without editing.  But there were smileys present, and I did say "a bit like me"...

But along those lines, I am sure that you can get an idea of what happens when you see code like

if( ( bValue ) || ( iValue=CallFunc() ) )

- You can see a possible bug simply by knowing how the code will (or wil not) execute depending on the value of bValue.

Hey - I once debugged something by having a hex dump of a memory area read to me over the phone, which was kinda like reverse-compiling... :)

Peace!

--------------------------------------------------
Just because you do not know what I am talking about, that does not mean that I do not.

Nandurius:

You're thinking the same thing, just saying it differently. The variable is local to the block, you can't access it outside the scope of the while block. As far as the java language cares, it only exists inside the while block, and the specifications require it to be initialized to zero at the point of declaration.

Now the compiler probably does NOT actually allocate new stack space of it every time it enters the loop, but instead optimizes it by allocating stack space for all variables on function entry. Now all it has to do is zero the value at the beginning of the loop.

Actually, the specification only requires fields to be initialized to zero; a local variable will not be automatically initialized. If it is used before it is initialized, you will get a 'the local variable var may not have been initialized' compiler error.
 

jtwine:

OK - maybe not "compile" in the sense of doing
translation to opcodes...  My fault for copying without
editing.  But there were smileys present, and I did say "a bit like me"...

But along those lines, I am sure that you can get an idea of what happens when you see code like

if( ( bValue ) || ( iValue=CallFunc() ) )

- You can see a possible bug simply by knowing how the code will (or wil not) execute depending on the value of bValue.

And the semantics of the or operator (remember VB6).

jtwine:

Hey - I once debugged something by having a hex dump of a memory area read to me over the phone, which was kinda like reverse-compiling... :)

 duh!

 

 

> And the semantics of the or operator (remember VB6).

Ahhh...  But I do not need to worry about that, nor how it works in the many other languages that I do not currently have a need for.  It is but one of the many benefits of being a highly-paid specialist.  I am sure that one day, you will understand.

>> Hey - I once debugged something by having a hex dump of a
>> memory area read to me over the phone, which was kinda like
>> reverse-compiling... :)
> duh!

Easy, kid... I said "kinda like" and there is no information in my post that clarifies what kind of memory I was looking at.  So jumping to a conclusion would be inappropriate.  ...Just like taking an inappropriate tone with those whom you do not know.

jtwine:

> And the semantics of the or operator (remember VB6).

Ahhh...  But I do not need
to worry about that, nor how it works in the many other languages that
I do not currently have a need for.  It is but one of the
many benefits of being a highly-paid specialist.  I am sure that
one day, you will understand.

Maybe you're one of those selfnamed (highly-paid) specialists the ends up (with his atrocities ) on theDailywtf?

Till the cold freemarket wind sweeps across the plain, and its back to shoveling dung.

 

 

zamies:

Unless you're a computer compiling shit won't help you understand it.

Well it can help.  I do it a bit with Java.  Having written a JVM from scratch in the past, I know vaguely what it does behind the scenes and what the various opcodes are and when they are generated.  However, that still doesn't really satisfy me properly because the implementations of various JVMs are all different and you just have to trust that it's doing something sensible and not be too much of a control freak about it.

When I first encountered interpreted and compiled-but-virtual languages, I didn't like them because I was a further step removed from the processor and felt uncomfortable not being able to control the processor properly.  But those sorts of things crop up in other places too.  I was used to programming in C and it is relatively easy to know how that is going to compile.  Use C++ though, and the preprocessor is doing loads behind your back and bloating your code for you. 

I thought about it and realised that if I wanted to be a complete control freak then I would really have to program in assembler because even in plain C, the optimiser can be doing strange things behind your back.  Useful, but still strange.  And also, even in assembler, you need to know your CPU inside-out to know what it's doing because CPUs contain various levels of microcode and nanocode for various instructions.

So knowing how your language is compiled can give you hints as to how efficient your algorithms will be and how much memory they will consume.  A lot of it is still up to various lower-level factors over which we have less control so keep that in mind.  Caring about it, however, is a significant step towards being a good programmer.

jtwine:

But I do not need to worry about that, nor how it works in the many other languages that I do not currently have a need for.  It is but one of the many benefits of being a highly-paid specialist.  I am sure that one day, you will understand. <snip>

  ...Just like taking an inappropriate tone with those whom you do not know.

Gasp!  A highly paid specialist that doesn't know jack... why am I not surprised??

captcha: null (maybe if I was a highly paid specialist then I would know what this means)
 

> Maybe you're one of those selfnamed (highly-paid) specialists
> the ends up (with his atrocities ) on theDailywtf?

I can honestly say that no, I have never seen my code on TDWTF...!  I have not even seen code close to it.  While I have written some (really) bad code in my younger days (some of it easily WTF-worthy!) and even being a college dropout, I do not think that "atrocity" applied since I had a VIC-20! :)

As far as the freemarket wind, remember there are companies out there that are competent enough to recognize experience and wisdom, and they will pay for it, even when the market sucks.  Trust in that when things start to look bad - there is always a position for a skilled (or better skilled) developer.  The last think a company needs when the software market sucks is to put out a poor(er)-quality product, which will only cause them to lose further sales.  That is the best time for them to spend money wisely.

Peace!

> Gasp!  A highly paid specialist that doesn't know jack... why am I not surprised??

Heh...  One might wonder just exactly how you would be aware of my body of knowledge (or not).  Not to point too fine a point on it, but I did not say that I did not know VB6 (or any other languages for that matter), I said that I do not have to worry about the ones that I do not currently have a need for.

> captcha: null (maybe if I was a highly paid specialist then I would know what this means)

Perhaps... One can hope... :)  J/K

Peace! 

i'm sorry, but i don't like the whole new "code snippet of the day" idea.  to me, the daily wtf *is* code like this, and while i like a few stories mixed in, we've had nothing *but* stories.  code is what i think should be the main diet of the daily wtf, like it used to be.

Anonymous:

jtwine:

But I do not need to worry about that, nor how it works in the many other languages that I do not currently have a need for.  It is but one of the many benefits of being a highly-paid specialist.  I am sure that one day, you will understand. <snip>

  ...Just like taking an inappropriate tone with those whom you do not know.

Gasp!  A highly paid specialist that doesn't know jack... why am I not surprised??

captcha: null (maybe if I was a highly paid specialist then I would know what this means)
 

Um, all he said was that he didn't need to know the semantics of the VB6 or operator.  He didn't actually say he didn't know it... just that it was unnecessary since he doesn't work with VB6.

 Er, wait, I mean... He suggested people who make lots of money don't write VB6!  He is TEH STUPID ELITIST!1   BURN HIMMMMM

Morbii:

Finally!  Thank you for posting code again!

 

Agreed, love the code, this is why I visit this place!
 

Anonymous:

As a novice at programming it's no surprise I don't understand everything that is said on here, but what I find very confusing is all the different answers and explainations.  A little help please.

Well, I think the community here is quite heterogeneous with respect to knowledge on coding, and on IT in general. Which is natural. No one has a full grasp of the unbounded ocean of possible IT knowledge anymore... and, of course, different life histories... As for your request for help: I think you should try to be a little bit more specific. Whence could we know what you know or not?

 When it comes down to discussions on code snippets in programming languages I don't know (or don't know well) I also often don't understand the comments. But WTF? Sometimes I learn something from them, nevertheless. And otherwise I just skip them.

Anonymous:

i'm sorry, but i don't like the whole new "code snippet of the day" idea.  to me, the daily wtf *is* code like this, and while i like a few stories mixed in, we've had nothing *but* stories.  code is what i think should be the main diet of the daily wtf, like it used to be.

So... Rather than getting a story per day which may or may not have code in it, we will be getting two stories per day, one of which is guaranteed to have code.  How is this not an improvement? 

It never ceases to amaze me when people, presented with free entertainment, feel the obligation to criticize and complain because it's not exactly what they were looking for.

Personally, I like Alex' writing - I usually get a laugh-of-the-day out of the story. The code, if present, is just an added bonus.

Cable has hundreds of channels - most with nothing of value to watch, but there is only one TDWTF!

Anonymous:

i'm sorry, but i don't like the whole new "code snippet of the day" idea.  to me, the daily wtf *is* code like this, and while i like a few stories mixed in, we've had nothing *but* stories.  code is what i think should be the main diet of the daily wtf, like it used to be.

 I have been lurking around here for several months only and don't know how TDWTF formerly was. For my taste, a good mix of stories w/o code, stories with code, WTF code snippet collections and WTF collections of codeless stuff is preferable. The problem with pure code WTFs is that often only a (rather small?) subset of people here would benefit from them. Or does anyone here know well all the programming languages that frequently occured on TDWTF so far? Whereas I daresay that everyone can profit from reading about management WTFs. And the subtitle of TDWTF is "Curious Perversions in Information Technology", after all. For me, that does include not only code, but also people, hardware, management, even politics.

Nevertheless, I admit that the assortment during the last weeks may have been a bit onesided.