<jemalloc>: jemalloc_arena.c:182: Failed assertion: "p[i] == 0"

[David Wolfskill]

After applying Dimitry Andric's patches to contrib/jemalloc and replacing
/usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
head as of 234536:

FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797 234536M: Sat Apr 21 10:23:33 PDT 2012     [hidden email]:/usr/obj/usr/src/sys/GENERIC  i386

However, 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 -)

it ran for a while, then:

<jemalloc>: 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.

freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name jemalloc_arena.c
freebeast(10.0-C)[3]

No file named "jemalloc_arena.c", either.

But contrib/jemalloc/src/arena.c contains a function,
arena_chunk_validate_zeroed():

    175 static inline void
    176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
    177 {
    178         size_t i;
    179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind << LG_PAGE));
    180
    181         for (i = 0; i < PAGE / sizeof(size_t); i++)
    182                 assert(p[i] == 0);
    183 }

Thoughts?

Peace,
david
--
David H. Wolfskill [hidden email]
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

[Jason Evans-2]

On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:

> After applying Dimitry Andric's patches to contrib/jemalloc and replacing
> /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
> head as of 234536:
>
> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797 234536M: Sat Apr 21 10:23:33 PDT 2012     [hidden email]:/usr/obj/usr/src/sys/GENERIC  i386
>
> However, 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 -)
>
> it ran for a while, then:
>
> <jemalloc>: 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.
>
> freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name jemalloc_arena.c
> freebeast(10.0-C)[3]
>
> No file named "jemalloc_arena.c", either.
>
> But contrib/jemalloc/src/arena.c contains a function,
> arena_chunk_validate_zeroed():
>
>    175 static inline void
>    176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
>    177 {
>    178         size_t i;
>    179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind << LG_PAGE));
>    180
>    181         for (i = 0; i < PAGE / sizeof(size_t); i++)
>    182                 assert(p[i] == 0);
>    183 }
>
> Thoughts?

I received a similar report yesterday in the context of filezilla, but didn't get as far as reproducing it.  I think the problem is in chunk_alloc_dss(), which dangerously claims that newly allocated memory is zeroed.  It looks like I formalized this bad assumption in early 2010, though the bug existed before that.  It's a bigger deal now because sbrk() is preferred over mmap(), so the bug has languished for a couple of years.  I'll get a fix committed today (and revert the order of preference between sbrk() and mmap()).

By the way, I wonder why not everyone hits this (I don't).

Thanks,
Jason_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Aleksandr Rybalko]

On Sat, 21 Apr 2012 13:11:16 -0700
Jason Evans <[hidden email]> wrote:

>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>> > After applying Dimitry Andric's patches to contrib/jemalloc and
>> > replacing /usr/bin/as with one built last Sunday, I was finally(!)
>> > able to rebuild head as of 234536:
>> >
>> > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT
>> > #797 234536M: Sat Apr 21 10:23:33 PDT 2012
>> > #[hidden email]:/usr/obj/usr/src/sys/GENERIC  i386
>> >
>> > However, 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
>> > -)
>> >
>> > it ran for a while, then:
>> >
>> > <jemalloc>: 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.
>> >
>> > freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>> > jemalloc_arena.c freebeast(10.0-C)[3]
>> >
>> > No file named "jemalloc_arena.c", either.
>> >
>> > But contrib/jemalloc/src/arena.c contains a function,
>> > arena_chunk_validate_zeroed():
>> >
>> >    175 static inline void
>> >    176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t
>> > run_ind) 177 {
>> >    178         size_t i;
>> >    179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk +
>> > (run_ind << LG_PAGE)); 180
>> >    181         for (i = 0; i < PAGE / sizeof(size_t); i++)
>> >    182                 assert(p[i] == 0);
>> >    183 }
>> >
>> > Thoughts?
>>
>> I received a similar report yesterday in the context of filezilla,
>> but didn't get as far as reproducing it.  I think the problem is in
>> chunk_alloc_dss(), which dangerously claims that newly allocated
>> memory is zeroed.  It looks like I formalized this bad assumption in
>> early 2010, though the bug existed before that.  It's a bigger deal
>> now because sbrk() is preferred over mmap(), so the bug has
>> languished for a couple of years.  I'll get a fix committed today
>> (and revert the order of preference between sbrk() and mmap()).
>>
>> By the way, I wonder why not everyone hits this (I don't).
>>
>> Thanks,
>> Jason_______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "[hidden email]"

Hi,

maybe it somehow related to low count of free memory, because I see
that very frequently on my box. (Atheros AR7242 mips32be with 32M of
RAM)

After "#ifdef" of that function body, box behave good (seems) :)

WBW
--
Alexandr Rybalko <[hidden email]>
aka Alex RAY <[hidden email]>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Jason Evans-2]

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_t *chunk, size_t
>>>> run_ind) 177 {
>>>>   178         size_t i;
>>>>   179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk +
>>>> (run_ind << LG_PAGE)); 180
>>>>   181         for (i = 0; i < PAGE / sizeof(size_t); i++)
>>>>   182                 assert(p[i] == 0);
>>>>   183 }
>
> maybe it somehow related to low count of free memory, because I see
> that very frequently on my box. (Atheros AR7242 mips32be with 32M of
> RAM)
>
> After "#ifdef" of that function body, box behave good (seems) :)

Yes, arena_chunk_validate_zeroed() (which is debug-only code) has the side effect of faulting in untouched pages, so it potentially increases physical memory usage.  In practice, this sanity checking has saved jemalloc from regressions that would otherwise manifest as mysterious application memory corruption (and would have prevented even more regressions, had it existed earlier).  You can disable it and many other performance-sacrificing debug features by defining MALLOC_PRODUCTION in /etc/make.conf.

Jason_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Aleksandr Rybalko]

On Sat, 28 Apr 2012 11:29:01 -0700
Jason Evans <[hidden email]> 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 static inline void
> >>>>   176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t
> >>>> run_ind) 177 {
> >>>>   178         size_t i;
> >>>>   179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk +
> >>>> (run_ind << LG_PAGE)); 180
> >>>>   181         for (i = 0; i < PAGE / sizeof(size_t); i++)
> >>>>   182                 assert(p[i] == 0);
> >>>>   183 }
> >
> > maybe it somehow related to low count of free memory, because I see
> > that very frequently on my box. (Atheros AR7242 mips32be with 32M of
> > RAM)
> >
> > After "#ifdef" of that function body, box behave good (seems) :)
>
> Yes, arena_chunk_validate_zeroed() (which is debug-only code) has the
> side effect of faulting in untouched pages, so it potentially
> increases physical memory usage.  In practice, this sanity checking
> has saved jemalloc from regressions that would otherwise manifest as
> mysterious application memory corruption (and would have prevented
> even more regressions, had it existed earlier).  You can disable it
> and many other performance-sacrificing debug features by defining
> MALLOC_PRODUCTION in /etc/make.conf.

Yeah, found it. Thank you.

It is possible to hide such debug code under debug macro, so embedded
guys will be more happy about sizes? :)

Thank you for that big job!

>
> Jason_______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "[hidden email]"


--
Aleksandr Rybalko <[hidden email]>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Adrian Chadd-2]

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}     \
            ${X_TARGET_CPUTYPE} KERNCONF=${KERNCONF}
DESTDIR=${X_DESTDIR}       \
            KODIR=/boot/kernel.${KERNCONF}/
         \
            KMODDIR=/boot/kernel.${KERNCONF}/
         \
            __MAKE_CONF=/dev/null SRCCONF=/dev/null
         \
            LOCAL_DIRS="${LOCAL_DIRS}"
         \
            LOCAL_TOOL_DIRS="${LOCAL_TOOL_DIRS}" $1
         \

.. so I'd have to put MALLOC_PRODUCTION=yes in a temporary make.conf,
and point __MAKE_CONF at that?



Adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Adrian Chadd-2]

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 example device:

http://code.google.com/p/freebsd-wifi-build/wiki/TpLinkTLWR1043ND

You'll have to patch build_freebsd in that SVN repo to populate
make.conf with 'MALLOC_PRODUCTION=', rather than pointing it to
/dev/null.

Please note that for cross builds to MIPS, the compiler being used is
GCC and not LLVM.

Thanks,


Adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Adrian Chadd-2]

.. 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
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/gdtoa
-DINET6 -I/usr/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/lib/libc
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/resolv -D_ACL_PRIVATE
-DPOSIX_MISTAKE
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/jemalloc/include
-DMALLOC_PRODUCTION
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/tzcode/stdtime
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdtime
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/locale -DBROKEN_DES
-DPORTMAP -DDES_BUILTIN
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/rpc
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips/softfloat
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/softfloat
-DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c
/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdlib/twalk.c -o
twalk.So
cc  -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
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/gdtoa
-DINET6 -I/usr/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/lib/libc
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/resolv -D_ACL_PRIVATE
-DPOSIX_MISTAKE
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/jemalloc/include
-DMALLOC_PRODUCTION
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/tzcode/stdtime
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdtime
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/locale -DBROKEN_DES
-DPORTMAP -DDES_BUILTIN
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/rpc
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips/softfloat
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/softfloat
-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.o
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
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/gdtoa
-DINET6 -I/usr/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/lib/libc
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/resolv -D_ACL_PRIVATE
-DPOSIX_MISTAKE
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/jemalloc/include
-DMALLOC_PRODUCTION
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/tzcode/stdtime
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdtime
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/locale -DBROKEN_DES
-DPORTMAP -DDES_BUILTIN
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/rpc
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips/softfloat
-I/usr/home/adrian/work/freebsd/svn/src/lib/libc/softfloat
-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.So
jemalloc_jemalloc.c: In function 'calloc':
jemalloc_jemalloc.c:1027: internal compiler error: in
change_address_1, at emit-rtl.c:1784
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error


and the diff against build_freebsd:


Index: build_freebsd
===================================================================
--- build_freebsd       (revision 165)
+++ build_freebsd       (working copy)
@@ -45,6 +45,9 @@
     X_TARGET_CPUTYPE="TARGET_CPUTYPE=${TARGET_CPUTYPE}"
 fi

+# Create a make.conf
+echo "MALLOC_PRODUCTION=" > ${X_DESTDIR}/../make.conf.${BUILDNAME}
+
 while [ "x$1" != "x" ]; do
        if [ "$1" = "installworld" ]; then
                mkdir -p ${X_DESTDIR}/usr/local/bin/
@@ -63,7 +66,8 @@
            ${X_TARGET_CPUTYPE} KERNCONF=${KERNCONF}
DESTDIR=${X_DESTDIR}       \
            KODIR=/boot/kernel.${KERNCONF}/
         \
            KMODDIR=/boot/kernel.${KERNCONF}/
         \
-           __MAKE_CONF=/dev/null SRCCONF=/dev/null
         \
+           __MAKE_CONF=${X_DESTDIR}/../make.conf.${BUILDNAME}
         \
+           SRCCONF=/dev/null
         \
            LOCAL_DIRS="${LOCAL_DIRS}"
         \
            LOCAL_TOOL_DIRS="${LOCAL_TOOL_DIRS}" $1
         \
        || exit 1
@@ -74,3 +78,6 @@
        fi
        shift
 done
+
+#          __MAKE_CONF=/dev/null
         \
+#          SRCCONF=${X_DESTDIR}/../src.conf.${BUILDNAME}
         \



adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Aleksandr Rybalko]

On Sun, 29 Apr 2012 12:04:05 -0700
Adrian Chadd <[hidden email]> 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/freebsd/svn/src/lib/libc/mips -DNLS
> -DSOFTFLOAT -D__DBINTERFACE_PRIVATE
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/gdtoa
> -DINET6
> -I/usr/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/lib/libc
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/resolv
> -D_ACL_PRIVATE -DPOSIX_MISTAKE
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/jemalloc/include
> -DMALLOC_PRODUCTION
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/tzcode/stdtime
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdtime
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/locale -DBROKEN_DES
> -DPORTMAP -DDES_BUILTIN
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/rpc
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips/softfloat
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/softfloat
> -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign
> -c /usr/home/adrian/work/freebsd/svn/src/lib/libc/stdlib/twalk.c -o
> twalk.So cc  -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
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/gdtoa
> -DINET6
> -I/usr/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/lib/libc
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/resolv
> -D_ACL_PRIVATE -DPOSIX_MISTAKE
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/jemalloc/include
> -DMALLOC_PRODUCTION
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/tzcode/stdtime
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdtime
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/locale -DBROKEN_DES
> -DPORTMAP -DDES_BUILTIN
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/rpc
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips/softfloat
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/softfloat
> -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.o 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
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/gdtoa
> -DINET6
> -I/usr/home/adrian/work/freebsd/svn/obj/mipseb/mips.mips/usr/home/adrian/work/freebsd/svn/src/lib/libc
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/resolv
> -D_ACL_PRIVATE -DPOSIX_MISTAKE
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/jemalloc/include
> -DMALLOC_PRODUCTION
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/../../contrib/tzcode/stdtime
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/stdtime
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/locale -DBROKEN_DES
> -DPORTMAP -DDES_BUILTIN
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/rpc
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/mips/softfloat
> -I/usr/home/adrian/work/freebsd/svn/src/lib/libc/softfloat
> -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.So
> jemalloc_jemalloc.c: In function 'calloc': jemalloc_jemalloc.c:1027:
> internal compiler error: in change_address_1, at emit-rtl.c:1784
> Please submit a full bug report, with preprocessed source if
> appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
>
>
> and the diff against build_freebsd:
>
>
> Index: build_freebsd
> ===================================================================
> --- build_freebsd       (revision 165)
> +++ build_freebsd       (working copy)
> @@ -45,6 +45,9 @@
>      X_TARGET_CPUTYPE="TARGET_CPUTYPE=${TARGET_CPUTYPE}"
>  fi
>
> +# Create a make.conf
> +echo "MALLOC_PRODUCTION=" > ${X_DESTDIR}/../make.conf.${BUILDNAME}
> +
>  while [ "x$1" != "x" ]; do
>         if [ "$1" = "installworld" ]; then
>                 mkdir -p ${X_DESTDIR}/usr/local/bin/
> @@ -63,7 +66,8 @@
>             ${X_TARGET_CPUTYPE} KERNCONF=${KERNCONF}
> DESTDIR=${X_DESTDIR}       \
>             KODIR=/boot/kernel.${KERNCONF}/
>          \
>             KMODDIR=/boot/kernel.${KERNCONF}/
>          \
> -           __MAKE_CONF=/dev/null SRCCONF=/dev/null
>          \
> +           __MAKE_CONF=${X_DESTDIR}/../make.conf.${BUILDNAME}
>          \
> +           SRCCONF=/dev/null
>          \
>             LOCAL_DIRS="${LOCAL_DIRS}"
>          \
>             LOCAL_TOOL_DIRS="${LOCAL_TOOL_DIRS}" $1
>          \
>         || exit 1
> @@ -74,3 +78,6 @@
>         fi
>         shift
>  done
> +
> +#          __MAKE_CONF=/dev/null
>          \
> +#          SRCCONF=${X_DESTDIR}/../src.conf.${BUILDNAME}
>          \
>
>
>
> adrian

Hi,

confirm, same for zrouter builds, at least for MIPS32EB and MIPS32EL.
In short, MALLOC_PRODUCTION flag for MIPS32EL used this way:
make \
        TARGET=mips \
        TARGET_ARCH=mipsel \
        TARGET_CPUARCH=mips \
        ... \
        MALLOC_PRODUCTION=yes toolchain
make \
        TARGET=mips \
        TARGET_ARCH=mipsel \
        TARGET_CPUARCH=mips \
        ... \
        MALLOC_PRODUCTION=yes buildworld

Just s/mipsel/mips/ for MIPS32EB.

WBW
--
Aleksandr Rybalko <[hidden email]>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Oleksandr Tymoshenko-2]

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.So
> jemalloc_jemalloc.c: In function 'calloc':
> jemalloc_jemalloc.c:1027: internal compiler error: in
> change_address_1, at emit-rtl.c:1784
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See<URL:http://gcc.gnu.org/bugs.html>  for instructions.
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error

This ICE was fixed here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
Unfortunately the fix is GPLv3-licensed, so we can't merge it
back as-is.

I tracked down the cause of the issue to
contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h line 214.
So possible workaround could be replacing this line to
#if defined(JEMALLOC_DEBUG) || defined(__mips__)

Ugly, yes, but good enough as a band-aid until we figure out what to do
with the real issue
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Pedro Giffuni-4]

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-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So
>> jemalloc_jemalloc.c: In function 'calloc':
>> jemalloc_jemalloc.c:1027: internal compiler error: in
>> change_address_1, at emit-rtl.c:1784
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See<URL:http://gcc.gnu.org/bugs.html>  for instructions.
>> *** Error code 1
>> 1 error
>> *** Error code 2
>> 1 error
>> *** Error code 2
>> 1 error
>> *** Error code 2
>> 1 error
>> *** Error code 2
>> 1 error
>
> This ICE was fixed here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
> Unfortunately the fix is GPLv3-licensed, so we can't merge it
> back as-is.
>

Actually.. the fix was merged to the gcc 4.1 branch
so we can take it under GPLv2:

http://gcc.gnu.org/viewcvs?view=revision&revision=128198

best regards,

Pedro.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Oleksandr Tymoshenko-2]

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 -Wno-format-y2k -Wno-uninitialized
>>> -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So
>>> jemalloc_jemalloc.c: In function 'calloc':
>>> jemalloc_jemalloc.c:1027: internal compiler error: in
>>> change_address_1, at emit-rtl.c:1784
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See<URL:http://gcc.gnu.org/bugs.html> for instructions.
>>> *** Error code 1
>>> 1 error
>>> *** Error code 2
>>> 1 error
>>> *** Error code 2
>>> 1 error
>>> *** Error code 2
>>> 1 error
>>> *** Error code 2
>>> 1 error
>>
>> This ICE was fixed here:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
>> Unfortunately the fix is GPLv3-licensed, so we can't merge it
>> back as-is.
>>
>
> Actually.. the fix was merged to the gcc 4.1 branch
> so we can take it under GPLv2:
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=128198

Thanks, Pedro! It's GPLv2 indeed. I missed it yesterday.
Will commit.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[mm]

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 <[hidden email]> 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 -Wno-format-y2k -Wno-uninitialized
>> -Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So
>> jemalloc_jemalloc.c: In function 'calloc':
>> jemalloc_jemalloc.c:1027: internal compiler error: in
>> change_address_1, at emit-rtl.c:1784
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See<URL:http://gcc.gnu.org/bugs.html>; for instructions.
>> *** Error code 1
>> 1 error
>> *** Error code 2
>> 1 error
>> *** Error code 2
>> 1 error
>> *** Error code 2
>> 1 error
>> *** Error code 2
>> 1 error
>
> This ICE was fixed here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
> Unfortunately the fix is GPLv3-licensed, so we can't merge it
> back as-is.
>

Actually.. the fix was merged to the gcc 4.1 branch
so we can take it under GPLv2:

http://gcc.gnu.org/viewcvs?view=revision&revision=128198

best regards,

Pedro.
_____________________________________________

[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[swills]

> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>> After applying Dimitry Andric's patches to contrib/jemalloc and
>> replacing
>> /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
>> head as of 234536:
>>
>> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
>> 234536M: Sat Apr 21 10:23:33 PDT 2012
>> [hidden email]:/usr/obj/usr/src/sys/GENERIC  i386
>>
>> However, 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 -)
>>
>> it ran for a while, then:
>>
>> <jemalloc>: 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.
>>
>> freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>> jemalloc_arena.c
>> freebeast(10.0-C)[3]
>>
>> No file named "jemalloc_arena.c", either.
>>
>> But contrib/jemalloc/src/arena.c contains a function,
>> arena_chunk_validate_zeroed():
>>
>>    175 static inline void
>>    176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
>>    177 {
>>    178         size_t i;
>>    179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
>> << LG_PAGE));
>>    180
>>    181         for (i = 0; i < PAGE / sizeof(size_t); i++)
>>    182                 assert(p[i] == 0);
>>    183 }
>>
>> Thoughts?
>
> I received a similar report yesterday in the context of filezilla, but
> didn't get as far as reproducing it.  I think the problem is in
> chunk_alloc_dss(), which dangerously claims that newly allocated memory is
> zeroed.  It looks like I formalized this bad assumption in early 2010,
> though the bug existed before that.  It's a bigger deal now because sbrk()
> is preferred over mmap(), so the bug has languished for a couple of years.
>  I'll get a fix committed today (and revert the order of preference
> between sbrk() and mmap()).
>
> By the way, I wonder why not everyone hits this (I don't).
>

I just now hit the same issue while using ports tinderbox. It was calling
tar during the "makeJail" tinderbox subcommand and gave the same error as
in the subject. Funny thing is I had run the same command (on a different
"jail") right before this and didn't get the error. What's the status of
this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
and forget about it?

Steve


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Jason Evans-2]

On May 7, 2012, at 12:19 PM, Steve Wills wrote:

>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>>> After applying Dimitry Andric's patches to contrib/jemalloc and
>>> replacing
>>> /usr/bin/as with one built last Sunday, I was finally(!) able to rebuild
>>> head as of 234536:
>>>
>>> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #797
>>> 234536M: Sat Apr 21 10:23:33 PDT 2012
>>> [hidden email]:/usr/obj/usr/src/sys/GENERIC  i386
>>>
>>> However, 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 -)
>>>
>>> it ran for a while, then:
>>>
>>> <jemalloc>: 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.
>>>
>>> freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>>> jemalloc_arena.c
>>> freebeast(10.0-C)[3]
>>>
>>> No file named "jemalloc_arena.c", either.
>>>
>>> But contrib/jemalloc/src/arena.c contains a function,
>>> arena_chunk_validate_zeroed():
>>>
>>>   175 static inline void
>>>   176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t run_ind)
>>>   177 {
>>>   178         size_t i;
>>>   179         UNUSED size_t *p = (size_t *)((uintptr_t)chunk + (run_ind
>>> << LG_PAGE));
>>>   180
>>>   181         for (i = 0; i < PAGE / sizeof(size_t); i++)
>>>   182                 assert(p[i] == 0);
>>>   183 }
>>>
>>> Thoughts?
>>
>> I received a similar report yesterday in the context of filezilla, but
>> didn't get as far as reproducing it.  I think the problem is in
>> chunk_alloc_dss(), which dangerously claims that newly allocated memory is
>> zeroed.  It looks like I formalized this bad assumption in early 2010,
>> though the bug existed before that.  It's a bigger deal now because sbrk()
>> is preferred over mmap(), so the bug has languished for a couple of years.
>> I'll get a fix committed today (and revert the order of preference
>> between sbrk() and mmap()).
>>
>> By the way, I wonder why not everyone hits this (I don't).
>
> I just now hit the same issue while using ports tinderbox. It was calling
> tar during the "makeJail" tinderbox subcommand and gave the same error as
> in the subject. Funny thing is I had run the same command (on a different
> "jail") right before this and didn't get the error. What's the status of
> this? Should I set MALLOC_PRODUCTION=yes in /etc/make.conf, rebuild world
> and forget about it?

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 assertion, but unlikely.)

Thanks,
Jason_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[swills]

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 assertion, but
> unlikely.)
>

My system is r235115.

Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Stefan Farfeleder]

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.  (By the way, it's
> > possible for an application to trigger this assertion, but
> > unlikely.)
> >
>
> My system is r235115.

I hit the same assertion with r235052 and inkscape. I'm now using
MALLOC_PRODUCTION and it works again.

Stefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Jason Evans-2]

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 revision,
>>> there's another problem we need to figure out.  (By the way, it's
>>> possible for an application to trigger this assertion, but
>>> unlikely.)
>>>
>>
>> My system is r235115.
>
> I hit the same assertion with r235052 and inkscape. I'm now using
> MALLOC_PRODUCTION and it works again.

Was the assertion failure easily reproducible with inkscape?

Thanks,
Jason
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Stefan Farfeleder]

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 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 assertion, but
> >>> unlikely.)
> >>>
> >>
> >> My system is r235115.
> >
> > I hit the same assertion with r235052 and inkscape. I'm now using
> > MALLOC_PRODUCTION and it works again.
>
> Was the assertion failure easily reproducible with inkscape?

Yes, it crashed everytime before showing the GUI. The backtrace goes
like this:

(gdb) bt
#0  0x000000080ad760ac in thr_kill () from /lib/libc.so.7
#1  0x000000080ae22548 in abort () from /lib/libc.so.7
#2  0x000000080ad9f57d in sbrk () from /lib/libc.so.7
#3  0x000000080ada1c51 in sbrk () from /lib/libc.so.7
#4  0x000000080ada3624 in sbrk () from /lib/libc.so.7
#5  0x000000080ada3ffc in sbrk () from /lib/libc.so.7
#6  0x000000080ada432d in sbrk () from /lib/libc.so.7
#7  0x000000080ad9394f in syscall () from /lib/libc.so.7
#8  0x000000080ad93d70 in syscall () from /lib/libc.so.7
#9  0x000000080ada73a0 in malloc () from /lib/libc.so.7
#10 0x000000080a6a283d in operator new () from /usr/lib/libstdc++.so.6
#11 0x00000000007af660 in sigc::internal::typed_slot_rep<sigc::bind_functor<-1, sigc::pointer_functor3<SPObject*, SPObject*, SPStyle*, void>, SPStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> >::dup ()
#12 0x00000008033016b4 in sigc::slot_base::slot_base ()
   from /usr/local/lib/libsigc-2.0.so.0
#13 0x00000000006f0a77 in std::list<sigc::slot_base, std::allocator<sigc::slot_base> >::insert ()
#14 0x000000080330084a in sigc::internal::signal_impl::insert ()
   from /usr/local/lib/libsigc-2.0.so.0
#15 0x0000000803300893 in sigc::internal::signal_impl::connect ()
   from /usr/local/lib/libsigc-2.0.so.0
#16 0x0000000803300a44 in sigc::signal_base::connect ()
#17 0x00000000007a8635 in SPIPaint::read ()
[...]

Stefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"

[Jason Evans-2]

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 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 assertion, but
>>>>> unlikely.)
>>>>>
>>>>
>>>> My system is r235115.
>>>
>>> I hit the same assertion with r235052 and inkscape. I'm now using
>>> MALLOC_PRODUCTION and it works again.
>>
>> Was the assertion failure easily reproducible with inkscape?
>
> Yes, it crashed everytime before showing the GUI. The backtrace goes
> like this:
>
> (gdb) bt
> #0  0x000000080ad760ac in thr_kill () from /lib/libc.so.7
> #1  0x000000080ae22548 in abort () from /lib/libc.so.7
> #2  0x000000080ad9f57d in sbrk () from /lib/libc.so.7
> #3  0x000000080ada1c51 in sbrk () from /lib/libc.so.7
> #4  0x000000080ada3624 in sbrk () from /lib/libc.so.7
> #5  0x000000080ada3ffc in sbrk () from /lib/libc.so.7
> #6  0x000000080ada432d in sbrk () from /lib/libc.so.7
> #7  0x000000080ad9394f in syscall () from /lib/libc.so.7
> #8  0x000000080ad93d70 in syscall () from /lib/libc.so.7
> #9  0x000000080ada73a0 in malloc () from /lib/libc.so.7
> #10 0x000000080a6a283d in operator new () from /usr/lib/libstdc++.so.6
> #11 0x00000000007af660 in sigc::internal::typed_slot_rep<sigc::bind_functor<-1, sigc::pointer_functor3<SPObject*, SPObject*, SPStyle*, void>, SPStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> >::dup ()
> #12 0x00000008033016b4 in sigc::slot_base::slot_base ()
>   from /usr/local/lib/libsigc-2.0.so.0
> #13 0x00000000006f0a77 in std::list<sigc::slot_base, std::allocator<sigc::slot_base> >::insert ()
> #14 0x000000080330084a in sigc::internal::signal_impl::insert ()
>   from /usr/local/lib/libsigc-2.0.so.0
> #15 0x0000000803300893 in sigc::internal::signal_impl::connect ()
>   from /usr/local/lib/libsigc-2.0.so.0
> #16 0x0000000803300a44 in sigc::signal_base::connect ()
> #17 0x00000000007a8635 in SPIPaint::read ()
> […]

sbrk() is being used rather than mmap().  Unless mmap() is failing (which would surprise me), this indicates that you are using a version of libc that's old enough to have the bug I fixed in r234569.

Thanks,
Jason_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"