Re: Question about a comment in _Jv_StackTrace::UnwindTraceFn

Dave Korn <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
Dave Korn wrote:

>   So, I think maybe I have *two* problems:
> 
> i)  The gcj::Core::root chain is empty.  Should it be?  Do I have a problem
> with static c/dtors?  I don't have JCR_SECTIONS turned on yet, so maybe I need
> to enable it?

  To half-answer my own question there, __Jv_global_static_constructor is at
least being called at static ctor time, so I should be OK on most fronts.

> ii) I don't think the library is able to handle an exception being thrown this
> early in startup because the code that segfaults filling out the stacktrace
> does assume it's inside at least one nested interpreter frame, and it wouldn't
> be called at all if it wasn't for what looks like a race-condition failure of
> the safety check at the top of java::lang::VMThrowable::fillInStackTrace.
> Should nothing be throwing at this early stage, or should we perhaps not set
> runtimeInitialized until later?  I note that it gets set true a second time,
> apparently redundantly, at the very end of _Jv_CreateJavaVM, so perhaps an
> accident of some sort has occurred here?  I'll take a look through the svn
> history.


  Yes, this looks like a regression.  The setting of runtimeInitialized was
moved to the end of the function in r115791

Revision 115791 - (view) (download) - [select for diffs]
Modified Fri Jul 28 07:40:17 2006 UTC (2 years, 9 months ago) by gary
File length: 45045 byte(s)
Diff to previous 114300 (colored)

2006-07-28  Gary Benson  <[email protected]>

	* prims.cc (_Jv_CreateJavaVM): Move setting runtimeInitialized
	from the start to the end of the function.  Remove references
	to VMThrowable.trace_enabled.
	* java/lang/natVMThrowable.cc (fillInStackTrace): Use
	runtimeInitialized rather than trace_enabled to decide
	whether to inhibit stack trace generation.
	* java/lang/VMThrowable.java (trace_enabled): Removed.


... and apparently re-added at the start, almost certainly inadvertently, when
Tom merged the gcj-eclipse branch to trunk at r120621.

  I will prepare and test a patch that simply removes the re-added set at the
top of the function.

    cheers,
      DaveK
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.