thr3ads.net - dovecot - Test failure on ARM: backtrace

If this information is useful, please help other people find it:
Share via:

Julien Lepiller

2020-Feb-20 20:49 UTC

Test failure on ARM: backtrace_append

Le 20 f?vrier 2020 13:37:20 GMT-05:00, Aki Tuomi <aki.tuomi at
open-xchange.com> a ?crit :>
>> On 20/02/2020 20:31 Julien Lepiller <julien at lepiller.eu>
wrote:
>> 
>>  
>> Le 20 f?vrier 2020 12:58:52 GMT-05:00, Aki Tuomi
><aki.tuomi at open-xchange.com> a ?crit :
>> >
>> >> On 20/02/2020 18:56 Julien Lepiller <julien at
lepiller.eu> wrote:
>> >> 
>> >>  
>> >> Hi,
>> >> 
>> >> I am a packager in Guix and user of dovecot on an ARM server
>(armhf).
>> >The Guix package fails to build because of a test error (see the
>last
>> >lines of the full build log:
>>
>>https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
>> >As the name suggests, this is dovecot 2.3.9.3, the latest version.
>> >Previous versions built fine, as well as the same version on x86
and
>> >x86_64. Note that the build on guix's build farm was done in a
qemu
>vm,
>> >but I got the same test failure on real hardware.
>> >> 
>> >> I'm not sure what the best course of action is. Did I find
a
>> >legitimate bug, or should I simply ignore that test for that
>> >architecture? Dovecot itself seems to be running fine when I ignore
>the
>> >tests.
>> >> 
>> >> Thanks for any guidance you could provide!
>> >
>> >(sorry for the previous mail, client acted up...)
>> >
>> >Can you provide backtrace for the core file? This seems to be
>related
>> >to libunwind somehow.
>> >
>> >Aki
>> 
>> I can try, but it will take me some time to rebuild. I forgot to keep
>the previous attempts. I think this is unrelated to libunwind since the
>asserts that fail are in the #elif case for libunwind. We don't build
>with libunwind (should we? What does it bring us?)
>
>Then it's somehow related into how the backtrace handling works in ARM.
>Anyways, cannot say anything without the core file.
>
>Aki
Thanks, it took me two hours to produce the core dump, but here it is. I suppose
putting it as an attachment is not ok for a mailing list, so I put it on my
server instead (tell me if you want it as an attachment instead, I couldn't
find that info). See https://lepiller.eu/files/core (400KB) and
https://lepiller.eu/files/test-lib (2.7MB) (the program that dumped core).
Thanks for your help!

Aki Tuomi

2020-Feb-21 05:25 UTC

head link

Test failure on ARM: backtrace_append

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   <br>
  </div>
  <blockquote type="cite">
   <div>
    On 20/02/2020 22:49 Julien Lepiller <
    <a
href="mailto:julien@lepiller.eu">julien@lepiller.eu</a>>
wrote:
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    Le 20 février 2020 13:37:20 GMT-05:00, Aki Tuomi <
    <a
href="mailto:aki.tuomi@open-xchange.com">aki.tuomi@open-xchange.com</a>>
a écrit :
   </div>
   <div>
    >
   </div>
   <div>
    >> On 20/02/2020 20:31 Julien Lepiller <
    <a
href="mailto:julien@lepiller.eu">julien@lepiller.eu</a>>
wrote:
   </div>
   <div>
    >>
   </div>
   <div>
    >>
   </div>
   <div>
    >> Le 20 février 2020 12:58:52 GMT-05:00, Aki Tuomi
   </div>
   <div>
    ><
    <a
href="mailto:aki.tuomi@open-xchange.com">aki.tuomi@open-xchange.com</a>>
a écrit :
   </div>
   <div>
    >> >
   </div>
   <div>
    >> >> On 20/02/2020 18:56 Julien Lepiller <
    <a
href="mailto:julien@lepiller.eu">julien@lepiller.eu</a>>
wrote:
   </div>
   <div>
    >> >>
   </div>
   <div>
    >> >>
   </div>
   <div>
    >> >> Hi,
   </div>
   <div>
    >> >>
   </div>
   <div>
    >> >> I am a packager in Guix and user of dovecot on an ARM
server
   </div>
   <div>
    >(armhf).
   </div>
   <div>
    >> >The Guix package fails to build because of a test error (see
the
   </div>
   <div>
    >last
   </div>
   <div>
    >> >lines of the full build log:
   </div>
   <div>
    >>
   </div>
   <div>
    >>
    <a
href="https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3)"
rel="noopener"
target="_blank">https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3)</a>.
   </div>
   <div>
    >> >As the name suggests, this is dovecot 2.3.9.3, the latest
version.
   </div>
   <div>
    >> >Previous versions built fine, as well as the same version on
x86 and
   </div>
   <div>
    >> >x86_64. Note that the build on guix's build farm was done
in a qemu
   </div>
   <div>
    >vm,
   </div>
   <div>
    >> >but I got the same test failure on real hardware.
   </div>
   <div>
    >> >>
   </div>
   <div>
    >> >> I'm not sure what the best course of action is. Did I
find a
   </div>
   <div>
    >> >legitimate bug, or should I simply ignore that test for that
   </div>
   <div>
    >> >architecture? Dovecot itself seems to be running fine when I
ignore
   </div>
   <div>
    >the
   </div>
   <div>
    >> >tests.
   </div>
   <div>
    >> >>
   </div>
   <div>
    >> >> Thanks for any guidance you could provide!
   </div>
   <div>
    >> >
   </div>
   <div>
    >> >(sorry for the previous mail, client acted up...)
   </div>
   <div>
    >> >
   </div>
   <div>
    >> >Can you provide backtrace for the core file? This seems to be
   </div>
   <div>
    >related
   </div>
   <div>
    >> >to libunwind somehow.
   </div>
   <div>
    >> >
   </div>
   <div>
    >> >Aki
   </div>
   <div>
    >>
   </div>
   <div>
    >> I can try, but it will take me some time to rebuild. I forgot to
keep
   </div>
   <div>
    >the previous attempts. I think this is unrelated to libunwind since the
   </div>
   <div>
    >asserts that fail are in the #elif case for libunwind. We don't
build
   </div>
   <div>
    >with libunwind (should we? What does it bring us?)
   </div>
   <div>
    >
   </div>
   <div>
    >Then it's somehow related into how the backtrace handling works in
ARM.
   </div>
   <div>
    >Anyways, cannot say anything without the core file.
   </div>
   <div>
    >
   </div>
   <div>
    >Aki
   </div>
   <div>
    <br>
   </div>
   <div>
    Thanks, it took me two hours to produce the core dump, but here it is. I
suppose putting it as an attachment is not ok for a mailing list, so I put it on
my server instead (tell me if you want it as an attachment instead, I
couldn't find that info). See
    <a href="https://lepiller.eu/files/core"
rel="noopener"
target="_blank">https://lepiller.eu/files/core</a> (400KB)
and
    <a href="https://lepiller.eu/files/test-lib"
rel="noopener"
target="_blank">https://lepiller.eu/files/test-lib</a>
(2.7MB) (the program that dumped core). Thanks for your help!
   </div>
  </blockquote>
  <div>
   <br>
  </div>
  <div>
   Thank you,
  </div>
  <div>
   <br>
  </div>
  <div>
   as I don't have arm at hand, can you provide
  </div>
  <div>
   <br>
  </div>
  <div>
   gdb .test-lib core
  </div>
  <div>
   bt full
  </div>
  <div>
   <br>
  </div>
  <div>
   output?
  </div>
  <div class="io-ox-signature">
   <pre>---
Aki Tuomi</pre>
  </div> 
 </body>
</html>

Julien Lepiller

2020-Feb-21 12:23 UTC

head link

Test failure on ARM: backtrace_append

Le Fri, 21 Feb 2020 07:25:15 +0200 (EET),
Aki Tuomi <aki.tuomi at open-xchange.com> a ?crit :
> Thank you,
> 
> as I don't have arm at hand, can you provide
> 
> gdb .test-lib core
> bt full
> 
> output?
> ---
> Aki Tuomi
> 
There you are (sorry for the long file names, that's how guix works,
it's expected):

[New LWP 21501]
Core was generated by `./test-lib'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb6e24d30 in strchr () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
(gdb) bt full
#0  0xb6e24d30 in strchr () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
No symbol table info available.
#1  0xb6e26094 in strstr () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
No symbol table info available.
#2  0x000144fe in test_backtrace_get () at test-backtrace.c:45
        bt = 0x0
        bt = <optimized out>
#3  test_backtrace () at test-backtrace.c:56
No locals.
#4  0x000353a4 in test_run_named_funcs (tests=tests at entry=0x6608c
<test_functions>, match=match at entry=0x6ddcc "") at
test-common.c:288
        _data_stack_cur_id = 2
        i = <optimized out>
#5  0x00035bf0 in test_run_named_with_fatals (match=0x6ddcc "",
tests=0x6608c <test_functions>, fatals=0x6603c <fatal_functions>) at
test-common.c:370
No locals.
#6  0xb6de6426 in __libc_start_main () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
No symbol table info available.
#7  0x00013268 in _start ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
(gdb)

Maybe Matching Threads

Search for more apparently analagous threads

dovecot - Feb 2020 - Test failure on ARM: backtrace_append

Test failure on ARM: backtrace_append

Test failure on ARM: backtrace_append

Test failure on ARM: backtrace_append

Maybe Matching Threads