GNOME Bugzilla – Bug 791954
gnumeric 1.12.37 fails to build with itstool 2.0.4
Last modified: 2018-05-22 14:32:31 UTC
The build is fine with itstool 2.0.2. (The build gets stuck with itstool 2.0.3 but that is an unrelated problem.) The build fails with itstool 2.0.4. The error is Error: Could not merge translations: 'ascii' codec can't decode byte 0xc2 in position 97: ordinal not in range(128) make[3]: *** [cs/cs.stamp] Error 1 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 Full build log is here: https://gist.github.com/ilovezfs/39549b24fc277e891281d962bb5071c6 This has been reported by someone else to itstool upstream, so far with no response. See https://github.com/itstool/itstool/issues/22 (Note Homebrew's itstool 2.0.4 is already patched with https://github.com/itstool/itstool/commit/9b84c00 for https://github.com/itstool/itstool/issues/17 and the gnumeric build fails nonetheless.)
That's a core dump from inside itstool. A segfault, it seems. This has the feel of a problem relating to memory ownership. I am so not looking forward to debugging this, :-( I am still at itstool 2.0.2, so not affected yet. It is unlikely that there is a workaround other than fixing itstool or not building translated documentation. My advice would be to 1. Figure out precisely what command is being run. Building Gnumeric with "make V=1" might be helpful. 2. Run that same command under valgrind.
==6272== Invalid read of size 4 ==6272== at 0x6FD3633: ??? (in /usr/lib/python2.7/dist-packages/libxml2mod.so) ==6272== by 0x4C45F9: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C9D7E: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C2704: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==6272== by 0x4DE69D: ??? (in /usr/bin/python2.7) ==6272== by 0x4B0C92: PyObject_Call (in /usr/bin/python2.7) ==6272== by 0x4B0900: PyObject_CallFunction (in /usr/bin/python2.7) ==6272== by 0x4E3957: ??? (in /usr/bin/python2.7) ==6272== by 0x4C442B: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C2704: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==6272== by 0x4CA087: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C2704: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==6272== Address 0x302f32312f333038 is not stack'd, malloc'd or (recently) free'd ==6272== ==6272== ==6272== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==6272== General Protection Fault ==6272== at 0x6FD3633: ??? (in /usr/lib/python2.7/dist-packages/libxml2mod.so) ==6272== by 0x4C45F9: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C9D7E: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C2704: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==6272== by 0x4DE69D: ??? (in /usr/bin/python2.7) ==6272== by 0x4B0C92: PyObject_Call (in /usr/bin/python2.7) ==6272== by 0x4B0900: PyObject_CallFunction (in /usr/bin/python2.7) ==6272== by 0x4E3957: ??? (in /usr/bin/python2.7) ==6272== by 0x4C442B: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C2704: PyEval_EvalCodeEx (in /usr/bin/python2.7) ==6272== by 0x4CA087: PyEval_EvalFrameEx (in /usr/bin/python2.7) ==6272== by 0x4C2704: PyEval_EvalCodeEx (in /usr/bin/python2.7)
It looks like https://github.com/itstool/itstool/commit/d3adf0264ee2b6fd28b7eff7dec33501d6e75a7c is the first bad commit producing the "codec can't decode byte 0xc2" error. Before that commit, it gets stuck instead.
The message 'ascii' codec can't decode byte 0xc2 in position 97: ordinal not in range(128) suggests that itstool cannot deal with UTF-8. That's the default for xml files, so it's a bit weird. It might also be that the memory corruption is showing up this way too.
This should be reported as an itstool bug. Was it?
Morten, the link to the itstool bug report is in the first message. Here it is again: https://github.com/itstool/itstool/issues/22
Ah, right. No action on that bug though.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/331.