help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave chokes on this in some systems


From: John W. Eaton
Subject: Re: Octave chokes on this in some systems
Date: Tue, 15 Nov 2005 22:20:12 -0500

On 15-Nov-2005, Quentin Spencer wrote:

| I'm willing to update the Fedora release of 2.1.72 with this patch, but 
| for some reason when I tried patching the sources with your patch, it 
| didn't work. I keeps complaining that the patch is reversed, even though 
| it looks correct--maybe I found a bug in patch. Maybe this is the same 
| thing Paul ran into yesterday.

I don't understand why patch is failing.  The patch also looks correct
to me (it is supposed to be removing the resize function from
oct-obj.cc and adding it to oct-obj.h).

In any case, I'm not yet convinced that the bug is in GCC or Octave.

Can you please try the following and see if it avoids the bug:

  export GLIBCXX_FORCE_NEW=1
  octave
  ...
  octave:1> test_caller

Setting this environment variable forces the mt_allocator in GCC 4.0.2
to always use new/delete instead of the custom allocator.  Doing that
makes the code work for me.  Otherwise, it is crashing inside 

  void __pool<true>::_M_reclaim_block(char* __p, size_t __bytes)

in mt_allocator.cc (part of libstdc++).  Older versions of
mt_allocator (up until GCC 3.4, it appears) always used operator
new/delete.  So this is starting to look like a bug in mt_allocator,
but I still don't know how to write a concise test case for the bug
without doing a lot of work.

I still think that applying the patch is just hiding the bug, and so
it would not surprise me to find it biting again somewhere else.

BTW, I tried building Octave with the current SVN sources of GCC to
see if the problem was already fixed.  Unfortunately it was not.
Doubly unfortunate is that the C++ compiler seems much slower now
(maybe more optimizations?) and it took >10 minutes to create
liboctinterp.so.  Would someone like to verify this problem and
compare the build times (possibly also timing some individual steps
like creating shared libraries) between GCC 3.4, 4.0, and the current
SVN sources of GCC?  If GCC built from the current sources is really
as slow as I experienced (and the problem wasn't due to something
stupid that I did) then I think we need to report the problem.

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]