Minecraft java.lang.OutOfMemoryError

My son tried to launch Minecraft recently.   For some reason it's stopped working and shows java.lang.OutOfMemoryError  when he tries to launch it.  The full error being the following

java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3332) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:569) at java.lang.StringBuilder.append(StringBuilder.java:190) at com.google.gson.stream.JsonReader.nextQuotedValue(JsonReader.java:1003) at com.google.gson.stream.JsonReader.nextString(JsonReader.java:815) at com.google.gson.internal.bind.TypeAdapters$16.read(TypeAdapters.java:418) at com.google.gson.internal.bind.TypeAdapters$16.read(TypeAdapters.java:406) at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41) at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:82) at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) at

The fix:  Clean up Minecraft\installs\options.txt by removing any entries that looked bad.

The explanation:

Searching the internet didn't provide much help other than 'reinstall'.  Rather than risk losing saves, I poked around some of the files and was able to fix it.  I noticed the file Minecraft\installs\options.txt was 300MB.  This seemed a little large for a txt file that was supposed to be options.  Looking through the file there are a bunch of key:value entries.  One of them called 'resourcePacks' had a value that looked like 300MB of garbage.  Looking at Options.txt  said these should be readable names.   Since it was random non-printable characters, I removed the whole 300MB entry.  Minecraft now loads just fine.

Seems Minecraft was choaking on trying to load of 300MB of resourcePack names.  StringBuilder was called to keep appending and ran of of room.  After all a 300MB string is rather large.

Common Source Code Directories

I placing this here to keep a list of common source code directories and their uses.  I'll update this periodically

• src - Compiled source code
• include - Header files
• deps - External dependencies, or ".d" dependency files
• .deps - .d dependency files
• build - build scripts
• dist - distribution files.  Final compiled files
• debug - files compile in debug mode
• release - files compiled in release mode
• obj(s) - Compiled object files
• bin - Binaries, or compiled executable
• lib - library files (so, a, dll, lib), either external or compiled
• test(suite) - test suite code
• externs/ext - External dependencies
• contrib - external dependencies, or additional code not officially part of the main line
• patches - patch files to apply to build
• tools - tools used in build, but not necessarily part of final project
• doc - documents
• res - resources

Some source trees include directories for each file type, such as css, js, xml

How to fix Battle.net App video playback

Blizzard has a Battle.net desktop app for their games.  Its supposed to support video playback, but it
seems its a common bug to lose video playback in the battle.net desktop app.

Instead of a video, just a black window that says "The Adobe Flash Player or an HTML5 supported browser is required for video playback" shows up.

After re-installing my computer I was hit with this bug.  I had a HTML5 supported browser. (chrome), and I tried installed firefox, but this did not fix it. Since battle.net uses CEF (Chromium Embedded Framework), I assumed getting flash for Chrome (PPAPI) would fix it.   I then tried the other versions for Firefox and Internet explorer.  None of these fixed it.

What finally fixed it was this link, that explained to install the version of flash found at
https://get.adobe.com/flashplayer/?fpchrome, I'm not exactly sure what version this is suppsoed to be, because I can't find a link to it on adobes site, but it works.

container_of and offsetof in C++

I'm just putting this here for future reference

Linux uses a macro called container_of in kernel

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
#define container_of(ptr, type, member) ({                      \
      const typeof(((type *)0)->member) * __mptr = (ptr);     \
      (type *)((char *)__mptr - offsetof(type, member)); })

BSD has one

#define CONTAINING_RECORD(addr, type, field)    \
      ((type *)((vm_offset_t)(addr) - (vm_offset_t)(&((type *)0)->field)))

and so does windows

#define CONTAINING_RECORD(address, type, field) ((type *)( \
                                              (PCHAR)(address) - \
                                              (ULONG_PTR)(&((type *)0)->field)))

( These were all found at http://stackoverflow.com/questions/8240273/a-portable-way-to-calculate-pointer-to-the-whole-structure-using-pointer-to-a-fi )

I've written the linux version as a C++ template.

template<class P, class M>
size_t offsetof(const M P::*member)
{
    return (size_t) &( reinterpret_cast<P*>(0)->*member);
}

template<class P, class M>
P* container_of(M* ptr, const M P::*member)
{
    return (P*)( (char*)ptr - offsetof(member));
}

This has the added benefit of being able to 'step-into' the function, unlike a macro call.  But this also requires it to be done in C++, and not C.

In C you would call the macro        container_of( pointer, Foo, bar)
In C++ you would call the function container_of( pointer,  &Foo::bar )

Microsoft Visual C memory segments

If you look in a file called Microsoft Visual Studio\VC\crt\src\sect_attribs.h you'll see a list of #pragma's for section attributes.  This is here to define memory segments in your compiled software.   After a little searching on the internet I wasn't able to find a list of what each of this segments were for.  Poking around the rest of the CRT source was able to give me some clues.


#pragma section(".CRTMP$XCA",long,read)
#pragma section(".CRTMP$XCZ",long,read)
#pragma section(".CRTMP$XIA",long,read)
#pragma section(".CRTMP$XIZ",long,read)

#pragma section(".CRTMA$XCA",long,read)
#pragma section(".CRTMA$XCZ",long,read)
#pragma section(".CRTMA$XIA",long,read)
#pragma section(".CRTMA$XIZ",long,read)

#pragma section(".CRTVT$XCA",long,read)
#pragma section(".CRTVT$XCZ",long,read)

These sections are used for initializers of globals when you are building a managed binary.  The $XI are C initializes while the $XC are C++ initializers.   The MP means managed per process, while the MA means managed per app domain.  The VT stands for VTABLE, in other words your virtual method initializers.  I found this all in crt\src\mstartup.cpp.   Something interesting is the C initializers are never called.

#pragma section(".CRT$XCA",long,read)
#pragma section(".CRT$XCC",long,read)
#pragma section(".CRT$XCZ",long,read)
#pragma section(".CRT$XIA",long,read)
#pragma section(".CRT$XIC",long,read)
#pragma section(".CRT$XID",long,read)
#pragma section(".CRT$XIY",long,read)
#pragma section(".CRT$XIZ",long,read)

These sections are used for native initializers. Like before $XI are C while $XC are C++ initializers.  The XCC section is the list of C++ initializers and the XIC are the C initializers.  The XID and XIY seems to be a special sections of C initializers that are to be run after all the C initializers

#pragma section(".CRT$XCAA",long,read)
#pragma section(".CRT$XIAA",long,read)

These sections are for native PRE-initializers.  That is, they are run before the above initializers.

#pragma section(".CRT$XPA",long,read)
#pragma section(".CRT$XPB",long,read)
#pragma section(".CRT$XPX",long,read)
#pragma section(".CRT$XPXA",long,read)
#pragma section(".CRT$XPZ",long,read)
#pragma section(".CRT$XTA",long,read)
#pragma section(".CRT$XTB",long,read)
#pragma section(".CRT$XTX",long,read)
#pragma section(".CRT$XTZ",long,read)

These are C terminators (read destructors), that get called on exit.  $XP are pre-terminators, and $XT are normal terminators.

#pragma section(".CRT$XDA",long,read)
#pragma section(".CRT$XDC",long,read)
#pragma section(".CRT$XDL",long,read)
#pragma section(".CRT$XDU",long,read)
#pragma section(".CRT$XDZ",long,read)

These are used for Thread Local Storage dynamic initializers.  You can find a detailed explanation in crt\src\tlsdyn.c.

#pragma section(".CRT$XLA",long,read)
#pragma section(".CRT$XLC",long,read)
#pragma section(".CRT$XLD",long,read)
#pragma section(".CRT$XLZ",long,read)

These seem to be for bootstrapping for Thread Local Storage.  From a comment in src\crt\tlssup.c
/* Start section for TLS callback array examined by the OS loader code.
 * If dynamic TLS initialization is used, then a pointer to __dyn_tls_init
 * will be placed in .CRT$XLC by inclusion of tlsdyn.obj.  This will cause
 * the .CRT$XD? array of individual TLS variable initialization callbacks
 * to be walked.
 */
If I understand this correctly, it means that if you have Thread Local Storage enabled, a pointer to __dyn_tls_init will be placed in .CRT$XLC, which should cause it to be called and your TLS to be initialized as needed.  The XLD points to _dyn_tls_dtor, which calls the destructors for Thread Local Storage.

For an explanation on what these sections are used for read this blog

Floating point accuracy

Here are two pieces of code that do that same thing, but produce different results

This one doesn't work

            double majorTickStart = majorStep * Math.Floor(min / majorStep);
            double majorTickEnd = majorStep * Math.Floor(max / majorStep);
            for (double x = majorTickStart; x <= majorTickEnd; x += majorStep)
            {
                Point p1 = new Point((x - min) * scale, 0);
                Point p2 = new Point((x - min) * scale, 16);
                drawingContext.DrawLine(majorTickPen, p1, p2);
            }

This one does work

            double majorTickStart = majorStep * Math.Floor(min / majorStep);
            double majorTickEnd = majorStep * Math.Floor(max / majorStep);
            double majorSteps = (majorTickEnd - majorTickStart);
            for (double x = 0; x <= majorSteps; x += majorStep)
            {
                double _x = (x + (majorTickStart - min)) * scale;
                Point p1 = new Point(_x, 0);
                Point p2 = new Point(_x, 16);
                drawingContext.DrawLine(majorTickPen, p1, p2);
            }


If you look closely that math turns out to be the same on both of them.  What this is meant to do is draw the tick marks you would see on a graph along the axis.   The first two lines compute the offsets of where to start and stop drawing tick marks, since the beginning value, "min", doesn't necessarily start on a boundary.   Next the for loop will iterate between those two values with a step size of, "majorStep".  This would normally be a power of 10.  

The problem the happens is the first set of code turns into an infinite loop under certain conditions.  If "majorsStep" is small compared to the start and end values, x will never increase.  "small" means that there is more than 52bits of precision between the two of them.  In other words a factor of more that 4503599627370496.   This has to do with how a computer stores an IEEE754 (64 bit double) number.  It stores it using 1 bit sign, 11bit exponent , and 52bit fractional.   To get the number it represents 2 raise to the power of the exponent times the fractional bits.   Stated another way the exponent is the number of bits that are ignored.  If it takes more than 52 bits to represent the number, you will lose the lower E bits of accuracy.    Adding 1 to your 53 bit number will result in the lowest bit being ignore, and this the 1 turns into a 0.


How do you fix this?  Make sure you do all your math with numbers that are close to each other.  The second one works because we start "x" at 0 and add the small value of "majorStep" to it.  We also subtract "min" from "majorTickStart" to get a small value before we add it to x, which will also be small.  If we tried to add "x" to "majorTickStart" and then subtract "min" we would end up with just "majorTickStart - min", because the value in x would be ignored.

CableCards and Tuning Adapters

I've been using my Ceton turner card for a while now and its been pretty nice.  Being able to DVR multiple shows and once is very nice.  The only problem I've had so far, is that some channels will not tune some times.

tl;dr - Tuning adapters case 99% of the problems

I wake up in the morning with a notice that it wasn't able to record my sons cartoon because the channel couldn't be found.  To Cetons credit it is NOT their fault.  Its actually Time Warner's fault.  They use SDV (switch digital video) on a lot of their channels.  To receive SDV channels Time Warner gives you a "tuning adapter".  Its a small box that plugs into your computer through USB and your cable line.  The computer queries the tuner adapter for the frequency of a given channel and the tuning adapter does it magic and tells the computer where it can find the channel.  The problem is these adapters seem to have MANY, MANY problems.  Some times they don'y sync up to the cable company and suddenly you can not use half of your channels.