Created attachment 114079 [details]
full bt at sigsegv

under lldb, one can recover from the sigsegv and continue, the ouput is then :
(lldb) c
Process 66590 resuming
warn:sw.resizeview:66590:1:sw/source/core/view/vdraw.cxx:237: Trying to move anchor from invalid page - fix layouting!
warn:sw.resizeview:66590:1:sw/source/core/view/vdraw.cxx:237: Trying to move anchor from invalid page - fix layouting!

Open 3rd form in list of forms :

lldb output :

java.lang.IncompatibleClassChangeError
java.lang.IncompatibleClassChangeError
warn:legacy.osl:66590:16:connectivity/source/drivers/jdbc/JStatement.cxx:669: caught an exception!
in function:virtual sal_Bool connectivity::java_sql_Statement_Base::convertFastPropertyValue(com::sun::star::uno::Any &, com::sun::star::uno::Any &, sal_Int32, const com::sun::star::uno::Any &)
type: com.sun.star.lang.WrappedTargetRuntimeException
message: java.lang.IncompatibleClassChangeError

Clicking in the lower controls containing lists causes LO to freeze :
Process 66590 stopped
* thread #37: tid = 0x6a4e8, 0x000000012983bc2f, stop reason = signal SIGSEGV
    frame #0: 0x000000012983bc2f
-> 0x12983bc2f:  movl   0x8(%rsi), %r11d
   0x12983bc33:  cmpl   $0xc, %edx
   0x12983bc36:  je     0x12983bdba
   0x12983bc3c:  movabsq $0x7802e2370, %rdx
(lldb)

Created attachment 114083 [details]
Full bt navigating Form 3

No problem to open the forms with OpenSUSE 13.2 and
Version: 4.5.0.0.alpha0+
Build ID: 468677c9f5fbdb91f0817674d1c7765e971e4df1
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-13_01:03:55

Alex: what precise Java version is installed? (32/64 bits, 1.6, 1.7 ?). Also, what's your precise version of MacOs?

Stephan: noticing message: java.lang.IncompatibleClassChangeError, I wonder if it could be a Java version problem or a special Apple package which should be installed.

(In reply to Alex Thurgood from comment #1)
> Created attachment 114079 [details]
> full bt at sigsegv

This looks like one of these internal SIGSEGVs of Java, which Java handles (through its exception mechanism) and are thus normal.

(In reply to Alex Thurgood from comment #4)
> Created attachment 114083 [details]
> Full bt navigating Form 3

Same thing: internal Java SIGSEGV, nothing out of the ordinary.

(In reply to Alex Thurgood from comment #3)
> Open 3rd form in list of forms :

> java.lang.IncompatibleClassChangeError
> java.lang.IncompatibleClassChangeError

This is a real problem. Incomplete recompile? Try "make clean" and recompile. If still reproducible, then we have a bug.

(In reply to Lionel Elie Mamane from comment #9)
> (In reply to Alex Thurgood from comment #3)
> > Open 3rd form in list of forms :
> 
> > java.lang.IncompatibleClassChangeError
> > java.lang.IncompatibleClassChangeError
> 
> This is a real problem. Incomplete recompile? Try "make clean" and
> recompile. If still reproducible, then we have a bug.

This was a fresh build after make clean.

FWIW, the JDK is latest Oracle Java 1.8u40

The traces contain mismatch w

(In reply to Alex Thurgood from comment #11)
> The traces contain mismatch w

Ignore that last comment.

(In reply to Alex Thurgood from comment #3)
> Open 3rd form in list of forms :
[...]
> java.lang.IncompatibleClassChangeError
[...]

With my --enable-dbgutil master build on Mac OS X 10.10.2 with JDK 1.8.0_25 I can reproduce the "IncompatibleClassChangeError" etc. reporting on stderr (but no crash).

The reason is connectivity/source/drivers/jdbc/JStatement.cxx

> sal_Int32 java_sql_Statement_Base::getResultSetType() throw(SQLException, RuntimeException)
> {
>     static jmethodID mID(NULL);
>     return impl_getProperty("getResultSetType",mID,m_nResultSetType);
> }

using a static jmethodID.  If this function first gets called on a java_sql_PreparedStatement derivation instance (where getMyClass() obtains the java.sql.PreparedStatement interface deriving from java.sql.Statement) and then on a java_sql_Statement derivation instance (where getMyClass() obtains the java.sql.Statement interface), at least the given JDK version rejects the java.sql.Statement.getResultSetType JNI call via the static stored java.sql.PreparedStatement.getResultSetType jmethodID with a java.lang.IncompatibleClassChangeError.

Removing the "static" from "static jmethodID mID(NULL);" would make that go away.  However, that would likely cause a performance regression, and lots of other places in JStatement.cxx (and probably elsewhere) use the same broken idiom, too.  What is rather needed is to redesign the connectivity/source/inc/java/lang/Object.hxx etc. code to properly cache matching class/method pairs.

Following last Stephen's comment, I put tdf#57872 in See Also

Version: 5.0.0.0.alpha1+
Build ID: 950055bcb06c8edcd9062c71184f02bf8e0604e6

now wfm