Strange Exception in default Hashtable constructor

[Nick Vaughan]

While running some long term tests on our Broadcast SDK one of our
thread dropped out because an exception had been thrown:

Exception: System.Argument OutOfRangeExcep tion
Message: Load factor needs to be between 0.1 and 1.
Parameter name: loadFactor
Source: mscorlib
at System.Collecti ons.Hashtable.. ctor(Int32 capacity, Single
loadFactor, IHashCodeProvid er hcp, IComparer comparer)
at System.Collecti ons.Hashtable.. ctor()
at Codestuff.Harth ill.Sources.Bas eSource.ReadHea ders(Stream s)
at Codestuff.Harth ill.Sources.Bas eSource.ReadJpe g(Stream str, Byte[]
boundaryBytes)
at Codestuff.Harth ill.Sources.Liv eSource.VideoSt reamProc()

Now, correct me if I'm wrong but surely if I'm calling the default
constructor on such a common Framework class, I shouldn't expect to get
an Argument exception...

Has anyone else seen this or know what could be causing it?

[Nicholas Paldino [.NET/C# MVP]]

Nick,

When you use a default hashtable constructor, it assumes a load factor
of 1. However, because it uses a float for that, it might not be exactly 1
(even though it is baked into the code as 1).

This could be the result of your exception. Unfortunately, reproducing
it consistently will be extremely difficult. This is one of the dangers of
using floats...

Perhaps what you could do is create a wrapper which will catch that
exception, and retry the creation of the hashtable.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Nick Vaughan" <ni**@codestuff .net> wrote in message
news:11******** *************@g 43g2000cwa.goog legroups.com...

While running some long term tests on our Broadcast SDK one of our
thread dropped out because an exception had been thrown:

Exception: System.Argument OutOfRangeExcep tion
Message: Load factor needs to be between 0.1 and 1.
Parameter name: loadFactor
Source: mscorlib
at System.Collecti ons.Hashtable.. ctor(Int32 capacity, Single
loadFactor, IHashCodeProvid er hcp, IComparer comparer)
at System.Collecti ons.Hashtable.. ctor()
at Codestuff.Harth ill.Sources.Bas eSource.ReadHea ders(Stream s)
at Codestuff.Harth ill.Sources.Bas eSource.ReadJpe g(Stream str, Byte[]
boundaryBytes)
at Codestuff.Harth ill.Sources.Liv eSource.VideoSt reamProc()

Now, correct me if I'm wrong but surely if I'm calling the default
constructor on such a common Framework class, I shouldn't expect to get
an Argument exception...

Has anyone else seen this or know what could be causing it?

[Nick Vaughan]

Hi Nicholas,

Thanks for your reply.

How can a float which is 1.0 not always be 1.0? I would have though
it's a constant value.

Are you suggesting that once in a while, this constructor is just going
to fling an exception? That sounds like quite a serious issue doesn't
it?

Could it be that the default constructor tries to modify the loadfactor
based on the amount of available memory?

Am I required to put a try-catch block around every call to 'new
Hashtable( )' ??

Cheers,

Nick.

[Jon Skeet [C# MVP]]

Nicholas Paldino [.NET/C# MVP] wrote:

When you use a default hashtable constructor, it assumes a load factor
of 1. However, because it uses a float for that, it might not be exactly 1
(even though it is baked into the code as 1).

If it's baked into the code as 1, it should be exactly 1. 1 is exactly
representable in all the various floating point formats .NET has.

I can't think of any floating point conversion that would corrupt that,
or give a false comparison with another value of exactly 1.

This is very odd...

Jon

[Nicholas Paldino [.NET/C# MVP]]

Jon,

How about a cast from double to float?

When looking at the code in reflector, it's the only thing I could think
of that would cause this.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

Nicholas Paldino [.NET/C# MVP] wrote:

When you use a default hashtable constructor, it assumes a load
factor
of 1. However, because it uses a float for that, it might not be exactly
1
(even though it is baked into the code as 1).

If it's baked into the code as 1, it should be exactly 1. 1 is exactly
representable in all the various floating point formats .NET has.

I can't think of any floating point conversion that would corrupt that,
or give a false comparison with another value of exactly 1.

This is very odd...

Jon

[Jon Skeet [C# MVP]]

Nicholas Paldino [.NET/C# MVP] wrote:

How about a cast from double to float?
Certainly wouldn't change 1.0 to anything else, because it's exactly
representable in both forms. At least, it would only break things if
something was seriously broken in the conversion :)

(None of the 80-bit to 32/64-bit conversions should break 1.0 either.
It's one of the simplest bit patterns for floating point numbers that
you can get...)
When looking at the code in reflector, it's the only thing I could think
of that would cause this.

That's reasonable - I just can't see how it would possibly fail.

I suspect either a hardware failure or a problem deep inside the CLR...

Jon

[Nick Vaughan]

Well, it just happened again this evening:

Exception: System.Argument OutOfRangeExcep tion
Message: Load factor needs to be between 0.1 and 1.
Parameter name: loadFactor
Source: mscorlib
at System.Collecti ons.Hashtable.. ctor(Int32 capacity, Single
loadFactor, IHashCodeProvid er hcp, IComparer comparer)
at System.Collecti ons.Hashtable.. ctor()
at Codestuff.Harth ill.Sources.Bas eSource.ReadHea ders(Stream s)
at Codestuff.Harth ill.Sources.Bas eSource.ReadJpe g(Stream str, Byte[]
boundaryBytes)
at Codestuff.Harth ill.Sources.Liv eSource.VideoSt reamProc()

To be honest, I'm going to refactor this code anyway as I don't really
like the idea of create a new hashtable 30 times a second!! However,
its an interesting bug with the framework I think. Its unlikely to be
hardware as it has happened on 2 separate and quite different machines.

Hopefully someone will be able to track this one down and fix it!!

Thanks for your responses people.

Nick.

[Bruce Wood]

This is a long shot, but does it happen only on one particular machine?
Have you tried running a utility to thrash that machine's memory to
make sure that it's OK? One of the guys in my office swears that these
oddball bugs are occasionally the result of bad memory.

[Jon Skeet [C# MVP]]

Nick Vaughan wrote:

Well, it just happened again this evening:

Exception: System.Argument OutOfRangeExcep tion
Message: Load factor needs to be between 0.1 and 1.
Parameter name: loadFactor
Source: mscorlib
at System.Collecti ons.Hashtable.. ctor(Int32 capacity, Single
loadFactor, IHashCodeProvid er hcp, IComparer comparer)
at System.Collecti ons.Hashtable.. ctor()
at Codestuff.Harth ill.Sources.Bas eSource.ReadHea ders(Stream s)
at Codestuff.Harth ill.Sources.Bas eSource.ReadJpe g(Stream str, Byte[]
boundaryBytes)
at Codestuff.Harth ill.Sources.Liv eSource.VideoSt reamProc()

To be honest, I'm going to refactor this code anyway as I don't really
like the idea of create a new hashtable 30 times a second!!
Well, I wouldn't worry about that. 30 new hashtables in a second is
barely going to catc your computer's attention. I very quick
micro-benchmark I just wrote showed my desktop being able to create
about 8 *million* new hashtables in a second. Go for the simplest code
which works and which doesn't give you a *definite* performance
problem.
However, its an interesting bug with the framework I think. Its unlikely to be
hardware as it has happened on 2 separate and quite different machines.

This is an odd suggestion, but are these machines by any chance using
the same anti-virus software? Try disabling the AV software, reboot,
and try again. I've seen some AV software changing the floating point
mode of a computer, and that can have some odd effects. I can't see why
it would be a problem here, but it's possible. If that's not it, could
you tell us anything else which the two computers have in common?

Jon

[Nick Vaughan]

They are both running the same AV software, I'll run the tests again
tonight with it turned off and report back. There does seem to be
something happening with the network around the time of the exception
being thrown so this could tie in.

Cheers,

nick.