Java code generation for monster.fbs causes segmentation fault.

[hyunsik]

how to reproduction:

Currently, flatc does not seem to understand relative paths. So, I've copied monster.fbs from sample to source root. Then, I executed flatc as follows:

hyunsik@Hyunsiks-MacBook-Pro:flatbuffers$ ./flatc -j monster.fbs 
Segmentation fault: 11

LLDB debugging result:

(lldb) run -j monster.fbs
Process 85655 launched: './flatc' (x86_64)
Process 85655 stopped
* thread #1: tid = 0x101ba30, 0x00000001000730f2 flatc`flatbuffers::java::GenStructArgs(struct_def=0x0000000100204380, code_ptr=0x00007fff5fbfe5b8, nameprefix=0x00007fff5f4006f1) + 530 at idl_gen_java.cpp:127, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3fffa8)
    frame #0: 0x00000001000730f2 flatc`flatbuffers::java::GenStructArgs(struct_def=0x0000000100204380, code_ptr=0x00007fff5fbfe5b8, nameprefix=0x00007fff5f4006f1) + 530 at idl_gen_java.cpp:127
   124         it != struct_def.fields.vec.end();
   125         ++it) {
   126      auto &field = **it;
-> 127      if (IsStruct(field.value.type)) {
   128        // Generate arguments for a struct inside a struct. To ensure names
   129        // don't clash, and to make it obvious these arguments are constructing
   130        // a nested struct, prefix the name with the struct name.
(lldb) p field.value.type
(flatbuffers::Type) $0 = {
  base_type = BASE_TYPE_FLOAT
  element = BASE_TYPE_NONE
  struct_def = 0x0000000000000000
  enum_def = 0x0000000000000000
}

[ghost]

regarding relative paths, what is the problem? There's commits on July 2 &
21 related to path handling, are you up to date?

As for your call stack, I can't tell why it is crashing, the line it is
pointing at should not crash with the given type.

If you are using the unmodified monster.fbs in samples, I can run:
./flatc -j samples/monster.fbs
without crashing. Same if I first copy the fbs file to the parent dir. Tested on Linux & OS X.