#1009739 python3.10 breaks yade autopkgtest on i386: Segmentation fault

Package:
src:yade
Source:
yade
Submitter:
Paul Gevers
Date:
2022-06-01 15:21:02 UTC
Severity:
serious
Tags:
#1009739#5
Date:
2022-04-15 20:08:08 UTC
From:
To:
Dear maintainer(s),

With a recent upload of python3.10 the autopkgtest of yade fails in
testing when that autopkgtest is run with the binary packages of
python3.10 from unstable. It passes when run with only packages from
testing. In tabular form:

                        pass            fail
python3.10             from testing    3.10.4-3
yade                   from testing    2022.01a-7
all others             from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3.10 to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3.10

https://ci.debian.net/data/autopkgtest/testing/i386/y/yade/20864008/log.gz


testAssignment (yade.tests.enumTest.TestEnum) ...
[ci-105-2493316c:08193] *** Process received signal ***
[ci-105-2493316c:08193] Signal: Segmentation fault (11)
[ci-105-2493316c:08193] Signal code: Address not mapped (1)
[ci-105-2493316c:08193] Failing at address: 0x1
[ci-105-2493316c:08193] [ 0]
linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf7f97580]
[ci-105-2493316c:08193] [ 1]
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(+0x17d7b)[0xf7446d7b]
[ci-105-2493316c:08193] [ 2] /usr/bin/python3.10(+0x16d816)[0x567bb816]
[ci-105-2493316c:08193] [ 3]
/usr/lib/i386-linux-gnu/yade-double/py/yade/boot.so(_ZN5boost6python3api11object_baseD1Ev+0x39)[0xf747a7f9]
[ci-105-2493316c:08193] [ 4]
/usr/lib/i386-linux-gnu/yade-double/libpkg_common.so(_ZN4yade25ArbitraryEnum_from_pythonINS_14OpenGLRenderer14BlinkHighlightEE16setArbitraryEnumERKN5boost6python3api6objectERS2_+0xb38)[0xf4169008]
[ci-105-2493316c:08193] [ 5]
/usr/lib/i386-linux-gnu/yade-double/libpkg_common.so(_ZN4yade25ArbitraryEnum_from_pythonINS_14OpenGLRenderer14BlinkHighlightEE11convertibleEP7_object+0xa72)[0xf416aa12]
[ci-105-2493316c:08193] [ 6]
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(_ZN5boost6python9converter25rvalue_from_python_stage1EP7_objectRKNS1_12registrationE+0x6d)[0xf74445bd]
[ci-105-2493316c:08193] [ 7]
/usr/lib/i386-linux-gnu/yade-double/libpkg_common.so(_ZN5boost6python7objects23caller_py_function_implINS0_6detail6callerINS3_6memberIN4yade14OpenGLRenderer14BlinkHighlightES7_EENS0_19return_value_policyINS0_15return_by_valueENS0_21default_call_policiesEEENS_3mpl7vector3IvRS7_RKS8_EEEEEclEP7_objectSN_+0x77)[0xf415eeb7]
[ci-105-2493316c:08193] [ 8]
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(_ZNK5boost6python7objects8function4callEP7_objectS4_+0x2c4)[0xf744d974]
[ci-105-2493316c:08193] [ 9]
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(+0x1eb96)[0xf744db96]
[ci-105-2493316c:08193] [10]
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(_ZN5boost6python21handle_exception_implENS_9function0IvEE+0x73)[0xf7452f73]
[ci-105-2493316c:08193] [11]
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(+0x1c180)[0xf744b180]
[ci-105-2493316c:08193] [12]
/usr/bin/python3.10(_PyObject_MakeTpCall+0x257)[0x5679c727]
[ci-105-2493316c:08193] [13] /usr/bin/python3.10(+0x156fd8)[0x567a4fd8]
[ci-105-2493316c:08193] [14]
/usr/bin/python3.10(PyObject_CallFunctionObjArgs+0x33)[0x567a4e03]
[ci-105-2493316c:08193] [15] /usr/bin/python3.10(+0x21f6b1)[0x5686d6b1]
[ci-105-2493316c:08193] [16]
/usr/bin/python3.10(_PyObject_GenericSetAttrWithDict+0x616)[0x5677bed6]
[ci-105-2493316c:08193] [17]
/usr/bin/python3.10(PyObject_SetAttr+0x61)[0x5677b751]
[ci-105-2493316c:08193] [18]
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0x1403)[0x567915e3]
[ci-105-2493316c:08193] [19] /usr/bin/python3.10(+0x163abf)[0x567b1abf]
[ci-105-2493316c:08193] [20]
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0xad1)[0x56790cb1]
[ci-105-2493316c:08193] [21]
/usr/bin/python3.10(_PyFunction_Vectorcall+0x8f)[0x567a583f]
[ci-105-2493316c:08193] [22]
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0xc9f)[0x56790e7f]
[ci-105-2493316c:08193] [23] /usr/bin/python3.10(+0x163c00)[0x567b1c00]
[ci-105-2493316c:08193] [24]
/usr/bin/python3.10(PyObject_Call+0x71)[0x567b2641]
[ci-105-2493316c:08193] [25]
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0x2cc2)[0x56792ea2]
[ci-105-2493316c:08193] [26]
/usr/bin/python3.10(_PyObject_FastCallDictTstate+0xb8)[0x5679b988]
[ci-105-2493316c:08193] [27]
/usr/bin/python3.10(_PyObject_Call_Prepend+0x54)[0x567aef54]
[ci-105-2493316c:08193] [28] /usr/bin/python3.10(+0x26182d)[0x568af82d]
[ci-105-2493316c:08193] [29]
/usr/bin/python3.10(_PyObject_MakeTpCall+0x257)[0x5679c727]
[ci-105-2493316c:08193] *** End of error message ***
Segmentation fault
autopkgtest [15:27:16]: test yadetest

#1009739#16
Date:
2022-05-01 18:03:04 UTC
From:
To:
yade was removed from testing, and also is not installable on i386. Reassigning
until we can investigate if that's a Python issue.

#1009739#25
Date:
2022-05-22 20:49:09 UTC
From:
To:
Dear Maintainer,
just tried to see if I can find some more information.
I was able to reproduce the issue and got the stack below.

I debugged a little back and forth and guess the issue
is related to the way a PyLongObject stores its value in
the ob_digit array.

Unfortunately boost looks like it expects a pointer to be
stored in "ob_digit" having just one element.
But in my example the value 0x9e56f420 takes up three elements,
looks like because PyLong_SHIFT is 15 bits at i386.
This conversation takes place in function PyLong_FromLong.

Therefore the third digit of ob_digit occupies the memory
that is also used for the "name" member, therefore got a
value != 0, and is tried to be destroyed and segfaults there.

Maybe someone with more detailed Python knowledge can confirm
this being a bug in boost placing the name member of
boost::python::objects::enum_object after the base_object
and therefore base_object having "ob_digit" just one element?


Following bug reports in yade and boost might be related to this issue:
https://gitlab.com/yade-dev/trunk/-/issues/239
https://github.com/boostorg/python/issues/312

Kind regards,
Bernhard



Thread 1 received signal SIGSEGV, Segmentation fault.
_Py_XDECREF (op=<unknown at remote 0x1>) at /usr/include/python3.10/object.h:567
567             Py_DECREF(op);
1: x/i $pc
=> 0xb70dfd7b <boost::python::objects::enum_dealloc(boost::python::objects::enum_object*)+27>:  subl   $0x1,(%eax)
(rr) bt 15
#0  _Py_XDECREF (op=<unknown at remote 0x1>) at /usr/include/python3.10/object.h:567
#1  boost::python::objects::enum_dealloc (self=0x9e56f410) at libs/python/src/object/enum.cpp:40
#2  0x0058bd56 in subtype_dealloc (self=<EnumClass_BlinkHighlight at remote 0x9e56f410>) at ../Objects/typeobject.c:1458
#3  0xb71137f9 in _Py_DECREF (op=<optimized out>) at /usr/include/python3.10/object.h:500
#4  boost::python::api::object_base::~object_base (this=0xbfd170a8, __in_chrg=<optimized out>) at /usr/include/boost/python/object_core.hpp:423
#5  0xb3e0d4b8 in boost::python::api::object::~object (this=0xbfd170a8, __in_chrg=<optimized out>) at /usr/include/boost/python/object_core.hpp:238
#6  yade::ArbitraryEnum_from_python<yade::OpenGLRenderer::BlinkHighlight>::setArbitraryEnum (arg=..., col=@0xbfd17250: yade::OpenGLRenderer::BlinkHighlight::NEVER) at ./lib/serialization/EnumSupport.hpp:76
#7  0xb3e0ef75 in yade::ArbitraryEnum_from_python<yade::OpenGLRenderer::BlinkHighlight>::convertible (obj_ptr=<optimized out>) at ./lib/serialization/EnumSupport.hpp:92
#8  0xb70dd5bd in boost::python::converter::rvalue_from_python_stage1 (source='NEVER', converters=...) at libs/python/src/converter/from_python.cpp:54
#9  0xb3e03337 in boost::python::converter::arg_rvalue_from_python<yade::OpenGLRenderer::BlinkHighlight const&>::arg_rvalue_from_python (obj='NEVER', this=0xbfd1733c) at /usr/include/boost/python/converter/arg_from_python.hpp:296
#10 boost::python::arg_from_python<yade::OpenGLRenderer::BlinkHighlight const&>::arg_from_python (source='NEVER', this=0xbfd1733c) at /usr/include/boost/python/arg_from_python.hpp:70
#11 boost::python::detail::caller_arity<2u>::impl<boost::python::detail::member<yade::OpenGLRenderer::BlinkHighlight, yade::OpenGLRenderer>, boost::python::return_value_policy<boost::python::return_by_value, boost::python::default_call_policies>, boost::mpl::vector3<void, yade::OpenGLRenderer&, yade::OpenGLRenderer::BlinkHighlight const&> >::operator() (args_=<optimized out>, this=<optimized out>) at /usr/include/boost/preprocessor/iteration/detail/local.hpp:37
#12 boost::python::objects::caller_py_function_impl<boost::python::detail::caller<boost::python::detail::member<yade::OpenGLRenderer::BlinkHighlight, yade::OpenGLRenderer>, boost::python::return_value_policy<boost::python::return_by_value, boost::python::default_call_policies>, boost::mpl::vector3<void, yade::OpenGLRenderer&, yade::OpenGLRenderer::BlinkHighlight const&> > >::operator() (this=0x2175a10, args=(<OpenGLRenderer at remote 0xa20a15c8>, 'NEVER'), kw=0x0) at /usr/include/boost/python/object/py_function.hpp:38
#13 0xb70e6974 in boost::python::objects::py_function::operator() (kw=0x0, args=(<OpenGLRenderer at remote 0xa20a15c8>, 'NEVER'), this=0x21759e8) at ./boost/python/object/py_function.hpp:147
#14 boost::python::objects::function::call (this=0x21759e0, args=<optimized out>, keywords=<optimized out>) at libs/python/src/object/function.cpp:221
(More stack frames follow...)

(rr) print/x $eax
$1 = 0x1
(rr) print op
$2 = <unknown at remote 0x1>

(rr) print self
$3 = (boost::python::objects::enum_object *) 0x9e56f410
(rr) print *self
$4 = {base_object = {ob_base = {ob_base = {ob_refcnt = 0, ob_type = 0xb71b0b38}, ob_size = -3}, ob_digit = {3056}}, name = <unknown at remote 0x1>}
(rr) print sizeof(*self)
$5 = 20
(rr) print *self->base_object->ob_base->ob_base->ob_type
$6 = {ob_base = {ob_base = {ob_refcnt = 6, ob_type = 0x9ce9a0 <PyType_Type>}, ob_size = 0}, tp_name = 0xb7207578 "EnumClass_BlinkHighlight", tp_basicsize = 20, tp_itemsize = 2, tp_dealloc = 0x58ba60 <subtype_dealloc>, tp_vectorcall_offset = 0, tp_getattr = 0x0, tp_setattr = 0x0, tp_as_async = 0xb71b0c04, tp_repr = 0xb70dfde0 <boost::python::objects::enum_repr(PyObject*)>, tp_as_number = 0xb71b0c14, tp_as_sequence = 0xb71b0cb0, tp_as_mapping = 0xb71b0ca4, tp_hash = 0x547e00 <long_hash>, tp_call = 0x0, tp_str = 0xb70dfdb0 <boost::python::objects::enum_str(PyObject*)>, tp_getattro = 0x574a40 <PyObject_GenericGetAttr>, tp_setattro = 0x54bbd0 <PyObject_GenericSetAttr>, tp_as_buffer = 0xb71b0cd8, tp_flags = 21517824, tp_doc = 0x0, tp_traverse = 0x58e3c0 <subtype_traverse>, tp_clear = 0x5ee3e0 <subtype_clear>, tp_richcompare = 0x583830 <long_richcompare>, tp_weaklistoffset = 0, tp_iter = 0x0, tp_iternext = 0x4f7c0b <_PyObject_NextNotImplemented>, tp_methods = 0x0, tp_members = 0xb71b0cf4, tp_getset = 0x0, tp_base = 0xb7106020 <boost::python::objects::enum_type_object>, tp_dict = {'__slots__': (), 'values': {0: <EnumClass_BlinkHighlight at remote 0xb71ae5a8>, 1: <EnumClass_BlinkHighlight at remote 0xb71ae648>, 2: <EnumClass_BlinkHighlight at remote 0xb71ae8e8>}, 'names': {'NEVER': <...>, 'NORMAL': <...>, 'WEAK': <...>}, '__module__': 'yade', '__doc__': None, 'NEVER': <...>, 'NORMAL': <...>, 'WEAK': <...>}, tp_descr_get = 0x0, tp_descr_set = 0x0, tp_dictoffset = 0, tp_init = 0x573340 <object_init>, tp_alloc = 0x546810 <PyType_GenericAlloc>, tp_new = 0x5a1da0 <long_new>, tp_free = 0x548280 <PyObject_GC_Del>, tp_is_gc = 0x0, tp_bases = (<type at remote 0xb7106020>,), tp_mro = (<type at remote 0xb71b0b38>, <type at remote 0xb7106020>, <type at remote 0x9ce620>, <type at remote 0x9ce8c0>), tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = <weakref at remote 0xb71a6168>, tp_del = 0x0, tp_version_tag = 1031, tp_finalize = 0x0, tp_vectorcall = 0x0}

(rr) x/5xw self
0x9e56f410:     0x00000000      0xb71b0b38      0xfffffffd      0x43520bf0
0x9e56f420:     0x00000001

(rr) ptype /o self
type = struct boost::python::objects::enum_object {
/*      0      |      16 */    PyLongObject base_object;
/*     16      |       4 */    PyObject *name;

                                /* total size (bytes):   20 */
                              } *

(rr) ptype /o PyLongObject
type = struct _longobject {
/*      0      |      12 */    PyVarObject ob_base;
/*     12      |       2 */    digit ob_digit[1];
/* XXX  2-byte padding   */

                                /* total size (bytes):   16 */
                              }

(rr) print/x self->base_object->ob_digit[0]
$7 = 0xbf0
(rr) print/x self->base_object->ob_digit[1]
$8 = 0x4352
(rr) print/x self->base_object->ob_digit[2]
$9 = 0x1

(rr) print &self->base_object->ob_digit[2]
$10 = (digit *) 0x9e56f420
(rr) print &self->name
$11 = (PyObject **) 0x9e56f420








(rr) bt 15
#0  PyLong_FromLong (ival=-1638468592) at ../Objects/longobject.c:44
#1  0xb70e00e2 in boost::python::converter::arg_to_python<long>::arg_to_python (x=<optimized out>, this=0xbfd16fc4) at ./boost/python/converter/builtin_converters.hpp:123
#2  boost::python::call<boost::python::api::object, long> (a0=@0xbfd16ff4: -1638468592, a0=@0xbfd16ff4: -1638468592, callable=<type at remote 0xb71b0b38>) at ./boost/python/call.hpp:65
#3  boost::python::api::object_operators<boost::python::api::object>::operator()<long> (a0=@0xbfd16ff4: -1638468592, this=<synthetic pointer>) at ./boost/python/object_call.hpp:19
#4  boost::python::objects::enum_base::to_python (type_=0xb71b0b38, x=-1638468592) at libs/python/src/object/enum.cpp:249
#5  0xb3dfdd25 in boost::python::enum_<yade::OpenGLRenderer::BlinkHighlight>::to_python (x=0xbfd17250) at /usr/include/boost/python/enum.hpp:54
#6  0xb70ee5bd in boost::python::converter::detail::arg_to_python_base::arg_to_python_base (this=0xbfd170d4, source=0xbfd17250, converters=...) at libs/python/src/converter/arg_to_python_base.cpp:23
#7  0xb3e0ca48 in boost::python::converter::detail::value_arg_to_python<yade::OpenGLRenderer::BlinkHighlight>::value_arg_to_python (x=@0xbfd17250: (unknown: 0x9e56f410), this=0xbfd170d4) at /usr/include/boost/python/converter/arg_to_python.hpp:204
#8  boost::python::converter::arg_to_python<yade::OpenGLRenderer::BlinkHighlight>::arg_to_python (x=@0xbfd17250: (unknown: 0x9e56f410), this=0xbfd170d4) at /usr/include/boost/python/converter/arg_to_python.hpp:252
#9  boost::python::api::object_initializer_impl<false, false>::get<yade::OpenGLRenderer::BlinkHighlight> (x=@0xbfd17250: (unknown: 0x9e56f410)) at /usr/include/boost/python/object_core.hpp:289
#10 boost::python::api::object_base_initializer<yade::OpenGLRenderer::BlinkHighlight> (x=@0xbfd17250: (unknown: 0x9e56f410)) at /usr/include/boost/python/object_core.hpp:232
#11 boost::python::api::object::object<yade::OpenGLRenderer::BlinkHighlight> (x=@0xbfd17250: (unknown: 0x9e56f410), this=0xbfd170a8) at /usr/include/boost/python/object_core.hpp:247
#12 yade::ArbitraryEnum_from_python<yade::OpenGLRenderer::BlinkHighlight>::setArbitraryEnum (arg=..., col=@0xbfd17250: (unknown: 0x9e56f410)) at ./lib/serialization/EnumSupport.hpp:51
#13 0xb3e0ef75 in yade::ArbitraryEnum_from_python<yade::OpenGLRenderer::BlinkHighlight>::convertible (obj_ptr=<optimized out>) at ./lib/serialization/EnumSupport.hpp:92
#14 0xb70dd5bd in boost::python::converter::rvalue_from_python_stage1 (source='NEVER', converters=...) at libs/python/src/converter/from_python.cpp:54
(More stack frames follow...)

(rr) print/x ival
$180 = 0x9e56f410

#1009739#30
Date:
2022-05-22 22:33:42 UTC
From:
To:
Am 22.05.22 um 22:49 schrieb Bernhard Übelacker:
Short addition:
to prove my suspicion the fault being at boost side,
I rebuilt locally the boost1.74 package with the
modification below, and the before crashing yade test
went through with "*** ALL TESTS PASSED ***".
The below test is just an attempt to avoid overwriting
the name pointer by placing a few dummy bytes in the struct.
--- orig/boost1.74-1.74.0/libs/python/src/object/enum.cpp       2022-05-22 14:50:12.000000000 +0200
+++ try1/boost1.74-1.74.0/libs/python/src/object/enum.cpp       2022-05-22 22:56:38.961526419 +0200
@@ -23,6 +23,7 @@ struct enum_object
  #else
      PyIntObject base_object;
  #endif
+    char foo[4];
      PyObject* name;
  };

#1009739#35
Date:
2022-05-26 16:35:10 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
yade, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1009739@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Anton Gladky <gladk@debian.org> (supplier of updated yade package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 26 May 2022 17:39:05 +0200
Source: yade
Architecture: source
Version: 2022.01a-8
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Anton Gladky <gladk@debian.org>
Closes: 1009739
Changes:
 yade (2022.01a-8) unstable; urgency=medium
 .
   * [fc5ece6] Do not run a special test on i486. (Closes: #1009739)
Checksums-Sha1:
 a39c54397d120836edabf43a49a114898b0ef5db 3000 yade_2022.01a-8.dsc
 2bb7721b7174ef39b19c808cb3e95e0404adcdd5 45612 yade_2022.01a-8.debian.tar.xz
 58a7343282c547036e47bd1427b5be7b4ef3e00d 12169 yade_2022.01a-8_source.buildinfo
Checksums-Sha256:
 200f41216f629e5f910549b3c556d049ef85a44bf22f5e33b2141594e35a7021 3000 yade_2022.01a-8.dsc
 795059d5be22246f0263d5476abe4b7d373d42011338843ed158d9d90ff458f3 45612 yade_2022.01a-8.debian.tar.xz
 de756c46b64536ca8a50b9815d0bd3d7caf01a44f9914a0689ba038f9800278c 12169 yade_2022.01a-8_source.buildinfo
Files:
 f00606a220238be3d9800b1b915faa72 3000 science optional yade_2022.01a-8.dsc
 137f5f6a8c1f6a81ab4289d62a1ba172 45612 science optional yade_2022.01a-8.debian.tar.xz
 f5684b0bece4fc50f5671ca62a3ceffa 12169 science optional yade_2022.01a-8_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmKPqoQACgkQ0+Fzg8+n
/wbVdBAAmOZEaEyDuFuHKH3VDOeQScXBFBleUy1q0XulPIirxhYNhKWfP8Ne1fvi
Ea+9Os7aYmguk/haaiAGoTTz8g1y7ffmi4voNwJuw2q5HceFw+/CUKm56sKxAASv
52JKb5DAveOljvQnDG28agPKph4cta4e54+4tH/DL2FHnGp8SiaQDWItZjknZ5AA
KZliTh/ZLIzUAtNHucJ0ZZKLdKfOs1xilCUp4Gvep/knOG5Z3Qu45F8liPoK5Tv2
oom0XrUcaBRy1hfm0LKRpzbZU0PRbE8Rj7s0cJRuBkztPNDDweu7lgz4NoMzp9ab
krtIncR6iTSF+UD6vKiO8YgANqOGrWBi0K86XNWA9FSSyuzNMA+Uo8F2p94bxK2b
pytBEzzvfZ+JFATNLQtWOnoW+3dkqdXN7DqJw0p+P6YClE8bj0jjROa5YjLqcS9X
F/9oOg9FZYSSX3n86Bd/FcaAip15QZNgrkBZzNa5Eyv6IiS5irnwfLrqcWzZ9QbQ
D+QxOBCHTcR1NiiX7phkreCxdS8n8AOzmfvXqhzVuv7Pv/kpDjqUc5tVk5TG+geu
KOuBzzgbFAfcGuFgmtJLVojKYafuoXT2CN4kOGUlP/D2ljYiLaaPb5IRk3PTBv1y
hFxBynfp//V4j1XfJYtdB/ljpW6SqYxyzCj1Vg2+5QLYlM5oJiQ=
=Htth
-----END PGP SIGNATURE-----

#1009739#40
Date:
2022-05-29 14:37:45 UTC
From:
To:
Dear Maintainer,
while disabling the test in yade works around the issue,
I tried to create a merge request for boost ready [1].
If that would get accepted to boost the workaround in yade
could be removed again.

Kind regards,
Bernhard

[1] https://salsa.debian.org/debian/boost/-/merge_requests/6

#1009739#45
Date:
2022-05-31 04:56:23 UTC
From:
To:
Hi Bernhard,

Thank you very much for this information and for fixing it!

I have just uploaded boost1.74_1.74.0-15 with this fix and
will revert the workaround in yade!

Best regards

Anton

#1009739#50
Date:
2022-05-31 22:12:05 UTC
From:
To:
Hello Anton,
I am happy if my work helps.
And I am sorry, but I fear my test shows now a failure
for armhf and armel too.

 From 'echo | gcc -dM -E - | grep -i arm' I see gcc has
on both platforms predefined the macro __ARMEL__.
But I am not sure what is the best way to just detect those
platforms, or maybe just check for sizeof(void*)==4 or similar.

Kind regards,
Bernhard

#1009739#55
Date:
2022-06-01 05:17:50 UTC
From:
To:
Hi Bernhard,

I think one can ask the corresponding arm-mailing list. Anyway,
if you have a solution for that I could test it first on the real hardware.

Thanks

Anton

Am Mi., 1. Juni 2022 um 00:12 Uhr schrieb Bernhard Übelacker
<bernhardu@mailbox.org>:

#1009739#60
Date:
2022-06-01 15:18:02 UTC
From:
To:
Hello Anton,
I created another merge request with adding the __ARMEL__ macro.
That way armhf and armel should pick it up, while arm64
has this macro not defined.

Kind regards,
Bernhard


Am 01.06.22 um 07:17 schrieb Anton Gladky: