On May 9, 2012, at 12:01 AM, Stefan Farfeleder wrote:
> On Tue, May 08, 2012 at 03:59:42PM -0700, Jason Evans wrote:
>> On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote:
>>> On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote:
On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote:
>>>
On Tue, May 08, 2012 at 03:59:42PM -0700, Jason Evans wrote:
> On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote:
> > On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote:
> >> On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote:
> >>>
> >>> I hit the same assertion with r235052 and inksc
On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote:
> On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote:
>> On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote:
>>> On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote:
On 05/08/12 00:46, Jason Evans wrote:
>
> How re
On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote:
> On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote:
> > On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote:
> >> On 05/08/12 00:46, Jason Evans wrote:
> >>>
> >>> How recent is your system? This problem should have been fixe
On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote:
> On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote:
>> On 05/08/12 00:46, Jason Evans wrote:
>>>
>>> How recent is your system? This problem should have been fixed by
>>> r234569, so if you're still seeing problems after that revisio
On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote:
> On 05/08/12 00:46, Jason Evans wrote:
> >
> > How recent is your system? This problem should have been fixed by
> > r234569, so if you're still seeing problems after that revision,
> > there's another problem we need to figure out. (
On 05/08/12 00:46, Jason Evans wrote:
>
> How recent is your system? This problem should have been fixed by
> r234569, so if you're still seeing problems after that revision,
> there's another problem we need to figure out. (By the way, it's
> possible for an application to trigger this assertio
er, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>>>
>>> root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj && mkdir
>>> obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
>>>
>>> i
/home/david # (cd /var/tmp && rm -fr obj && mkdir
>> obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
>>
>> it ran for a while, then:
>>
>> : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
>&g
Feel free to import this change referencing this explicit gcc-4_1-branch
revision as source and mentioning the GPLv2 license.
--
Martin Matuška
FreeBSD commiter
http://blog.vx.sk
Pedro Giffuni wrote:
On 04/30/12 14:04, Oleksandr Tymoshenko wrote:
> On 29/04/2012 12:04 PM, Adrian Chadd wrote:
>
On 30/04/2012 1:52 PM, Pedro Giffuni wrote:
On 04/30/12 14:04, Oleksandr Tymoshenko wrote:
On 29/04/2012 12:04 PM, Adrian Chadd wrote:
.. and the output from the buildworld:
.. skipped ..
-DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
-Wsystem-headers -Werror -Wall -Wn
On 04/30/12 14:04, Oleksandr Tymoshenko wrote:
On 29/04/2012 12:04 PM, Adrian Chadd wrote:
.. and the output from the buildworld:
.. skipped ..
-DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-
On 29/04/2012 12:04 PM, Adrian Chadd wrote:
.. and the output from the buildworld:
.. skipped ..
-DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc
On Sun, 29 Apr 2012 12:04:05 -0700
Adrian Chadd wrote:
> .. and the output from the buildworld:
>
> cc -fpic -DPIC -O -pipe -G0 -march=mips32
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/include
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../include
> -I/usr/home/adrian/work/fre
.. and the output from the buildworld:
cc -fpic -DPIC -O -pipe -G0 -march=mips32
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/include
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../include
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips -DNLS
-DSOFTFLOAT -D__DBINTERFACE_PRIVATE
Hi Jason,
Cross compiles are now failing for me when I enable MALLOC_PRODUCTION.
I'm doing cross-builds using my environment at
http://code.google.com/p/freebsd-wifi-build/ .
All it requires is a checkout of -HEAD src, so you should be able to
reproduce it by following the instructions for an exa
Hi,
So hm, how do I define MALLOC_PRODUCTION correctly when doing a cross-build?
When doing a cross-build, I do this in my build script:
env CROSS_BUILD_TESTING=YES
MAKEOBJDIRPREFIX=${X_MAKEOBJDIRPREFIX} \
make ${BUILD_FLAGS} TARGET=${TARGET}
TARGET_ARCH=${TARGET_ARCH}
On Sat, 28 Apr 2012 11:29:01 -0700
Jason Evans wrote:
> On Apr 28, 2012, at 5:09 AM, Aleksandr Rybalko wrote:
> >>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>
> But contrib/jemalloc/src/arena.c contains a function,
> arena_chunk_validate_zeroed():
>
> 175
On Apr 28, 2012, at 5:09 AM, Aleksandr Rybalko wrote:
>>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():
175 static inline void
176 arena_chunk_validate_zeroed(arena_chunk_
er, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>> >
>> > root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj &&
>> > mkdir obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf
>> > -)
>&
&& mkdir obj)
> && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf -)
>
> it ran for a while, then:
>
> : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
> Abort (core dumped)
> root@freebeast:/common/home/david # echo $?
&g
it ran for a while, then:
: jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
Abort (core dumped)
root@freebeast:/common/home/david # echo $?
134
root@freebeast:/common/home/david # ls -lTio *.core
ls: No match.
root@freebeast:/common/home/david #
So ... no core file, apparently.
fr
22 matches
Mail list logo
