<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Le 11/10/2017 à 11:16, James Cowgill a écrit :<br>
<blockquote type="cite"
cite="mid:31587e66-2677-ba8c-949a-d6cf9d65d734@debian.org">
<pre wrap="">Control: tags -1 moreinfo
On 11/10/17 00:11, <a class="moz-txt-link-abbreviated" href="mailto:gperreal@free.fr">gperreal@free.fr</a> wrote:
[...]
</pre>
<pre wrap="">How do you trigger this bug? If you need any module files, can you
attach them to the bug report.</pre>
</blockquote>
I use no openmpt module. I can trigger the bug by running minidlnad
on the command line, e.g. :<br>
<br>
guillaume@exodus ~> /usr/sbin/minidlnad<br>
fish: '/usr/sbin/minidlnad' terminated by signal SIGILL (Instruction
illégale)<br>
<br>
The same thing happens when I try to run the testsuite:<br>
<br>
guillaume@exodus ~/s/libopenmpt-0.3.1+release.autotools>
./libopenmpttest<br>
fish: './libopenmpttest' terminated by signal SIGILL (Instruction
illégale)<br>
<blockquote type="cite"
cite="mid:31587e66-2677-ba8c-949a-d6cf9d65d734@debian.org">
<pre wrap="">Can you provide a GDB backtrace and the disassembly around the
instruction which causes the SIGILL?</pre>
</blockquote>
I attached the traces from both minidlnad and the testsuite.<br>
<blockquote type="cite"
cite="mid:31587e66-2677-ba8c-949a-d6cf9d65d734@debian.org">
<pre wrap="">minidlnad does not directly depend on libopenmpt0, so presumably this is
triggered through ffmpeg. Can you run ffmpeg on some module files to see
if that also fails with SIGILL? Can you run openmpt123 on the same files?</pre>
</blockquote>
According to <a class="moz-txt-link-freetext"
href="https://packages.debian.org/stretch/minidlna">https://packages.debian.org/stretch/minidlna</a>,
minidlnad depends on libavformat57, which in turn depends on
libopenmpt0, so neither openmpt123 nor ffmpeg are involved in this
bug, and I am not using them on any fill either.<br>
<blockquote type="cite"
cite="mid:31587e66-2677-ba8c-949a-d6cf9d65d734@debian.org">[...]
<blockquote type="cite">
<pre wrap="">Kernel: Linux 4.4.52-gnu (SMP w/4 CPU cores)
</pre>
</blockquote>
<pre wrap="">Where is this kernel from? I note the CPU you are using does not have an
FPU, so this could be a bug in the kernel FPU emulator. I can't remember
what fixes have gone in since 4.4 though.</pre>
</blockquote>
This kernel is provided by the manufacturer of the board. I used
this binary to update the firmware :
<a class="moz-txt-link-freetext"
href="https://github.com/gnubee-git/gnubee-git.github.io/blob/master/debian/librecmc-ramips-mt7621-gb-pc1-squashfs-sysupgrade_2017-07-22.bin">https://github.com/gnubee-git/gnubee-git.github.io/blob/master/debian/librecmc-ramips-mt7621-gb-pc1-squashfs-sysupgrade_2017-07-22.bin</a>.
In normal operation, only the bootloader, kernel and initramfs are
used. The initramfs pivots to a GNUBEE-ROOT partition if it finds
one. The LibreCMC distribution is only used as a fallback.<br>
<br>
cat /proc/version<br>
Linux version 4.4.52-gnu (dgazineu@olimpo) (gcc version 5.4.0 (LEDE
GCC 5.4.0 r20-646beea) ) #0 SMP Wed Jul 5 16:50:03 2017<br>
<br>
I can contact dgazineu if need be.<br>
<br>
Best regards,<br>
-- <br>
Guillaume.<br>
</body>
</html>