help-octave
[Top][All Lists]
Advanced

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

Re: octave-3.4.3+gcc46 on OS X 10.4/powerpc, test hangs in bsxfun


From: Ben Abbott
Subject: Re: octave-3.4.3+gcc46 on OS X 10.4/powerpc, test hangs in bsxfun
Date: Thu, 15 Dec 2011 22:01:02 -0500

On Dec 15, 2011, at 11:24 AM, Alexander Hansen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/15/11 11:01 AM, Alexander Hansen wrote:
>> On 11/30/11 2:44 PM, David Fang wrote:
>>> Hello octavians,
>> 
>>> Recently, I've been trying to port octave-3.4.3 for OS X 
>>> 10.4/powerpc in fink, and have encountered hanging in the test 
>>> suite. I initially tried the system compiler (g++-4.0.1) but 
>>> encountered the following issue: 
>>> https://savannah.gnu.org/bugs/?30685 where on startup, octave 
>>> would segfault in sigemptyset(). I then switched to gcc-4.6.2, 
>>> which has shown decent test results for powerpc-apple-darwin8 
>>> [http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03272.html]. 
>>> With gcc-4.6, the test suite hangs starting in bsxfun.cc, 
>>> specifically on:
>> 
>>> octave:1> f = @minus; octave:2> bsxfun (f, ones(4, 0), ones(4,
>>> 4)) *** wait forever... ^C^C^C
>> 
>>> I've added some debug hooks to trace what's going on and also
>>> have a gdb stacktrace (from ../run-octave -g ...):
>> 
>>> \-{ Fbsxfun | :  arguments checked. | :  func.is_builtin || 
>>> is_function_handle... | \-{ maybe_optimized_builtin | | \-{ 
>>> maybe_fill_table | | | :  filling... | | /-} maybe_fill_table | |
>>> \-{ bsxfun_builtin_lookup | | /-} bsxfun_builtin_lookup | | :
>>> op != bsxfun_builtin_unknown | | \-{ octave_value 
>>> bsxfun_forward_op(const octave_value&, const octave_value&) [with
>>> NDA = NDArray, NDA (* bsxfun_op)(const NDA&, const NDA&) = 
>>> bsxfun_sub] | | | :  extracted x | | | :  extracted y | | | \-{ 
>>> NDArray bsxfun_sub(const NDArray&, const NDArray&) | | | | \-{ 
>>> Array<R> do_bsxfun_op(const Array<X>&, const Array<Y>&, void 
>>> (*)(std::size_t, R*, const X*, const Y*), void (*)(std::size_t, 
>>> R*, X, const Y*), void (*)(std::size_t, R*, const X*, Y)) [with
>>> R = double, X = double, Y = double, std::size_t = long unsigned
>>> int] | | | | | :  i = 0 | | | | | :  i = 1 | | | | | \-{ 
>>> lo_error_handler error: bsxfun: nonconformant dimensions: 4x0
>>> and 4x4 | | | | | | \-{ octave_throw_execution_exception ^C
>>> Program received signal SIGINT, Interrupt. 0x9143b3a0 in
>>> uw_frame_state_for () (gdb) where #0  0x9143b3a0 in
>>> uw_frame_state_for () #1 0x9143cb7c in _Unwind_RaiseException ()
>>> #2  0x03be6148 in __cxa_throw () at settings.h:338 #3  0x0038acc8
>>> in octave_throw_execution_exception () #4  0x0123ec08 in 
>>> _ZL16lo_error_handlerPKcz () #5  0x02c40d90 in
>>> do_bsxfun_op<double, double, double> () #6  0x02438d24 in
>>> bsxfun_sub () #7  0x04a49008 in bsxfun_forward_op<NDArray,
>>> &(bsxfun_sub(NDArray const&, NDArray const&))> () at
>>> settings.h:338 #8  0x04a59460 in Fbsxfun () at settings.h:338 #9
>>> 0x012f95d0 in octave_builtin::do_multi_index_op () #10 0x012f8460
>>> in octave_builtin::subsref () #11 0x012f9074 in 
>>> octave_builtin::subsref () #12 0x013b0ed4 in
>>> octave_value::subsref () #13 0x01445908 in
>>> tree_index_expression::rvalue () #14 0x01446348 in
>>> tree_index_expression::rvalue () #15 0x01440dc0 in 
>>> tree_index_expression::rvalue1 () #16 0x01436710 in 
>>> tree_evaluator::visit_statement () #17 0x0145ff10 in 
>>> tree_statement::accept () #18 0x0143118c in 
>>> tree_evaluator::visit_statement_list () #19 0x01460030 in 
>>> tree_statement_list::accept () #20 0x01298538 in main_loop () #21
>>> 0x01242c40 in octave_main () #22 0x00002e28 in _start () #23 
>>> 0x00002b2c in start ()
>> 
>>> The full trail of my debugging efforts is at: 
>>> http://paste.lisp.org/display/125952 (starting at annotation #5)
>> 
>>> The thrown exception looks like an empty class, thrown by value,
>>> and somehow this winds up in some infinite loop.
>> 
>>> My questions: what is supposed to happen after "bsxfun: 
>>> nonfconformant dimensions"? I would expect the stack to unwind up
>>> to the next handler when thrown, but that doesn't seem to be 
>>> happening?
>> 
>>> Suspects: gcc46 miscompilation?
>> 
>>> Any help/tips/leads greatly appreciated.  Thanks.
>> 
>>> Fang
>> 
>> 
>> For what it's worth, I also see a hang on OS X 10.5/powerpc.  On 
>> 10.5/intel 32-bit, I get the following at the same point:
>> 
>> src/DLD-FUNCTIONS/bsxfun.cc ............................terminate 
>> called after throwing an instance of 'octave_execution_exception'
>> 
> 
> Also 10.5/intel 64-bit.
> 
>> 10.7/64-bit works OK, however.
>> 
>> I'll report on 10.6 after I test that:  I only have one intel box,
>> so I have to reboot to test different OS versions. :-)
> 

I'm traveling and don't have by Mac with Fink installed with me.

For gcc-4.5, I had troubles with "-O3" and "-O1", but "-O2" did not result in 
any additional test failures (as compared to -O0). Unfortunately, I don't 
recall what regressions I encountered using "-O1" or "-O3".

Ben







reply via email to

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