Monday, April 23, 2012

When GlassFish Stomps On Your JSON

Funny thing about learning new technologies and stacks, you run into all kinds of hard to diagnose problems. Here's one that I ran into that took a few days to figure out.

The Problem

The stack I'm working on right now is a Backbone front end with a Grails back end running on Glassfish. The thing about Backbone is since everything is in Javascript, you do a lot of jQuery calls to get/update content. One of the things to consider when doing that is error handling.

In one of my Backbone views, I'm issuing an update via a button click. This sends a post up to the server and if there's a problem, it's supposed to return some JSON as an error:

If there's an error, it gets handled by a utility written to handle errors from the Grails stack:

I was testing the error handling which worked fine on my box but when it would get deployed to GlassFish, the errors weren't happening. I looked at the response coming back from the server and the JSON was in it but right behind it was this big chunk of HTML from GlassFish:

So what the hell? Now GlassFish has decided in its infinite wisdom to add to my JSON? I searched and searched for some kind of setting to change to make it not do that. Guess what, didn't find it. The controller code I was calling to was simple enough:

Why wasn't it just giving me the JSON? Also, why was it working through the Grails stack on my box?

Select Isn't Broken

Turns out I need to learn more about HTTP content headers. I gave up on configuring GlassFish, walked away from the problem for a while and then one day it dawned on me: in Grails, if you use render without specifying the content type it's just going to assume you're sending HTML. I made one minor tweak by specifying the content type and boom, no GlassFish in my JSON:

Hope this helps someone.

Thursday, March 29, 2012

Stack Buffer Overrun Killed My CLR!

So I ran into an interesting problem the last few days. And by ran into I mean made me lose more hair than I have already lost! It took quite a bit of research and I thought I'd help the Internet by sharing what I ran into.

The Problem

We've been working on a new version of our product that was originally built on .Net 3.5 but has been migrated to .Net 4.0. Part of that application does a DllImport on some unmanaged code which has worked great in .Net 3.5.

Now that we're using .Net 4.0 the method that uses that DllImport is crashing. And I mean crashing HARD. There's a try/catch around the method call but it's not getting that far. There's no minidump to be seen, but there is an entry in the Windows event log:

Faulting application name: MyAppService.exe, version:, time stamp: 0x4f738b08
Faulting module name: clr.dll, version: 4.0.30319.239, time stamp: 0x4e181a6d
Exception code: 0xc0000409
Fault offset: 0x002b60d0
Faulting process id: 0x15b8
Faulting application start time: 0x01cd0dc5e21cf6a0
Faulting application path: C:\Program Files (x86)\MyCompany\MyAppService.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 5453534c-79b9-11e1-8970-000c29dad353


Wow. The freaking CLR died. No wonder no exception was caught. I looked up the exception code and it said that it was a Stack Buffer Overrun exception.

Stack buffer overrun? Can that happen in .Net? No, not really, but I was calling into unmanaged code which led me to believe that the unmanaged code was bad. Of course, if that code was bad, why did it work when .Net 3.5 was calling it?

Looking through I found a few things. Apparently stack buffer overrun protection has been in place in Windows for unmanaged code for a while but was ignored until .Net 4.0. I can't say for sure that this is why I'm running into problems but seems likely.

The Solution

Then I ran across this and this that talk about changing the calling convention from __declspec to __stdcall. At first I didn't think much of it because this was all C++ code and I was dealing with .Net. And then it hit me, that DllImport is using Cdecl isn't it? So then I changed the CallingConvention to use the StdCall and things started to magically work!

I wish I knew all the technical details about why this made things work but if this helps someone else out, I'll be happy enough.

Wednesday, March 21, 2012

Utah Code Camp Spring 2012

So check it out, I actually spoke at a code camp. I've always thought about speaking at code camp but I've never felt authoritative enough about anything to speak on it. Well, not anything interesting anyway. A few friends of mine finally coaxed me into taking the plunge and I totally survived.

I've been doing a lot of work with Mercurial at work lately so I decided to speak about how great it is and how it's totally viable as a version control system for both personal and work use. I didn't have the biggest audience in the world but I was able to fill up the time and was even able to field a few questions. It was stressful, exhilarating and I totally need to do it again.

I decided to do the slide deck through Google docs (which was pretty brave on my part as the wireless was brought to its knees during the conference). I don't regret it as it's easy to share and reference later. Anyway, here they are if you're interested, I included fairly detailed notes on each slide so if you missed my session, you can see what I talked about.