Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
On 2015-04-02 22:14, Moritz Mühlenhoff wrote: On Sun, Mar 29, 2015 at 07:30:55PM -0700, Tom Lee wrote: Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Alternatively remove the arm* binaries (capnproto is new in jessie and has no reverse deps) and let ARM porters figure it out if they want support for capnproto in the future. Cheers, Moritz Hi Tom, Any news on this bug? If nothing changes soon, capnproto will be autoremoved in 5-6 days from now. As Moritz suggested, removing capnproto from arm* is a viable alternative for Jessie. Simply file a bug against ftp.debian.org requesting their removal from unstable (remember to make it architecture specific). :) Please note that the ftp-masters can be a few days at processing your request. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
On Sun, Mar 29, 2015 at 07:30:55PM -0700, Tom Lee wrote: Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Alternatively remove the arm* binaries (capnproto is new in jessie and has no reverse deps) and let ARM porters figure it out if they want support for capnproto in the future. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
Vincent captured a gdb backtrace + the test-suite.log output for me.
Nothing's leaping out at me at a glance, I can take a closer look tonight.
Forwarded both upstream in case they can see what's going on.
Test failure seems to be capnp::_::(anonymous
namespace)::Capability_DynamicClientInheritance_Test::TestBody
(this=this@entry=0xb8250978) at src/capnp/capability-test.c++:275 in the
bowels of some upcast operation.
Posting the full logs here for completeness:
* Run the failing test via:
./libtool --mode=execute gdb capnp-test
For some reason, I got an illegal instruction in the dynamic
linker. Instead, I have enabled core dumping and used gdb on that:
Core was generated by `/home/bernat/capnproto-0.4.1/.libs/lt-capnp-test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb6ab982c in capnp::DynamicCapability::Client::upcast (this=this@entry
=0xbec1e6d8,
requestedSchema=requestedSchema@entry=...) at
src/capnp/dynamic-capability.c++:33
33return DynamicCapability::Client(requestedSchema, hook-addRef());
(gdb) bt full
#0 0xb6ab982c in capnp::DynamicCapability::Client::upcast (this=this@entry
=0xbec1e6d8,
requestedSchema=requestedSchema@entry=...) at
src/capnp/dynamic-capability.c++:33
No locals.
#1 0xb6d62568 in capnp::_::(anonymous namespace)::Capability_
DynamicClientInheritance_Test::TestBody (this=this@entry=0xb8250978) at
src/capnp/capability-test.c++:275
request1 = {capnp::DynamicStruct::Builder = {schema =
{capnp::Schema = {
raw = 0xbec1e800}, No data fields},
builder = {kj::DisallowConstCopy = {No data fields},
segment = 0xb6992008,
data = 0xb699af28 std::string::_Rep::_S_empty_rep_storage,
pointers =
0xb6bb6570
testing::internal::StringStreamToString(std::basic_stringstreamchar,
std::char_traitschar, std::allocatorchar *)+476, dataSize =
3063524026, pointerCount = 59300,
bit0Offset = 193 '\301'}}, hook = {disposer = 0x1, ptr = 0x0},
resultSchema = {capnp::Schema = {raw = 0xb824ff84}, No data
fields}}
promise1 = {kj::Promisecapnp::Responsecapnp::DynamicStruct =
{kj::_::PromiseBase = {node = {disposer = 0xbec1e8c4, ptr =
0xb6c44f10 __stack_chk_guard}}, No data fields},
capnp::DynamicStruct::Pipeline = {
schema = {capnp::Schema = {raw = 0xbec1e7a8}, No data
fields}, typeless = {
hook = {disposer = 0xb824ff78, ptr = 0xbec1e7a4}, ops = {ptr
= 0xb6991fcc,
size_ = 3063488480, disposer = 0xb6bea7b0}}}, No data
fields}
response2 = {capnp::DynamicStruct::Reader = {schema =
{capnp::Schema = {
raw = 0xb6f4b88c
kj::_::HeapDisposercapnp::_::TestExtendsImpl::instance},
No data fields}, reader = {segment = 0x0, data = 0xb67d9000, pointers =
0xb67d9504,
dataSize = 132016, pointerCount = 2656, bit0Offset = 114 'r',
nestingLimit = 0}}, hook = {disposer = 0xb6719af8, ptr =
0xb67d9228}}
client = {capnp::Capability::Client = {hook = {disposer = 0x0,
ptr = 0x0}},
schema = {capnp::Schema = {raw = 0x20}, No data fields}}
request2 = {capnp::DynamicStruct::Builder = {schema =
{capnp::Schema = {
raw = 0xb6f4b88c
kj::_::HeapDisposercapnp::_::TestExtendsImpl::instance},
No data fields}, builder = {kj::DisallowConstCopy = {No data fields},
segment = 0x0,
data = 0x0, pointers = 0xb6991fcc, dataSize = 3063489304,
pointerCount = 3708,
bit0Offset = 37 '%'}}, hook = {disposer = 0xb8250e7c, ptr =
0xb8250e7d},
resultSchema = {capnp::Schema = {raw = 0xb8250e7c}, No data
fields}}
promise2 = {kj::Promisecapnp::Responsecapnp::DynamicStruct =
{kj::_::PromiseBase = {node = {disposer = 0xbec1e8c4,
ptr = 0xb6c44f10 __stack_chk_guard}}, No data fields},
capnp::DynamicStruct::Pipeline = {schema = {capnp::Schema = {raw =
0xb6992044}, No data fields},
typeless = {hook = {disposer = 0xb6905578 operator
delete(void*)+8,
ptr = 0xb6bf92b0 pthread_key_create}, ops = {
ptr = 0xb696d1d8
std::string::_Rep::_M_destroy(std::allocatorchar
const)+8, size_ = 3066008240,
disposer = 0xb6bb4708
std::string::_Rep::_M_dispose(std::allocatorchar
const)+100}}}, No data fields}
response1 = {capnp::DynamicStruct::Reader = {schema =
{capnp::Schema = {
raw = 0xb6f46240 capnp::schemas::s_88eb12a0e0af92b2}, No
data fields},
reader = {segment = 0xb825098c, data = 0x0, pointers = 0x203b0,
dataSize = 3089435728, pointerCount = 2, bit0Offset = 0
'\000',
nestingLimit = -1233285120}}, hook = {disposer = 0x2, ptr =
0x0}}
loop = {port = @0xb6a06004, running = false, lastRunnableState =
false, head = 0x0,
tail = 0xbec1e710, depthFirstInsertPoint = 0xbec1e710, daemons = {
disposer = 0xb6a04f24 kj::_::HeapDisposerkj::_::
TaskSetImpl::instance,
ptr = 0xb8250760}}
waitScope = {loop =
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
On 2015-03-30 04:30, Tom Lee wrote: Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Cheers, Tom [...] Hi Tom, I see no problem in adding a VERBOSE=1 (or --disable-silent-rules, or whatever), as it does not have an effect of the produced built. In fact, I am not aware of any other way to obtain the test-suite.log from the buildds. To my knowledge, the buildds more or less discards the build environment immediately after the build terminates. My best alternative is for you to get -guest access to a porterbox and try to reproduce it there[1]. It may take some time before you get such an account. It might make sense for you to try that in parallel with the build logs - just in case the build logs are not enough for you to fix the issue. DDs also have access to porterboxes, so you might also be able to convince your sponsor to help you with obtaining additional information from the porterbox. Though, in this case, you will probably want to stack up a few things to save a few roundtrips. Maybe something like: * Please build the package and which fail the tests * Extract test-build.log * Run the test via gdb and do a bt at the point it seg. faults. * Extract stacktrace from gdb and attach it along with the test-build.log * ... Thanks, ~Niels [1] https://dsa.debian.org/doc/guest-account/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Cheers, Tom On Sun, Mar 29, 2015 at 4:45 AM, Niels Thykier ni...@thykier.net wrote: Source: capnproto Version: 0.4.1-3 Severity: serious Hi, It seems that the current version of capnproto FTBFS on armel and armhf due to a segmentation fault in one of the tests. This prevents the new version of migrating to testing as it is a regression compared to the version in testing. Thanks, ~Niels -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
Source: capnproto Version: 0.4.1-3 Severity: serious Hi, It seems that the current version of capnproto FTBFS on armel and armhf due to a segmentation fault in one of the tests. This prevents the new version of migrating to testing as it is a regression compared to the version in testing. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
