Crash Java7 with JsonIOUtil.toByteArray

[Google Code Exporter]

What steps will reproduce the problem?
1. Create an annotated prostuff pojo using @Tag
2. Register pojo
3. In unit test create null instance of the object (MyTestObject mto = null)
4. Try to convert it to bytearray: JsonIOUtil.toByteArray(mto, mtoSchema, false)
5. Watch your JVM go up in flames


What is the expected output? What do you see instead?
I expect an error or an empty byte array.  Instead the JVM crashed with a fatal 
error.

What version of the product are you using? On what operating system?
# JRE version: 7.0_07-b11
# Java VM: Java HotSpot(TM) Client VM (23.3-b01 mixed mode, sharing windows-x86 
)


Please provide any additional information below.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5f2877bd, pid=3808, tid=8316
#
# JRE version: 7.0_07-b11
# Java VM: Java HotSpot(TM) Client VM (23.3-b01 mixed mode, sharing windows-x86 
)
# Problematic frame:
# V  [jvm.dll+0x1177bd]

Original issue reported on code.google.com by [e-mail] on 6 May 2013 at 10:15

[Google Code Exporter]

Unsafe.getXXX is the one barfing that when the message is null.
Serializing a null is invalid, so the null-protection could either be in the IO 
utils or your code.

Just like the generated schema (null protection not in the library, but in the 
generated code), it's better you check null before you use any of the IO utils.

Original comment by [e-mail] on 29 May 2013 at 11:23

[Google Code Exporter]

I have at this point wrapped your libraries to make sure they are safe.

I have to say it find odd that you would be fine building a library that would 
allow an end user to crash their JVM.  Also keep in mind that it crashes in a 
way that does not leave a user with a stack trace to find out why their JVM has 
crashed.  A middle of the road developer would not be able to track this down.

Your are making a design decision that allows users to crash their JVM in a way 
that leaves them totally in the dark as to why.  Seems like a hard to defend 
design decision to me.

Original comment by [e-mail] on 30 May 2013 at 2:59

[Google Code Exporter]

I can probably add this line in all of the IO utils.
if(message == null) throw new NullPointerException();

Original comment by [e-mail] on 30 May 2013 at 3:16

• Changed state: Accepted