<!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>