Re: pspp package FTBFS on armhf
On Mon, Aug 18, 2014 at 11:20:14AM -0700, Ben Pfaff wrote:
> On Mon, Aug 18, 2014 at 11:13 AM, Lennart Sorensen
> <lsorense@csclub.uwaterloo.ca> wrote:
> > On Sun, Aug 17, 2014 at 08:19:25AM +0200, Friedrich Beckmann wrote:
> >> Dear Ben,
> >>
> >> Am 15.08.2014 um 16:52 schrieb Ben Pfaff <blp@cs.stanford.edu>:
> >>
> >> > Reading https://dsa.debian.org/doc/guest-account/, one of the
> >> > requirements is "People requesting access should already have a track
> >> > record of working on Debian for some time." Do you qualify?
> >>
> >> I did not do other things in Debian, so I do not qualify. I thought this was
> >> the only way to get access to an armhf machine to debug the build problem, but you
> >> proposed and already implemented:
> >>
> >> > the testsuite.log is often sufficient to debug problems
> >>
> >> Thank you doing this. In addition Héctor Orón gave me access to ipa.debian.net so I have
> >> another possibility to look into the problem.
> >
> > Well it seems there is some segfaulting in some of the test cases:
> >
> > For example test 0485:
> >
> > Starting program: /root/pspp-0.8.3/src/ui/terminal/.libs/pspp -O format=csv 0485/means-hg.sps
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> > Cannot access memory at address 0x0
> >
> > Program received signal SIGILL, Illegal instruction.
> > 0xb62a5ca8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> > (gdb) where
> > #0 0xb62a5ca8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> > #1 0xb62a390c in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
> > #2 0xb6fe225e in call_init (l=<optimized out>, argc=4, argv=0xbefffd04, env=0xbefffd18) at dl-init.c:78
> > #3 0xb6fe22f0 in _dl_init (main_map=0xb6fff958, argc=4, argv=0xbefffd04, env=0xbefffd18) at dl-init.c:126
> > #4 0xb6fd7bf2 in _dl_start_user () from /lib/ld-linux-armhf.so.3
> > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> > (gdb) continue
> > Continuing.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > variable_matches_case (v=v@entry=0x3ea78, c=0x0) at src/data/case.c:475
> > 475 return (case_idx < caseproto_get_n_widths (c->proto)
> > (gdb) where
> > #0 variable_matches_case (v=v@entry=0x3ea78, c=0x0) at src/data/case.c:475
> > #1 0xb6e77cda in case_data (c=c@entry=0x0, v=0x3ea78) at src/data/case.c:267
> > #2 0xb6f5de5e in update_n (aux1=0xbefffab8, aux2=0x3eb28, user_data=0x41580, c=<optimized out>, weight=1) at src/language/stats/means.c:917
> > #3 0xb6f98ed0 in categoricals_update (cat=0x41060, c=c@entry=0x3e4f0) at src/math/categoricals.c:450
> > #4 0xb6f5e438 in run_means (ds=0x2e2b0, input=0x41048, cmd=0xbefffab8) at src/language/stats/means.c:1021
> > #5 cmd_means (lexer=<optimized out>, ds=0x2e2b0) at src/language/stats/means.c:784
> > #6 0xb6f3b198 in do_parse_command (state=CMD_STATE_DATA, ds=<optimized out>, lexer=0x2e920) at src/language/command.c:233
> > #7 cmd_parse_in_state (lexer=0x2e920, ds=0x2e2b0, state=CMD_STATE_DATA) at src/language/command.c:148
> > #8 0x000126de in main (argc=<optimized out>, argv=<optimized out>) at src/ui/terminal/main.c:138
> > (gdb) list
> > 470 Useful in assertions. */
> > 471 static bool UNUSED
> > 472 variable_matches_case (const struct ccase *c, const struct variable *v)
> > 473 {
> > 474 size_t case_idx = var_get_case_index (v);
> > 475 return (case_idx < caseproto_get_n_widths (c->proto)
> > 476 && caseproto_get_width (c->proto, case_idx) == var_get_width (v));
> > 477 }
> > 478
> > 479 /* Internal helper function for case_copy(). */
> >
> > (Note it is _normal_ to get sigill from openssl and having to continue).
> > Normal can be weird.
> >
> > c is NULL in this call it seems, so dereferencing it seems like a bad idea.
>
> I concluded that it was a compiler bug and avoided it by turning off
> compiler optimization on armhf:
> http://lists.gnu.org/archive/html/pspp-dev/2014-08/msg00021.html
Certainly gdb thinks the value of c is optimized away on the call to
->update, which makes no sense looking at the called function.
Sticking a printf of the value of c inside the n_update function of
course makes the problem go away (Thanks gcc).
--
Len Sorensen
Reply to: