You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Alexey Petrenko (JIRA)" <ji...@apache.org> on 2007/03/30 12:03:25 UTC

[jira] Resolved: (HARMONY-3529) [jdktools][build] fix GCC problem with handling C++ exceptions

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

Alexey Petrenko resolved HARMONY-3529.
--------------------------------------

    Resolution: Fixed

The patch has been applied.
Please verify.

> [jdktools][build] fix GCC problem with handling C++ exceptions
> --------------------------------------------------------------
>
>                 Key: HARMONY-3529
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3529
>             Project: Harmony
>          Issue Type: Bug
>          Components: JDK
>         Environment: Linux/x86, Harmony-jdk-r523977
>            Reporter: Ivan Popov
>         Assigned To: Alexey Petrenko
>         Attachments: jdktools_linux_build.patch
>
>
> After fix for jdktools in HARMONY-3429 has been applied, I see JPDA tests failures on Linux. The problem is in handling C++ exceptions thrown in JDWP agent code:
> STDERR> SIGSEGV in VM code.
> STDERR> Stack trace:
> STDERR> 0: parse_lsda_header(_Unwind_Context*, unsigned char const*, lsda_header_info*) (??:-1)
> STDERR> 1: __gxx_personality_v0 (??:-1)
> STDERR> 2: _Unwind_RaiseException (??:-1)
> STDERR> 3: __cxa_throw (??:-1)
> STDERR> 4: jdwp::ArrayReference::GetValuesHandler::Execute(JNIEnv_External*) (??:-1)
> STDERR> 5: jdwp::SyncCommandHandler::Run(JNIEnv_External*, jdwp::CommandParser*) (??:-1)
> STDERR> 6: jdwp::CommandDispatcher::ExecCommand(JNIEnv_External*, jdwp::CommandParser*) (??:-1)
> STDERR> 7: jdwp::PacketDispatcher::Run(JNIEnv_External*) (??:-1)
> STDERR> 8: jdwp::PacketDispatcher::StartFunction(jvmtiEnv_struct*, JNIEnv_External*, void*) (??:-1)
> STDERR> 9: wrapper_proc (??:-1)
> STDERR> 10: thread_start_proc (??:-1)
> STDERR> 11: start_thread (??:-1)
> STDERR> 12: clone (??:-1)
> STDERR> <end of stack trace>
> This is reproduced on 32-bit Linux SLES9 with GCC 3.3.3. It is not reproduced on SLES10 with GCC 4.1.0.
> The problem is that '-fpic' option is not now specified for building native code on 32-bit Linux platform. Adding '-fpic' option resolves this problem, and tests work well on both SLES9 and SLES10.

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