Bug#843926: jemalloc hard codes page size during build
On Tue, Nov 07, 2017 at 05:07:42PM +, James Cowgill wrote: > Ah nevermind - I see it FTBFS in experimental on lots of arches. Yeah, I've fixed some in git already and been working with upstream on a lot of those (upstream #761, #979, #985, #999). They've been extremely collaborative (and even trying to make sure breakages on non-x86 won't happen again, #1044). I'm currently waiting for either a backport of one of the fixes or a release, the latter being blocked on them figuring out their release strategy (#1049). Regards, Faidon
Bug#843926: jemalloc hard codes page size during build
On 07/11/17 17:02, James Cowgill wrote: > Hi, > > Is there a plan to start a transition to get this version of jemalloc in > unstable? I don't see a transition bug against release.d.o. Is there > anything blocking it? Ah nevermind - I see it FTBFS in experimental on lots of arches. James signature.asc Description: OpenPGP digital signature
Bug#843926: jemalloc hard codes page size during build
Hi, Is there a plan to start a transition to get this version of jemalloc in unstable? I don't see a transition bug against release.d.o. Is there anything blocking it? Thanks, James signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#843926: jemalloc hard codes page size during build
Processing commands for cont...@bugs.debian.org: > tags 843926 fixed-upstream Bug #843926 [libjemalloc1] jemalloc uses a hard coded page size detected during build Added tag(s) fixed-upstream. > forwarded 843926 https://github.com/jemalloc/jemalloc/issues/467 Bug #843926 [libjemalloc1] jemalloc uses a hard coded page size detected during build Set Bug forwarded-to-address to 'https://github.com/jemalloc/jemalloc/issues/467'. > tags 832931 - fixed-upstream Bug #832931 [src:mariadb-10.0] mariadb-10.0: FTBFS on powerpc Removed tag(s) fixed-upstream. > forwarded 832931 https://jira.mariadb.org/browse/MDEV-11877 Bug #832931 [src:mariadb-10.0] mariadb-10.0: FTBFS on powerpc Changed Bug forwarded-to-address to 'https://jira.mariadb.org/browse/MDEV-11877' from 'https://github.com/jemalloc/jemalloc/issues/467'. > thanks Stopping processing here. Please contact me if you need assistance. -- 832931: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 843926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843926 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832931: Bug#843926: jemalloc hard codes page size during build
tags 843926 fixed-upstream forwarded 843926 https://github.com/jemalloc/jemalloc/issues/467 tags 832931 - fixed-upstream forwarded 832931 https://jira.mariadb.org/browse/MDEV-11877 thanks Sorry, sent to the wrong bug number. On 07/06/17 15:15, James Cowgill wrote: > Control: forwarded -1 https://github.com/jemalloc/jemalloc/issues/467 > Control: tags -1 fixed-upstream > > On 10/11/16 18:37, Thadeu Lima de Souza Cascardo wrote: >> clone -1 -2 >> reassign -2 libjemalloc1 >> retitle -2 jemalloc uses a hard coded page size detected during build >> bye >> >> >> So, I traced this to jemalloc using the incorrect page size during >> runtime. In fact, it detects the page size during build and set it up. >> This has a large potential for a mess. And what a mess! >> >> So, jemalloc in jessie has been built on a 4KiB-page system, and, this, >> has a hard-coded page size of 4KiB. While jemalloc in sid has a >> 64KiB-page size. When we try to build mariadb on jessie on a 4KiB-page >> size system, everything goes well. When we build it on partch, with a >> 64-bit 64KiB-page size kernel, things break, if it's a jessie jemalloc. >> >> Later upstream versions seem to support multiple page sizes during >> build. > > It looks like jemalloc 5.0.0 will support multiple page sizes > automatically as long as you pass the biggest possible page size when > you configure it: > https://github.com/jemalloc/jemalloc/pull/769 > > That patch is pretty big though, so it won't help with stretch. > >> For MariaDB specifically, one option would be to build it without >> jemalloc. Other users would still be likely affected, however. > > Limiting it to specific architectures is probably ok though. > > Thanks, > James signature.asc Description: OpenPGP digital signature
Processed: Bug#843926: jemalloc hard codes page size during build
Processing control commands: > forwarded -1 https://github.com/jemalloc/jemalloc/issues/467 Bug #832931 [src:mariadb-10.0] mariadb-10.0: FTBFS on powerpc Changed Bug forwarded-to-address to 'https://github.com/jemalloc/jemalloc/issues/467' from 'https://jira.mariadb.org/browse/MDEV-11877'. > tags -1 fixed-upstream Bug #832931 [src:mariadb-10.0] mariadb-10.0: FTBFS on powerpc Added tag(s) fixed-upstream. -- 832931: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832931: Bug#843926: jemalloc hard codes page size during build
Control: forwarded -1 https://github.com/jemalloc/jemalloc/issues/467 Control: tags -1 fixed-upstream On 10/11/16 18:37, Thadeu Lima de Souza Cascardo wrote: > clone -1 -2 > reassign -2 libjemalloc1 > retitle -2 jemalloc uses a hard coded page size detected during build > bye > > > So, I traced this to jemalloc using the incorrect page size during > runtime. In fact, it detects the page size during build and set it up. > This has a large potential for a mess. And what a mess! > > So, jemalloc in jessie has been built on a 4KiB-page system, and, this, > has a hard-coded page size of 4KiB. While jemalloc in sid has a > 64KiB-page size. When we try to build mariadb on jessie on a 4KiB-page > size system, everything goes well. When we build it on partch, with a > 64-bit 64KiB-page size kernel, things break, if it's a jessie jemalloc. > > Later upstream versions seem to support multiple page sizes during > build. It looks like jemalloc 5.0.0 will support multiple page sizes automatically as long as you pass the biggest possible page size when you configure it: https://github.com/jemalloc/jemalloc/pull/769 That patch is pretty big though, so it won't help with stretch. > For MariaDB specifically, one option would be to build it without > jemalloc. Other users would still be likely affected, however. Limiting it to specific architectures is probably ok though. Thanks, James signature.asc Description: OpenPGP digital signature
