[jira] Resolved: (HARMONY-3117) [db2] IBM DB2 JDBC "sample apps" crash on exit

["Gregory Shimansky (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gregory Shimansky resolved HARMONY-3117.
----------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0M4
         Assignee: Gregory Shimansky

Well, if I understood the bug cause, it had to be Linux x86_64 specific, so testing on x86 doesn't help. It is on x86_64 where stack unwinding at thread interruption or C++ exception is done in some way that causes gcc code in libunwind to traverse all the stack of the thread, including possibly unmapped code. On x86 this doesn't happen, probably because not all of the stack is traversed to the bottom, or maybe stack unwinding at thread interruption point (this usually happens at VM shutdown when it kills running threads) doesn't use C++ unwinding at all. This is the reason why problems with unclean shutdown happened only on Linux x86_64.

Also, since I tried to reproduce this bug on SLES10 x86_64 and Gentoo x86_64, the bug seems to be RHEL specific. I don't mean that they behave differently, just it is probably that on RHEL the bug happened more often due to unknown reasons, like different pthreads version probably. I am talking in guesses because libunwind code is GPLed, and I read as minimum of it as it was necessary to understand the cause of this type of crash in HARMONY-5019.

As far as I know, this library unmapping problem has to be fixed, so I am closing this bug. If something like this happens again, I'll make a closer inspection, now that I have the knowledge of the cause of such crashes.

As for character conversion, I don't know for sure. Recently class library migrated from ICU v4 to ICU v6 and there were many changes in this area. I wonder if DB2 has some logs of Java exceptions so that it would be possible to understand what Java API it is using. In any case a bug report would be welcome.

> [db2] IBM DB2 JDBC "sample apps" crash on exit
> ----------------------------------------------
>
>                 Key: HARMONY-3117
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3117
>             Project: Harmony
>          Issue Type: Bug
>          Components: App-Oriented Bug Reports
>         Environment: EM64T -- RedHat Enterprise Linux 4 - U4
> IBM DB2 Express-C version9.1 
> Latest Harmony JRE binary download (vn = r487452, (Dec 15 2006), Linux/em64t/gcc 4.0.3, release build)
>            Reporter: Chris Elford
>            Assignee: Gregory Shimansky
>            Priority: Critical
>             Fix For: 5.0M4
>
>         Attachments: db2-setup.zip
>
>
> Putting critical because critical is defined as "Crashes, loss of data, severe memory leak."
> I was experimenting with whether DB2 JDBC connection will work with Harmony.    I am using the sample apps that come with DB2.  The JDBC layer appears to connect to the database successfully (which is good for Harmony) and queries appear to work (data comes thru).   However, during shutdown of the sample apps, the process regularly segfaults when using Harmony and exits cleanly using the BEA JRE and Sun JRE.
> crash behavior is consistent with both "java DbConn" (basic connection test) and "java TbSel" (basic sql select test) sample apps that come with the "free" version of DB2.
> unfortunately, the core file provides little insight.  
> (gdb) bt
> #0  0x0000002aaf5898fa in ?? ()
> #1  0x0000000000000000 in ?? ()
> (gdb) info threads
> * 1 process 22262  0x0000002aaf5898fa in ?? ()
> Attaching with debugger gives a possible hint:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000002aaf5898fa in OSSHLibrary::unload ()
>    from /home/db2inst/sqllib/lib64/libdb2osse.so.1
> (gdb) bt
> #0  0x0000002aaf5898fa in OSSHLibrary::unload ()
>    from /home/db2inst/sqllib/lib64/libdb2osse.so.1
> #1  0x0000002aacce93de in sqlexPluginUnload ()
>    from /home/db2inst/sqllib/lib64/libdb2.so.1
> #2  0x0000002aad1dd080 in sqlexAppLibTerm ()
>    from /home/db2inst/sqllib/lib64/libdb2.so.1
> #3  0x0000002aacc41afa in sqlmStreamFlagsAction ()
>    from /home/db2inst/sqllib/lib64/libdb2.so.1
> #4  0x0000002aacc41b83 in _ZN10appLibInitD9Ev ()
>    from /home/db2inst/sqllib/lib64/libdb2.so.1
> #5  0x0000002aacc41b73 in appLibInit::~appLibInit ()
>    from /home/db2inst/sqllib/lib64/libdb2.so.1
> #6  0x000000380df30c45 in exit () from /lib64/tls/libc.so.6
> #7  0x000000380df1c402 in __libc_start_main () from /lib64/tls/libc.so.6
> #8  0x000000000040096a in _start () at ../sysdeps/x86_64/elf/start.S:113
> It looks to me that the C++ destructors registered by some presumably JNI components are being invoked by the C runtime at process exit.  At this time there are no other threads remaining (i.e., java looks like it is done and gone) and presumably during the cleanup process something gets out of control.
> In contrast with the Sun Java5 JRE, there are 13 other threads remaining when the destructor runs and 12 other threads with the BEA Java5 JRE.
> I'm  not sure if this is a compatibility issue with the reference implementation or if is simply a hole in the JNI support that Harmony currently provides.  It appears to be 100% reproducable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.