Bug#911698: ITS: tbb
Hi Mo, I maintain the package and we had it hosted on Debian Science. I would like to keep maintaining the package, but I am happy to co-maintain the package with others. Out of interest, what would you like doing with the package? Would you like the version updating? Thanks, -- Steve
Bug#877380: tbb: fix __TBB_EXCEPTION_PTR_PRESENT for armel
Hi, Thank you for the bug report (and patch!), I have just travelled back home and plan on pushing a fix today after I finish work. Cheers, -- Steve On 4 October 2017 at 09:04, Petter Reinholdtsen wrote: > This issue block slic3r-prusa from entering testing, as it break the > armel build for this package. Any chance to have a fixed libtbb-dev > package uploaded soon? > -- > Happy hacking > Petter Reinholtsen >
Bug#832104: Fixed in experimental 2017~U7-7~exp1
Hi, The cause of the sparc64 build failure was a deliberate unaligned memory access in test_malloc_pools. I have removed this specific code (as unaligned accesses provoke a SIGBUS on sparc64) whilst retaining the rest of the test and the suite now appears to be passing. https://buildd.debian.org/status/fetch.php?pkg=tbb&arch=sparc64&ver=2017~U7-7~exp1&stamp=1502748989&raw=0 Cheers, -- Steve
Bug#870134:
Lowering severity of this as the build failure is extremely hard to reproduce (was completely unable to exacerbate this on the porterbox and a subsequent build for this has succeeded on a similar hw configuration that threw a problem before). Debugging machinery has been introduced into 2017~U7-5 to grab telemetry should this happen again. Will leave this bug open whilst I perform more builds. Cheers, -- Steve
Bug#870134: TBB builds on 32-bit MIPS platforms
Package: tbb Version: 2017~U7-4 Severity: important I am the maintainer of tbb, and am raising this bug here so my progress on mips builds can be tracked. Looking at the build output from buildd, it looks like the tbbmalloc internals structures are invalid: ./test_malloc_pools.exe 1:4 Assertion right->myL.value<=GuardedSize::MAX_SPEC_VAL failed on line 1483 of file ../../src/tbbmalloc/backend.cpp From: https://anonscm.debian.org/cgit/debian-science/packages/tbb.git/tree/src/tbbmalloc/backend.cpp?h=debian/2017_U7-4#n1483 I am reviewing the code and trying to figure out what the issue is. This may be memory pressure related, but unfortunately, I have been unable to reproduce this in QEMU (with Malta board and 1 CPU). I have filed a request for access to a mipsel buildd, and will give this a good going over in gdb once I have access. [ I am particularly interested in the Freeblock structures dereferenced. Then I was going to work backwards to try and find the source of the corruption. ] Cheers, -- Steve
Bug#869609: libgpg-error is unecessarily hard to bootstrap for new architectures/ABIs
Hi, So going through this my understanding is that for Linux this library creates weak references to the pthread_mutex_ functions as well as simulates the size of the pthread_mutex_t type. IIUC this obviates the need to cross-compile against pthreads. When one loads the library, the weak references will be overridden by the C library and, providing the data type is the same as simulated, should operate as one is using pthreads. If the simulated data type does not match the system implementation, I am not sure what behaviour will manifest. I don't understand why one cannot cross-compile a library that makes use of pthreads directly though? Was this weak function/type simulation workaround needed for a bug in the past that has since been fixed? Have we missed something obvious? Cheers, -- Steve
Bug#832104: [sparc64] Program received signal SIGBUS, Bus error.
Hi Mathieu, Thanks for this, and apologies for my late reply getting to this bug. Reading through your gdb logs (thanks!), I think the sigbus was caused by an unaligned memory access. The pointer for `region' appears to be odd 0x800101074021 and we're writing to an enum (at an even offset to the struct thus odd address overall) which is larger than a byte. I'm not sure how to fix this, will do some thinking :-). I suspect allocRawMem should be adjusted. I've updated the package to 2017 Update 7 and the debian-science folk have kindly set up a git repo at: https://anonscm.debian.org/cgit/debian-science/packages/tbb.git/ Cheers, -- Steve
Bug#850447: systemd backport sections only 4K aligned, won't boot with arm64 64K kernel
Hi, FWIW, I found that disabling gold (by tweaking configure.ac) then led to executables with the correct alignment. Cheers, -- Steve
Bug#809663: Add support for s390x / hppa
Thank you Mathieu, I've incorporated this into: tbb_4.3~20150611-1 as well as some minor telemetry and build timeout changes. Cheers, -- Steve On 2 January 2016 at 14:13, Mathieu Malaterre wrote: > Package: tbb > Version: 4.3~20150611-0.1 > Tags: patch > > Attached is a patch to get s390x and hppa debian package. > > Enjoy >
Bug#816989: tbb: FTBFS in testing (Build killed with signal TERM after 150 minutes of inactivity)
On 28 May 2016 at 21:12, Tobias Frost wrote: > Severity: -1 important > > On Sun, 17 Apr 2016 10:00:12 +0200 (CEST) Santiago Vila s> wrote: > > retitle 816989 tbb: FTBFS in testing (Build killed with signal TERM > after 150 minutes of inactivity) > > severity 816989 serious > > thanks > > > > This is a normal FTBFS, not related at all with "dpkg-buildpackage > -A" > > > > The package is "blacklisted" in reproducible builds: > > > > https://reproducible.debian.net/rb-pkg/unstable/amd64/tbb.html > > > > so I'm not the only one to reproduce this. > > > > > > I tried to reproduce this, but I was not able to do it in a local sid > pbuilder envrioment, neither building nor when only building arch- > independt. So I think we should downgrade it.. > > > Hi, Sorry about getting back to this late. I am unable to reproduce the stall here on amd64. I can see 4.3~20150611-1~exp3 passes the test? https://reproducible.debian.net/rbuild/experimental/amd64/tbb_4.3~20150611-1~exp3.rbuild.log I will better familiarise myself with FTBFS; one thing I have found is that the unit tests can hang on certain boxes. Cheers, -- Steve
Bug#805481: One important omission
On 18 November 2015 at 18:23, Michael Biebl wrote: > Am 18.11.2015 um 18:35 schrieb Steven Capper: > > Upgrading to 227-1 caused immediate segfaults and led to the same > > unbootable machine. > > > > So it looks like something introduced 227-1. > > I would guess this was introduced by > > > https://github.com/poettering/systemd/commit/75f86906c52735c98dc0aa7e24b773edb42ee814 > > This is a quite invasive patch, so it's probably not that simply to > revert in on top of v227. > > Steven, we uploaded 228-1 today. It would be great if you can pull that > version from unstable (should hit the mirrors in a couple of hours). > Hi Michael, I've installed 228-1 and it appears to be working well. I've booted the system a few times and haven't seen any segfaults or other problems. Cheers, -- Steve > > If this version is still affected we should take this upstream I think. > > Michael > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#805481: One important omission
On 18 November 2015 at 17:20, Michael Biebl wrote: > Hi Steve, > > Am 18.11.2015 um 16:52 schrieb Steven Capper: > > I neglected to mention that this running under a QEMU virtual machine > (same > > error for both KVM acceleration on and off). > > > > I will dig into this a little bit here and will update if I find > anything. > > Can you pinpoint the version when this started failing? > As a start you could pull the snapshots from [1] > > To make debugging easier, you can keep the old sysvinit binary around > (assuming you have a working /etc/inittab). This way you can easily boot > into the system via the grub menu. > > Regards, > Michael > Thanks Michael, I didn't know about snapshots. I pulled down: libsystemd0 226-4 systemd 226-4 That was then sufficient to boot the machine without issue. Upgrading to 227-1 caused immediate segfaults and led to the same unbootable machine. So it looks like something introduced 227-1. Cheers, -- Steve > > > [1] http://snapshot.debian.org/ > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#805481: One important omission
I neglected to mention that this running under a QEMU virtual machine (same error for both KVM acceleration on and off). I will dig into this a little bit here and will update if I find anything. Cheers, -- Steve
Bug#805481: systemd 227-2 SIGSEGV on boot on arm64
Package: systemd
Version: 227-2
Severity: grave
Justification: renders package unusable
-- Package-specific info:
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Kernel: Linux 4.2.0-1-arm64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages systemd depends on:
ii adduser 3.113+nmu3
ii libacl1 2.2.52-2
ii libapparmor12.10-2+b1
ii libaudit1 1:2.4.4-4
ii libblkid1 2.27.1-1
ii libc6 2.19-22
ii libcap2 1:2.24-12
ii libcap2-bin 1:2.24-12
ii libcryptsetup4 2:1.6.6-5
ii libgcrypt20 1.6.4-3
ii libkmod221-1
ii liblzma55.1.1alpha+20120614-2.1
ii libmount1 2.27.1-1
ii libpam0g1.1.8-3.1
ii libseccomp2 2.2.3-2
ii libselinux1 2.3-2+b1
ii libsystemd0 227-2
ii mount 2.27.1-1
ii sysv-rc 2.88dsf-59.2
ii udev227-2
ii util-linux 2.27.1-1
Versions of packages systemd recommends:
ii dbus1.10.2-1
pn libpam-systemd
Versions of packages systemd suggests:
pn systemd-container
pn systemd-ui
-- no debconf information
-- more information
systemd immediately fails on arm64 with a SIGSEGV rendering the system
unbootable.
I have booted up with init=/bin/bash and tried running system mode in gdb
to try and narrow down the problem:
Program received signal SIGSEGV, Segmentation fault.
0x005ac868 in detect_vm () at ../src/basic/virt.c:263
263if (cached_found >= 0)
(gdb) list
258 /* Returns a short identifier for the various VM implementations */
259 int detect_vm(void) {
260static thread_local int cached_found = _VIRTUALIZATION_INVALID;
261int r;
262
263if (cached_found >= 0)
264return cached_found;
265
266/* Try xen capabilities file first, if not found try
267 * high-level hypervisor sysfs file:
(gdb) disassemble $pc
Dump of assembler code for function detect_virtualization:
0x005ac848 <+0>: str x30, [sp,#-16]!
0x005ac84c <+4>: bl 0x5ac680
0x005ac850 <+8>: cbnz w0, 0x5ac870
0x005ac854 <+12>: mrs x1, tpidr_el0
0x005ac858 <+16>: adrp x0, 0x698000
0x005ac85c <+20>: ldr x2, [x0,#960]
0x005ac860 <+24>: nop
0x005ac864 <+28>: nop
=> 0x005ac868 <+32>: ldr w0, [x1,x0]
0x005ac86c <+36>: tbnz w0, #31, 0x5ac878
0x005ac870 <+40>: ldr x30, [sp],#16
0x005ac874 <+44>: ret
0x005ac878 <+48>: ldr x30, [sp],#16
0x005ac87c <+52>: b 0x5ac388
End of assembler dump.
(gdb) info registers
x0 0x698000 366505197568
x1 0x7fb7bea6f0 548543571696
x2 0x14 20
x3 0x7fee80 549755809408
x4 0x1 1
x5 0x0 0
x6 0x8000 140737488355328
x7 0x1 1
x8 0x42 66
x9 0x711f33356bff284d 8151290155102054477
x100x7f7f7f7f7f7f7f7f 9187201950435737471
x110x101010101010101 72340172838076673
x120x10 16
x130x20504d4f43434553 2328446010176783699
x140x2d2044494b4c422b 3251674012548088363
x150x7fb7e28588 548545922440
x160x698498 366505198744
x170x7fb7d5b2fc 548545082108
x180x7ff8e0 549755812064
x190x69c320 366505214752
x200x699000 366505201664
x210x69a000 366505205760
x220x69b320 366505210656
x230x699000 366505201664
x240x0 0
x250x699000 366505201664
x260x7ffd28 549755813160
x270x698000 366505197568
x280x69c3db 366505214939
x290x7ff820 549755811872
x300x5ac850 366504233040
sp 0x7ff800 0x7ff800
pc 0x5ac868 0x5ac868
cpsr 0x0 0
fpsr 0x0 0
fpcr 0x100 16777216
(gdb) bt full
#0 0x005ac868 in detect_vm () at ../src/basic/virt.c:263
No locals.
#1 detect_virtualization () at ../src/basic/virt.c:410
r =
#2 0x0057f588 in main (argc=0, argv=0x7ffd38) at
../src/core/main.c:1570
v =
m = 0x0
r =
retval = 1
before_startup =
after_startup =
timespan = '\000' ,
"\060\372\267\177\000\000\000(\321\002\000\000\000\000\000
\374\377\377\177\000\000\000\000\360\374\267\177", '\000'
fds = 0x69b320
reexecute = false
shutdown_verb = 0x0
initrd_timestamp = {realtime = 548547799504, monotonic =
548547721128}
userspace_timestamp = {realtime = 881758864, monotonic = 881758864}
kernel_timestamp = {realtime = 0, monotonic = 0}
security_start_timestamp =
Bug#787084: Processed: Re: Bug#787084: Acknowledgement (error: 'tbb::internal::atomic_impl::my_storage' has incomplete type)
Thank you for this patch Mathieu. I've tweaked it a little bit as: 1) The semantics of __atomic_compare_exchange are a little different to __sync_val_compare_and_swap, and my tests were failing. 2) I promoted it to gcc_generic.h as I believe this will be useful for other architectures. :-). This patch is currently applied in experimental: tbb_4.3~20150611-1~exp2. I'm going to transfer more of the __sync_* to __atomic_, then I plan on relaxing the fencing as the next step. Please let me know if this works well/needs further tweaking and I'll hit Sid with it soon. Cheers, -- Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778139: tbb: ftbfs with GCC-5
Hi, Thanks for this. I have been able to reproduce this with tbb_4.2~20140122-5. A new package is being worked on in experimental, tbb_4.3~20150611-1~exp1, and this *does* compile correctly with gcc-5. I will flag this bug as closed as soon as I upload 20150611 to Sid. Cheers, -- Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775506: unblock: tbb/4.2~20140122-4
Hi, arm64 should be building in -5, so shouldn't the arm64 reverse dependancies be unaffected? Under mips, mipsel, and s390x tbb fails to build unit tests due to missing/incorrect gcc atomics. I have very little confidence in the functional correctness of the reverse dependencies, so I would be inclined to remove them to be safe. Mathieu, please shout if I've missed something. Thank you for looking at this and apologies again for me messing things up before the freeze. Steve On 18/02/2015, Mehdi Dogguy wrote: > Hi all, > > Le 2015-01-16 23:37, Jonathan Wiltshire a écrit : >> Control: tag -1 moreinfo >> >> On Fri, Jan 16, 2015 at 03:03:08PM +0100, Mathieu Malaterre wrote: >>> Please unblock package tbb >>> >>> It fixes two grave bugs: #756233 & #762656 >>> It also fixes a longer term issue, as depicted in comment: #775263#17 >>> So I understand the debdiff may be a little long, but unblocking >>> current tbb from sid into testing would solve the issue for the long >>> term. >>> Comments welcome >> >> Not until the maintainer's objections to this upload are resolved. > > I'd like to get this request sorted out. We also want to make sure > that there is no misunderstanding between you two on the technical > decisions implemented in tbb up to -5. > > Besides, it seems that the list of architectures for this package > has been reduced to: amd64, arm64, armhf, hppa, i386, powerpc and > ppc64el. > > It appears that some reverse dependencies should have their binary > packages removed from those packages before getting tbb migrated. > Before proceeding, we want to be sure that this is what you want > and that the list will not change once again in a near future. > > $ dak rm -s testing -nR -a mips,mipsel,arm64,s390x tbb > W: -a/--architecture implies -p/--partial. > Will remove the following packages from testing: > > libtbb-dev | 4.2~20140122-1.1 | mips, mipsel, s390x > libtbb-dev | 4.2~20140122-1.1+b1 | arm64 > libtbb2 | 4.2~20140122-1.1 | mips, mipsel, s390x > libtbb2 | 4.2~20140122-1.1+b1 | arm64 > libtbb2-dbg | 4.2~20140122-1.1 | mips, mipsel, s390x > libtbb2-dbg | 4.2~20140122-1.1+b1 | arm64 > tbb | 4.2~20140122-1.1 | source > > --- Reason --- > > Checking reverse dependencies... > # Broken Depends: > deal.ii: libdeal.ii-8.1.0 [arm64 mipsel] > libdeal.ii-dev [arm64 mipsel] > flexbar: flexbar [arm64 mips mipsel] > mia: libmia-2.2-0 [arm64 mips mipsel] > libmia-2.2-dev [arm64 mips mipsel] > mia-tools [arm64 mips mipsel] > > # Broken Build-Depends: > clasp: libtbb-dev (>= 4.0+r233) > deal.ii: libtbb-dev > feel++: libtbb-dev > flexbar: libtbb-dev > gringo: libtbb-dev (>= 4.0+r233) > mia: libtbb-dev (>= 3.0) > opencv: libtbb-dev > openturns: libtbb-dev > openvdb: libtbb-dev > > Regards, > > -- > Mehdi > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773359: package tbb_4.2~20140122-4 FTBFS on mips and mipsel
On 20 January 2015 at 10:51, Aníbal Monsalve Salazar wrote: > Hello Steven, Hi Aníbal, > > At IMGtech.com, we would like to support this patch for tbb. > > If you prefer, I could sponsor a new Debian version of tbb including > Jurica's patch. > Taking a look at this patch, I would like to experiment with it further and even try to apply it to other architectures (as I believe the atomics to be superior to the old style sync intrinsics, and this may solve some unit test problems we've been experiencing). I was planning on rolling out an experimental package with a tweaked version of this patch in; and if it behaves, was going to put this into Sid. (Then if all goes well, send the patch upstream). Does this sound acceptable to you? Cheers, -- Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762656: patch
On 30 September 2014 11:04, Mathieu Malaterre wrote: > Control: tags -1 patch > > Here is a patch which solve the symptoms. The underlying bug is within > gcc internals where atomics operations are not implementation for > ppc32 targets. > Many thanks Mathieu, This looks good to me. I'm about to go offline for a week (holiday), I will give this a test and incorporate it into the package when I get back. Cheers, -- Steve
Bug#762655: assertion (EBX & rtm_ebx_mask)!=0: failed
Hello Mathieu, On 24 September 2014 08:52, Mathieu Malaterre wrote: > Package: tbb > Version: 4.2~20140122-3 > > Just for reference, why is the test suite not reporting an issue on i386: > > [...] > > sh ../test_summary.sh ./test_mutex.exe 1:3 > Call stack info (7): > ./test_mutex.exe(_Z16print_call_stackv+0x3d)[0x80554bd] > ./test_mutex.exe(_Z11ReportErrorPKciS0_S0_+0xd)[0x80555ad] > ./test_mutex.exe[0x805577c] > ./test_mutex.exe(_Z8TestMainv+0x25d)[0x80559dd] > ./test_mutex.exe(main+0x68)[0x8054f28] > /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf740c723] > ./test_mutex.exe[0x805528c] > ../../src/test/harness_tsx.h:72, assertion (EBX & rtm_ebx_mask)!=0: failed > Aborted > [...] > > and then then later on: > > [...] > > sh ../test_summary.sh ./test_mutex.exe 1:3 > Call stack info (7): > ./test_mutex.exe(_Z16print_call_stackv+0x3d)[0x805371d] > ./test_mutex.exe(_Z11ReportErrorPKciS0_S0_+0xd)[0x805381d] > ./test_mutex.exe[0x80539dc] > ./test_mutex.exe(_Z8TestMainv+0x22a)[0x8053c0a] > ./test_mutex.exe(main+0x68)[0x80531d8] > /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf7481723] > ./test_mutex.exe[0x80535a7] > ../../src/test/harness_tsx.h:72, assertion (EBX & rtm_ebx_mask)!=0: failed > Aborted > [...] > > Summarized as: > > 99 DEBUG tests passed. > The following DEBUG tests FAILED! > ./test_mutex.exe 1:3 > sh ./build/test_summary.sh --dump RELEASE > "./build/linux_ia32_gcc_cc4.9.1_libc2.19_kernel3.2.0_release" > 99 RELEASE tests passed. > The following RELEASE tests FAILED! > ./test_mutex.exe 1:3 > > > > ref: > > https://buildd.debian.org/status/fetch.php?pkg=tbb&arch=i386&ver=4.2~20140122-3&stamp=1411250359 > > > Could you please clarify why this test is ok to fail ? > Unfortunately on the systems I own, a desktop machine (building AMD64 and i386) and an ARMv7 Chromebook, I have not seen a single failure even after a *lot* of test builds. I am trying to gauge which unit tests are failing on which architectures/buildd's/kernels, to better understand what is firing and why. The upstream package ignores the failures by default, and I'm concerned about the validity of some of the tests; so chose to keep the build running. This is alluded to in changelog: * Unit test execution failures no longer cause build to fail; instead take a tally of passes/failures to make it easier to analyse which cases are prone to failure. + debian/patches/tally-unit-test-fails.patch I would, of course, welcome any insight into the test failures. Cheers, -- Steve
Bug#756426: [armhf] iceweasel segfaults when trying to save anything
For info, This has been raised upstream at: https://bugzilla.mozilla.org/show_bug.cgi?id=1050258 Cheers, -- Steve
Bug#756426: [armhf] iceweasel segfaults when trying to save anything
On Tue, 05 Aug 2014 14:24:48 +0100 Marc Zyngier wrote: > An update on this: the armel architecture is *not* affected, and this > seems to be an armhf specific issue (tested by running an armel VM on > the same hardware). > > I'd appreciate if anyone knowledgeable about this could have a look. > Hi Marc, I had the same issue on my Chromebook running Jessie and 3.8.11 Chrome kernel. I did some digging around. >From what I can see we have: NS_IMETHODIMP History::AddDownload(nsIURI* aSource, nsIURI* aReferrer, PRTime aStartTime, nsIURI* aDestination) Argument 0 is the "this" pointer and is 32-bit. Arguments 1, 2 and 4 are 32 bit pointers. Argument 3 (aStartTime) is 64 bit. The function (and gdb) expects arguments 0, 1 and 2 to be in r0, r1, r2 and arguments 3 and 4 to be on the stack. When I stepped through the NS_InvokeByIndex logic: I saw arguments 0, 1, 2 and 4 in registers and only argument 3 to be in the stack. This then caused aDestination to be invalid and hence the crash. I adjusted the logic of "copy_dword" in xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp such that "iregs_args" is set to "end" when we can't fit the 64-bit type in the registers. This appears to have fixed the file download problem for me, but obviously needs more testing! Cheers, -- Steve
