Re: Bug#790925: pandas: FTBFS on armhf and sparc: Bus error in test_append_frame_column_oriented
On Thu, Feb 18, 2016 at 04:35:09PM -0500, Lennart Sorensen wrote:
> On Mon, Feb 15, 2016 at 08:36:49AM -0500, Yaroslav Halchenko wrote:
> >
> > On Thu, 02 Jul 2015, Aaron M. Ucko wrote:
> >
> > > Source: pandas
> > > Version: 0.16.2+git65-g054821d-1
> > > Severity: serious
> > > Justification: fails to build from source (but built successfully in the past)
> >
> > > The armhf and sparc builds of pandas both failed with a bus error in
> > > test_append_frame_column_oriented:
> >
> > > test_append_frame_column_oriented (pandas.io.tests.test_pytables.TestHDFStore) ... Bus error
> > > make[1]: *** [python-test2.7] Error 135
> >
> > Sorry about delay... quite often those Bus errors just go away on their
> > own since aren't anything to be fixed in pandas, but this time it still
> > persists with 0.17.1:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=pandas&arch=armhf&ver=0.17.1-3&stamp=1450078009
> > test_append_frame_column_oriented (pandas.io.tests.test_pytables.TestHDFStore) ... Exception AttributeError: AttributeError("'File' object has no attribute '_node_manager'",) in ignored
> > Bus error
> >
> > sparc is gone and seems to be not trying on sparc64 yet. I will look
> > into fixing up my testing environment on sparc64 to see how current
> > master is doing:
> > http://nipy.bic.berkeley.edu/builders/pandas-py2.x-sid-sparc/builds/1806
> >
> > Dear ARM people -- any clues on what could be a culprit here?
>
> Well I tried it and hit the same error. kernel says:
>
> [3735253.445316] Alignment trap: not handling instruction ed937b00 at [<b5b2aee2>]
> [3735253.451204] Unhandled fault: alignment exception (0x011) at 0x049c0551
>
> So certainly an alignment problem there.
>
> Running it under gdb (which took some effort since gdb 7.10 gives assert
> errors on arm in sid, while installing 7.7 from jessie works fine,
> although gives some other errors).
Turns out gdb 7.10 DOES work if you mount /proc in your chroot. Older versions have no such requirement, and it sure would be nice if gdb could tell you 'I can't read /proc/<whatever>' rather than having an assert failure that tells you nothing about why it suddenly doesn't work like it used to.
Backtrace from gdb 7.10 which looks the same pretty much:
Program received signal SIGBUS, Bus error.
0xb57eb06e in __pyx_f_6pandas_5algos_take_2d_axis1_float64_float64_memview (__pyx_optional_args=<synthetic pointer>, __pyx_v_indexer=..., __pyx_v_values=..., __pyx_v_out=...) at pandas/algos.c:111226
111226 *((__pyx_t_5numpy_float64_t *) ( /* dim=1 */ (( /* dim=0 */ (__pyx_v_out.data + __pyx_t_12 * __pyx_v_out.strides[0]) ) + __pyx_t_13 * __pyx_v_out.strides[1]) )) = (*((__pyx_t_5numpy_float64_t *) ( /* dim=1 */ (( /* dim=0 */ (__pyx_v_values.data + __pyx_t_10 * __pyx_v_values.strides[0]) ) + __pyx_t_11 * __pyx_v_values.strides[1]) )));
(gdb) where
#0 0xb57eb06e in __pyx_f_6pandas_5algos_take_2d_axis1_float64_float64_memview (__pyx_optional_args=<synthetic pointer>, __pyx_v_indexer=..., __pyx_v_values=..., __pyx_v_out=...) at pandas/algos.c:111226
#1 __pyx_pf_6pandas_5algos_326take_2d_axis1_float64_float64 (__pyx_self=<optimized out>, __pyx_v_fill_value=<float at remote 0xb63693e0>, __pyx_v_out=..., __pyx_v_indexer=<optimized out>, __pyx_v_values=<optimized out>) at pandas/algos.c:45904
#2 __pyx_pw_6pandas_5algos_327take_2d_axis1_float64_float64 (__pyx_self=<optimized out>, __pyx_args=<optimized out>, __pyx_kwds=<optimized out>) at pandas/algos.c:45803
#3 0x00052f4c in PyCFunction_Call (func=<built-in function take_2d_axis1_float64_float64>, args=<optimized out>, kwds=<optimized out>) at ../Objects/methodobject.c:98
#4 0x00076744 in call_function (oparg=<optimized out>, pp_stack=0xbeffcde4) at ../Python/ceval.c:4652
#5 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:3185
#6 0x001222f4 in _PyEval_EvalCodeWithName.lto_priv.1329 (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=2, kws=0xb26a419c, kwcount=3, defs=0xb58af4ec, defcount=5, kwdefs=0x0, closure=0x0, name='take_nd',
qualname='take_nd') at ../Python/ceval.c:3965
#7 0x00076c56 in fast_function (nk=3, na=2, n=8, pp_stack=0xbeffcf1c, func=<optimized out>) at ../Python/ceval.c:4760
#8 call_function (oparg=<optimized out>, pp_stack=0xbeffcf1c) at ../Python/ceval.c:4677
#9 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:3185
#10 0x001222f4 in _PyEval_EvalCodeWithName.lto_priv.1329 (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=2, kws=0xb26a3938, kwcount=2, defs=0xb53fa5b4, defcount=2, kwdefs=0x0, closure=0x0, name='take_nd',
qualname='Block.take_nd') at ../Python/ceval.c:3965
#11 0x00076c56 in fast_function (nk=2, na=2, n=6, pp_stack=0xbeffd054, func=<optimized out>) at ../Python/ceval.c:4760
#12 call_function (oparg=<optimized out>, pp_stack=0xbeffd054) at ../Python/ceval.c:4677
[etc]
(gdb) list
111221 /*else*/ {
111222 __pyx_t_10 = __pyx_v_i;
111223 __pyx_t_11 = __pyx_v_idx;
111224 __pyx_t_12 = __pyx_v_i;
111225 __pyx_t_13 = __pyx_v_j;
111226 *((__pyx_t_5numpy_float64_t *) ( /* dim=1 */ (( /* dim=0 */ (__pyx_v_out.data + __pyx_t_12 * __pyx_v_out.strides[0]) ) + __pyx_t_13 * __pyx_v_out.strides[1]) )) = (*((__pyx_t_5numpy_float64_t *) ( /* dim=1 */ (( /* dim=0 */ (__pyx_v_values.data + __pyx_t_10 * __pyx_v_values.strides[0]) ) + __pyx_t_11 * __pyx_v_values.strides[1]) )));
111227 }
111228 __pyx_L10:;
111229 }
111230 }
Not the most readable line of code I have ever seen. Autogenerated mess.
--
Len Sorensen
Reply to: