Illegal instruction 2f0a when running msgmerge

[glaubitz]

Just updated master-dev to git 5e79823 and tried to build apt in a fresh unstable chroot which previously failed with timeouts when running /usr/bin/msgmerge:

Generating ../build/po/domains/apt/ast.po echo ../build/po/domains/apt/ast.po : ast.po ../build/po/apt.pot > ../build/po/apt_ast.po.d /usr/bin//msgmerge --add-location=file ast.po ../build/po/apt.pot -o ../build/po/domains/apt/ast.po ............E: Caught signal ‘Terminated’: terminating immediately make[2]: * wait: No child processes. Stop. make[2]: * Waiting for unfinished jobs.... make[2]: * wait: No child processes. Stop. make[1]: * wait: No child processes. Stop. make[1]: * Waiting for unfinished jobs.... make[1]: * wait: No child processes. Stop. make: * wait: No child processes. Stop. make: * Waiting for unfinished jobs.... make: *\ wait: No child processes. Stop. Build killed with signal TERM after 30 minutes of inactivity

The build still fails, but this time not with a timeout but with an illegal instruction:

Generating ../build/po/domains/apt/ar.po echo ../build/po/domains/apt/ar.po : ar.po ../build/po/apt.pot > ../build/po/apt_ar.po.d /usr/bin//msgmerge --add-location=file ar.po ../build/po/apt.pot -o ../build/po/domains/apt/ar.po qemu: fatal: Illegal instruction: 2f0a @ f615cd26 D0 = 00000004 A0 = 80093c70 F0 = 7fff 4000000000000000 D1 = 00000000 A1 = 80015150 F1 = 7fff 4000000000000000 D2 = f6fff428 A2 = f42ff91c F2 = 7fff 4000000000000000 D3 = 80093c84 A3 = 80003bf0 F3 = 7fff 4000000000000000 D4 = f42ff400 A4 = f6fff22c F4 = 7fff 4000000000000000 D5 = 00001000 A5 = f6168000 F5 = 7fff 4000000000000000 D6 = f614b3e0 A6 = f42feef0 F6 = 7fff 4000000000000000 D7 = 00800000 A7 = f42feed0 F7 = 7fff 4000000000000000 PC = f615cd22 SR = 0008 -N--- makefile:60: recipe for target '../build/po/domains/apt/ar.po' failed

Attaching the build log.

apt_1.1.10_m68k-20160111-1534.build.zip

[vivier]

2f0a is a "move.l %a2, #imm" which uses an invalid destination address mode. (#imm). So it is really invalid. The problem is surely before.

Could you run, something like:

QEMU_LOG=in_asm,op QEMU_LOG_FILENAME=/qemu.log /usr/bin//msgmerge --add-location=file ar.po ../build/po/apt.pot -o ../build/po/domains/apt/ar.po

[glaubitz]

I haven't had the time yet to re-test this and provide the necessary debug information, however, I just noticed that - without changing anything - apt now builds fine on m68k while it now fails the same way on sh4 it previously failed on m68k.

Current m68k:

https://buildd.debian.org/status/fetch.php?pkg=apt&arch=m68k&ver=1.2&stamp=1452915284

Current sh4:

https://buildd.debian.org/status/fetch.php?pkg=apt&arch=sh4&ver=1.2&stamp=1452893663

Fails with:

Generating ../build/po/domains/apt/gl.po echo ../build/po/domains/apt/gl.po : gl.po ../build/po/apt.pot > ../build/po/apt_gl.po.d /usr/bin//msgmerge --add-location=file gl.po ../build/po/apt.pot -o ../build/po/domains/apt/gl.po .................................E: Caught signal ‘Terminated’: terminating immediately make[2]: * wait: No child processes. Stop. make[2]: * Waiting for unfinished jobs.... make[2]: * wait: No child processes. Stop. make[1]: * wait: No child processes. Stop. make[1]: * Waiting for unfinished jobs.... make[1]: * wait: No child processes. Stop. make: * wait: No child processes. Stop. make: * Waiting for unfinished jobs.... make: *\ wait: No child processes. Stop. Build killed with signal TERM after 30 minutes of inactivity

As you can see in the build log on sh4, msgmerge is called multiple times before in similar fashion without failing before apparently the thread just dies. Looks very similar to the issue with the signals with previously had on m68k but it has to be something different as this was already fixed. I guess it will just fail on m68k during the next build.

[glaubitz]

Alright, as Michael Karcher has figured out, this is simply register_m68k_insns not being thread-safe and just adding "if(opcode_table[0] != NULL) return;" to the top of this function makes sure that the opcode table is only built once and not destroyed when multiple threads are involved.

I have added this change to the qemu-m68k instances running on my buildds and fixes the build failures for many packages including exim4, cups and others.

[glaubitz]

I think we can close this issue, can't we? The main culprit was the opcode table being destroyed on context switch and that was fixed. Although it's not been upstreamed yet.