Re: malloc() call somehow calling the rtld malloc() implementaion

[Don Lewis]

On 28 Jan, Jan Mikkelsen wrote:
> Hi,
> 
> Are you being affected by this rtld behaviour:
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/2016-July/049769.html 
> 
> 
> https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082751.html 
> 
> 
> (I still find this a bit scary.)

That's not rtld, it's the kernel linker.  Yes, I have also encountered
that, though in my case the effect was that it hid the fact that the
target symbol was not exported.  There was a linking failure on i386,
which the amd64-only testing did not uncover.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: malloc() call somehow calling the rtld malloc() implementaion

[Don Lewis]

On 27 Jan, Konstantin Belousov wrote:
> On Fri, Jan 27, 2017 at 12:19:16PM -0500, Alexander Kabaev wrote:
>> On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
>> Don Lewis  wrote:
>> 
>> > I've been attempting to get OpenOffice to build properly in a
>> > clang400-import poudriere jail and have run into a mystery.  The build
>> > procedure creates a c++ executable "idlc", which is used to build
>> > other stuff.  The new operator has been overrriden to call a custom
>> > memory allocator, which I have configured to call the system version
>> > of malloc().
>> > 
>> > At some point idlc crashes because it has allocated a 16 byte
>> > structure and the compiler is using "movaps %xmm0,(%rax)" to
>> > initialize it, which requires 16 byte alignment.  Unfortunately this
>> > structure is only 8 byte aligned, causing a bus error.  This
>> > shouldn't be happening because our system malloc() always seems to do
>> > the proper alignment.  It appears that intead of calling the version
>> > of malloc() in libc, the simple version of malloc() built into rtld
>> > is being called instead.
>> > 
>> > GNU gdb 6.1.1 [FreeBSD]
>> > Copyright 2004 Free Software Foundation, Inc.
>> > GDB is free software, covered by the GNU General Public License, and
>> > you are welcome to change it and/or distribute copies of it under
>> > certain conditions. Type "show copying" to see the conditions.
>> > There is absolutely no warranty for GDB.  Type "show warranty" for
>> > details. This GDB was configured as "amd64-marcel-freebsd"...
>> > (gdb) break main
>> > Breakpoint 1 at 0x43b1f6: file idlcmain.cxx, line 34.
>> > (gdb) run @/tmp/r
>> > Starting
>> > program: 
>> > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc
>> > @/tmp/r [New LWP 101304] [New Thread 802616000 (LWP 101304/idlc)]
>> > [Switching to Thread 802616000 (LWP 101304/idlc)]
>> > 
>> > Breakpoint 1, main (argc=2, argv=0x7fffb278) at idlcmain.cxx:34
>> > 34 SAL_IMPLEMENT_MAIN_WITH_ARGS(argc, argv)
>> > (gdb) break malloc
>> > Breakpoint 2 at 0x8006a5f01:
>> > file /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c,
>> > line 163. (gdb) cont Continuing.
>> > Trace 12474/1: "Min Prioriy for policy '2' == '0'
>> > "
>> > Trace 12474/1: "Max Prioriy for policy '2' == '103'
>> > "
>> > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
>> > compiling 1 source files ...
>> > Compiling: 
>> > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/offapi/com/sun/star/i18n/KParseTokens.idl
>> > 
>> > Breakpoint 2, malloc (nbytes=343)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:
>> > No such file or directory.
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > Current language:  auto; currently minimal (gdb) cont
>> > Continuing.
>> > 
>> > Breakpoint 2, malloc (nbytes=32)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> > Trace 13112/2: "ChildStatusProc : starting
>> > '/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/ucpp'"
>> >  [New
>> > Thread 802616500 (LWP 100249/idlc)] [Switching to Thread 802616500
>> > (LWP 100249/idlc)]
>> > 
>> > Breakpoint 2, malloc (nbytes=19)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> > 
>> > Breakpoint 2, malloc (nbytes=34)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> > 
>> > Breakpoint 2, malloc (nbytes=16)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> > 
>> > Breakpoint 2, malloc (nbytes=16)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> > 
>> > Breakpoint 2, malloc (nbytes=16)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> > 
>> > Breakpoint 2, malloc (nbytes=16)
>> > at 
>> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
>> > 163
>> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
>> > (gdb) cont Continuing.
>> >

Re: malloc() call somehow calling the rtld malloc() implementaion

[Jan Mikkelsen]

Hi,

Are you being affected by this rtld behaviour:

https://lists.freebsd.org/pipermail/freebsd-hackers/2016-July/049769.html 


https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082751.html 


(I still find this a bit scary.)

Regards,

Jan.


> On 27 Jan 2017, at 19:31, Don Lewis  wrote:
> 
> I've been attempting to get OpenOffice to build properly in a
> clang400-import poudriere jail and have run into a mystery.  The build
> procedure creates a c++ executable "idlc", which is used to build other
> stuff.  The new operator has been overrriden to call a custom memory
> allocator, which I have configured to call the system version of
> malloc().
> 
> At some point idlc crashes because it has allocated a 16 byte structure
> and the compiler is using "movaps %xmm0,(%rax)" to initialize it, which
> requires 16 byte alignment.  Unfortunately this structure is only 8 byte
> aligned, causing a bus error.  This shouldn't be happening because our
> system malloc() always seems to do the proper alignment.  It appears
> that intead of calling the version of malloc() in libc, the simple
> version of malloc() built into rtld is being called instead.
> 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> (gdb) break main
> Breakpoint 1 at 0x43b1f6: file idlcmain.cxx, line 34.
> (gdb) run @/tmp/r
> Starting program: 
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc
>  @/tmp/r
> [New LWP 101304]
> [New Thread 802616000 (LWP 101304/idlc)]
> [Switching to Thread 802616000 (LWP 101304/idlc)]
> 
> Breakpoint 1, main (argc=2, argv=0x7fffb278) at idlcmain.cxx:34
> 34SAL_IMPLEMENT_MAIN_WITH_ARGS(argc, argv)
> (gdb) break malloc
> Breakpoint 2 at 0x8006a5f01: file 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c, line 
> 163.
> (gdb) cont
> Continuing.
> Trace 12474/1: "Min Prioriy for policy '2' == '0'
> "
> Trace 12474/1: "Max Prioriy for policy '2' == '103'
> "
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
>  compiling 1 source files ... 
> Compiling: 
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/offapi/com/sun/star/i18n/KParseTokens.idl
> 
> Breakpoint 2, malloc (nbytes=343)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c: 
> No such file or directory.
>   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> Current language:  auto; currently minimal
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=32)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> Trace 13112/2: "ChildStatusProc : starting 
> '/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/ucpp'"
> [New Thread 802616500 (LWP 100249/idlc)]
> [Switching to Thread 802616500 (LWP 100249/idlc)]
> 
> Breakpoint 2, malloc (nbytes=19)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=34)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
>at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont
> Continuing.
> sizeof(AstExprValue)=16
> 
> Program received signal SIGBUS

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 22:16, Ngie Cooper  wrote:
> 
> 
>> On Jan 27, 2017, at 09:05, Warner Losh  wrote:
> 
> ...
> 
>> I'm curious why you can't find the space for a bigger partition?
>> Almost all drives these days are partitioned with a little wasted
>> space, and that wasted space should be more than enough to cover us
>> here. Also, most drives have a swap partition that can be shrunk a
>> trivial amount to get space for this...
> 
> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
> the swap partition.
> 
> We have a similar problem at work with sys/boot unfortunately, but that's a 
> side discussion for another time/place.
> 
> Thank you for the idea though -- I'll check when I get back to work.
> 
> -Ngie

Note the order of the partitions is not important, at least on paper anyhow. Of 
course there are preferences in sense that it does look nice if freebsd-boot is 
in front. Also, if you do have mirror setup, it is some work, but you can 
re-arrange mirror side partitioning (with usual cautions like having scrub 
done, having backup, having third disk would be helpful).

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: malloc() call somehow calling the rtld malloc() implementaion

[Alexander Kabaev]

On Fri, 27 Jan 2017 10:47:20 -0800 (PST)
Don Lewis  wrote:

> On 27 Jan, Alexander Kabaev wrote:
> > On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
> > Don Lewis  wrote:  
> 
> >> If I create a simple test program that calls malloc() and set a
> >> breakpoint in malloc(), the breakpoint gets set in the rtld
> >> version, but the the libc version of malloc is what gets called.
> >> 
> >> What the heck is going on here, and how can I fix it?
> >>   
> > 
> > rtld on my system does not have malloc exposed as dynamic symbol, it
> > cannot possibly be used for symbol resolution by any outside
> > module.  
> 
> Same here, but gdb at least seems to find it anyway.
> 
> 12.0-CURRENT r311765M
> 
> %nm /libexec/ld-elf.so.1
> nm: /libexec/ld-elf.so.1: no symbols
> 
> %elfdump -s /libexec/ld-elf.so.1 | grep st_name | sort
>   st_name: 
>   st_name: 
>   st_name: FBSD_1.0
>   st_name: FBSD_1.1
>   st_name: FBSD_1.2
>   st_name: FBSD_1.3
>   st_name: FBSD_1.4
>   st_name: FBSD_1.5
>   st_name: FBSDprivate_1.0
>   st_name: __tls_get_addr
>   st_name: _r_debug_postinit
>   st_name: _rtld_addr_phdr
>   st_name: _rtld_allocate_tls
>   st_name: _rtld_atfork_post
>   st_name: _rtld_atfork_pre
>   st_name: _rtld_error
>   st_name: _rtld_free_tls
>   st_name: _rtld_get_stack_prot
>   st_name: _rtld_is_dlopened
>   st_name: _rtld_thread_init
>   st_name: dl_iterate_phdr
>   st_name: dladdr
>   st_name: dlclose
>   st_name: dlerror
>   st_name: dlfunc
>   st_name: dlinfo
>   st_name: dllockinit
>   st_name: dlopen
>   st_name: dlsym
>   st_name: dlvsym
>   st_name: fdlopen
>   st_name: r_debug_state
> 
> %cd /tmp
> zipper:/tmp 508%cat malloctest.c 
> #include 
> volatile void *p;
> int
> main(void) {
>   p = malloc(16);
> }
> %cc -g malloctest.c
> %gdb a.out
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details. This GDB was configured as "amd64-marcel-freebsd"...
> (gdb) break main
> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
> (gdb) run
> Starting program: /tmp/a.out 
> 
> Breakpoint 1, main () at malloctest.c:5
> 5 p = malloc(16);
> Current language:  auto; currently minimal
> (gdb) break malloc
> Breakpoint 2 at 0x80060e9a4: file /usr/src/libexec/rtld-elf/malloc.c,
> line 163. (gdb) cont
> Continuing.
> 
> Program exited normally.
> (gdb) quit
> 
> Ports gdb finds both the rtld malloc() and the libc malloc():
> 
> %/usr/local/bin/gdb a.out
> GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
>  This is free software: you are
> free to change and redistribute it. There is NO WARRANTY, to the
> extent permitted by law.  Type "show copying" and "show warranty" for
> details. This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from a.out...done.
> (gdb) break main
> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
> (gdb) run
> Starting program: /tmp/a.out 
> 
> Breakpoint 1, main () at malloctest.c:5
> 5 p = malloc(16);
> (gdb) break malloc
> Breakpoint 2 at 0x80060e9a4: malloc. (2 locations)
> (gdb) cont
> Continuing.
> 
> Breakpoint 2, __malloc (size=16) at jemalloc_jemalloc.c:1636
> 1636  size_t usize JEMALLOC_CC_SILENCE_INIT(0);

gdb looks into debugging info for symbols in debug information and so
has greater visibility. Symbols gdb sees play no role in dynasmic
building, so rtld malloc somehow replacing the malloc from the program
as you suspected is really impossible.

kib@ has a better idea that is worth investigating further: is the
address on which idlc traps corresponds to TLS storage? tls alloc calls
are supposed to respect the tls section alignment though.

-- 
Alexander Kabaev


pgpz16Dbu9ryG.pgp
Description: Цифровая подпись OpenPGP

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 12:23, Toomas Soome  wrote:

...

>> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
>> the swap partition.
>> 
>> We have a similar problem at work with sys/boot unfortunately, but that's a 
>> side discussion for another time/place.
>> 
>> Thank you for the idea though -- I'll check when I get back to work.
>> 
>> -Ngie
> 
> Note the order of the partitions is not important, at least on paper anyhow. 
> Of course there are preferences in sense that it does look nice if 
> freebsd-boot is in front. Also, if you do have mirror setup, it is some work, 
> but you can re-arrange mirror side partitioning (with usual cautions like 
> having scrub done, having backup, having third disk would be helpful).

I have a raidz with 3 SSDs on it IIRC. Removing the SSD from the pool and 
readjusting partitions would probably be ok, but I'm not really keen on doing 
potentially destructive things like that, unless I absolutely have to do them 
:/..

Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 09:05, Warner Losh  wrote:

...

> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...

Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before the 
swap partition.

We have a similar problem at work with sys/boot unfortunately, but that's a 
side discussion for another time/place.

Thank you for the idea though -- I'll check when I get back to work.

-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 19:30, Allan Jude  wrote:
> 
> On 2017-01-27 12:05, Warner Losh wrote:
>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome > > wrote:
>>> 
 On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
  wrote:
 
 Hi,
  I tried upgrading one of my workstations and unfortunately the 
 freebsd-boot partition is too small (I follow manpage directions, exactly, 
 and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
 have enough space or ability to resize the partition and make it bigger. 
 So, I’m in need of a build knob to control the bloat, and/or having an 
 alternative boot loader without geli/skein/crypto support compiled in. 
 Would you be opposed to the work?
 Thanks,
 -Ngie
>>> 
>>> 
>>> I do agree that since the geli knob is already there, it may do. Of course 
>>> we also can think of additional knobs, but there is an issue - it wont help 
>>> just to exclude some files, the additional features also do sit in the 
>>> code, so the replacement stubs will be needed, also testing them all over 
>>> will take some time. And the preprocessor spaghetti really is nasty thing 
>>> to deal with;)
>>> 
>>> And then there is another issue (partly why I did the feature support in 
>>> first place) - as the kernel does not block user from enabling the 
>>> features, the user can end up facing non-bootable setup which is also not 
>>> good, as user is using perfectly legal options, and still the whole thing 
>>> is just rendered unusable…
>> 
>> I'm curious why you can't find the space for a bigger partition?
>> Almost all drives these days are partitioned with a little wasted
>> space, and that wasted space should be more than enough to cover us
>> here. Also, most drives have a swap partition that can be shrunk a
>> trivial amount to get space for this...
>> 
>> Warner
>> 
> 
> I need to do some testing to make a recipe that works for it, but the
> other option is to use the ZFS bootcode area.
> 
> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> partition, for boot code. This is how we boot ZFS on MBR.
> 
> It should be possible to use this on GPT as well, we just don't.
> 
> 

Indeed it is. this is how the illumos is doing, except that what in illumos, we 
use also a bit different boot method - instead of browsing the partition table, 
we record the boot2 start and size in pmbr, and the partition start in 
gptzfsboot, and we always boot based on recorded location - that does simplify 
the boot code in pmbr, but needs install tool, to detect and record the LBA.

And for fbsd case, the bootblock install must be able to distinguish 
geli/non-geli setups, and .. well, there are some complications:)

rgds,
toomas


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: malloc() call somehow calling the rtld malloc() implementaion

[Don Lewis]

On 27 Jan, Alexander Kabaev wrote:
> On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
> Don Lewis  wrote:

>> If I create a simple test program that calls malloc() and set a
>> breakpoint in malloc(), the breakpoint gets set in the rtld version,
>> but the the libc version of malloc is what gets called.
>> 
>> What the heck is going on here, and how can I fix it?
>> 
> 
> rtld on my system does not have malloc exposed as dynamic symbol, it
> cannot possibly be used for symbol resolution by any outside module.

Same here, but gdb at least seems to find it anyway.

12.0-CURRENT r311765M

%nm /libexec/ld-elf.so.1
nm: /libexec/ld-elf.so.1: no symbols

%elfdump -s /libexec/ld-elf.so.1 | grep st_name | sort
st_name: 
st_name: 
st_name: FBSD_1.0
st_name: FBSD_1.1
st_name: FBSD_1.2
st_name: FBSD_1.3
st_name: FBSD_1.4
st_name: FBSD_1.5
st_name: FBSDprivate_1.0
st_name: __tls_get_addr
st_name: _r_debug_postinit
st_name: _rtld_addr_phdr
st_name: _rtld_allocate_tls
st_name: _rtld_atfork_post
st_name: _rtld_atfork_pre
st_name: _rtld_error
st_name: _rtld_free_tls
st_name: _rtld_get_stack_prot
st_name: _rtld_is_dlopened
st_name: _rtld_thread_init
st_name: dl_iterate_phdr
st_name: dladdr
st_name: dlclose
st_name: dlerror
st_name: dlfunc
st_name: dlinfo
st_name: dllockinit
st_name: dlopen
st_name: dlsym
st_name: dlvsym
st_name: fdlopen
st_name: r_debug_state

%cd /tmp
zipper:/tmp 508%cat malloctest.c 
#include 
volatile void *p;
int
main(void) {
p = malloc(16);
}
%cc -g malloctest.c
%gdb a.out
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) break main
Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
(gdb) run
Starting program: /tmp/a.out 

Breakpoint 1, main () at malloctest.c:5
5   p = malloc(16);
Current language:  auto; currently minimal
(gdb) break malloc
Breakpoint 2 at 0x80060e9a4: file /usr/src/libexec/rtld-elf/malloc.c, line 163.
(gdb) cont
Continuing.

Program exited normally.
(gdb) quit

Ports gdb finds both the rtld malloc() and the libc malloc():

%/usr/local/bin/gdb a.out
GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...done.
(gdb) break main
Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
(gdb) run
Starting program: /tmp/a.out 

Breakpoint 1, main () at malloctest.c:5
5   p = malloc(16);
(gdb) break malloc
Breakpoint 2 at 0x80060e9a4: malloc. (2 locations)
(gdb) cont
Continuing.

Breakpoint 2, __malloc (size=16) at jemalloc_jemalloc.c:1636
1636size_t usize JEMALLOC_CC_SILENCE_INIT(0);

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Warner Losh]

On Fri, Jan 27, 2017 at 10:35 AM, Allan Jude  wrote:
> On 2017-01-27 12:33, Shawn Webb wrote:
>> On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
>>> On 2017-01-27 12:05, Warner Losh wrote:
 On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
>
>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>  wrote:
>>
>> Hi,
>>   I tried upgrading one of my workstations and unfortunately the 
>> freebsd-boot partition is too small (I follow manpage directions, 
>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
>> and I don???t have enough space or ability to resize the partition and 
>> make it bigger. So, I???m in need of a build knob to control the bloat, 
>> and/or having an alternative boot loader without geli/skein/crypto 
>> support compiled in. Would you be opposed to the work?
>> Thanks,
>> -Ngie
>
>
> I do agree that since the geli knob is already there, it may do. Of 
> course we also can think of additional knobs, but there is an issue - it 
> wont help just to exclude some files, the additional features also do sit 
> in the code, so the replacement stubs will be needed, also testing them 
> all over will take some time. And the preprocessor spaghetti really is 
> nasty thing to deal with;)
>
> And then there is another issue (partly why I did the feature support in 
> first place) - as the kernel does not block user from enabling the 
> features, the user can end up facing non-bootable setup which is also not 
> good, as user is using perfectly legal options, and still the whole thing 
> is just rendered unusable???

 I'm curious why you can't find the space for a bigger partition?
 Almost all drives these days are partitioned with a little wasted
 space, and that wasted space should be more than enough to cover us
 here. Also, most drives have a swap partition that can be shrunk a
 trivial amount to get space for this...

 Warner

>>>
>>> I need to do some testing to make a recipe that works for it, but the
>>> other option is to use the ZFS bootcode area.
>>>
>>> ZFS it self, reserves something like 3.5 mb of space in the ZFS
>>> partition, for boot code. This is how we boot ZFS on MBR.
>>>
>>> It should be possible to use this on GPT as well, we just don't.
>>
>> In the future, maybe it'd be a good idea for the installer to leave
>> more space (a few MB, perhaps?) between the freebsd-boot and
>> freebsd-swap partitions? At least, for ZFS installs.
>>
>> Thanks,
>>
>
> The PMBR code has a limitation for 536kb, and it all has to fit under
> the 640k barrier, so the current 512kb size is plenty. The issue is some
> people are upgrading from systems that were isntalled long ago, when
> 64kb or less was the default.

it's a limitation for the entire partition size, not just the code
size. Which is a trap that's hard to understand at first...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: malloc() call somehow calling the rtld malloc() implementaion

[Konstantin Belousov]

On Fri, Jan 27, 2017 at 12:19:16PM -0500, Alexander Kabaev wrote:
> On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
> Don Lewis  wrote:
> 
> > I've been attempting to get OpenOffice to build properly in a
> > clang400-import poudriere jail and have run into a mystery.  The build
> > procedure creates a c++ executable "idlc", which is used to build
> > other stuff.  The new operator has been overrriden to call a custom
> > memory allocator, which I have configured to call the system version
> > of malloc().
> > 
> > At some point idlc crashes because it has allocated a 16 byte
> > structure and the compiler is using "movaps %xmm0,(%rax)" to
> > initialize it, which requires 16 byte alignment.  Unfortunately this
> > structure is only 8 byte aligned, causing a bus error.  This
> > shouldn't be happening because our system malloc() always seems to do
> > the proper alignment.  It appears that intead of calling the version
> > of malloc() in libc, the simple version of malloc() built into rtld
> > is being called instead.
> > 
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and
> > you are welcome to change it and/or distribute copies of it under
> > certain conditions. Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details. This GDB was configured as "amd64-marcel-freebsd"...
> > (gdb) break main
> > Breakpoint 1 at 0x43b1f6: file idlcmain.cxx, line 34.
> > (gdb) run @/tmp/r
> > Starting
> > program: 
> > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc
> > @/tmp/r [New LWP 101304] [New Thread 802616000 (LWP 101304/idlc)]
> > [Switching to Thread 802616000 (LWP 101304/idlc)]
> > 
> > Breakpoint 1, main (argc=2, argv=0x7fffb278) at idlcmain.cxx:34
> > 34  SAL_IMPLEMENT_MAIN_WITH_ARGS(argc, argv)
> > (gdb) break malloc
> > Breakpoint 2 at 0x8006a5f01:
> > file /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c,
> > line 163. (gdb) cont Continuing.
> > Trace 12474/1: "Min Prioriy for policy '2' == '0'
> > "
> > Trace 12474/1: "Max Prioriy for policy '2' == '103'
> > "
> > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
> > compiling 1 source files ...
> > Compiling: 
> > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/offapi/com/sun/star/i18n/KParseTokens.idl
> > 
> > Breakpoint 2, malloc (nbytes=343)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163 /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:
> > No such file or directory.
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > Current language:  auto; currently minimal (gdb) cont
> > Continuing.
> > 
> > Breakpoint 2, malloc (nbytes=32)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > Trace 13112/2: "ChildStatusProc : starting
> > '/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/ucpp'"
> >  [New
> > Thread 802616500 (LWP 100249/idlc)] [Switching to Thread 802616500
> > (LWP 100249/idlc)]
> > 
> > Breakpoint 2, malloc (nbytes=19)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > 
> > Breakpoint 2, malloc (nbytes=34)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > 
> > Breakpoint 2, malloc (nbytes=16)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > 
> > Breakpoint 2, malloc (nbytes=16)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > 
> > Breakpoint 2, malloc (nbytes=16)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > 
> > Breakpoint 2, malloc (nbytes=16)
> > at 
> > /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> > 163
> > in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> > (gdb) cont Continuing.
> > sizeof(AstExprValue)=16
> > 
> > Program received signal SIGBUS, Bus error.
> > [Switching to Thread 802616000 (LWP 101304/idlc)]
> > 0x00478cc2 in AstExpre

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-27 12:05, Warner Losh wrote:
> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
>>
>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>>  wrote:
>>>
>>> Hi,
>>>   I tried upgrading one of my workstations and unfortunately the 
>>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>>> have enough space or ability to resize the partition and make it bigger. 
>>> So, I’m in need of a build knob to control the bloat, and/or having an 
>>> alternative boot loader without geli/skein/crypto support compiled in. 
>>> Would you be opposed to the work?
>>> Thanks,
>>> -Ngie
>>
>>
>> I do agree that since the geli knob is already there, it may do. Of course 
>> we also can think of additional knobs, but there is an issue - it wont help 
>> just to exclude some files, the additional features also do sit in the code, 
>> so the replacement stubs will be needed, also testing them all over will 
>> take some time. And the preprocessor spaghetti really is nasty thing to deal 
>> with;)
>>
>> And then there is another issue (partly why I did the feature support in 
>> first place) - as the kernel does not block user from enabling the features, 
>> the user can end up facing non-bootable setup which is also not good, as 
>> user is using perfectly legal options, and still the whole thing is just 
>> rendered unusable…
> 
> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...
> 
> Warner
> 

I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Shawn Webb]

On Fri, Jan 27, 2017 at 12:35:21PM -0500, Allan Jude wrote:
> On 2017-01-27 12:33, Shawn Webb wrote:
> > On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
> >> On 2017-01-27 12:05, Warner Losh wrote:
> >>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
> 
> > On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
> >  wrote:
> >
> > Hi,
> >   I tried upgrading one of my workstations and unfortunately the 
> > freebsd-boot partition is too small (I follow manpage directions, 
> > exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
> > and I don???t have enough space or ability to resize the partition and 
> > make it bigger. So, I???m in need of a build knob to control the bloat, 
> > and/or having an alternative boot loader without geli/skein/crypto 
> > support compiled in. Would you be opposed to the work?
> > Thanks,
> > -Ngie
> 
> 
>  I do agree that since the geli knob is already there, it may do. Of 
>  course we also can think of additional knobs, but there is an issue - it 
>  wont help just to exclude some files, the additional features also do 
>  sit in the code, so the replacement stubs will be needed, also testing 
>  them all over will take some time. And the preprocessor spaghetti really 
>  is nasty thing to deal with;)
> 
>  And then there is another issue (partly why I did the feature support in 
>  first place) - as the kernel does not block user from enabling the 
>  features, the user can end up facing non-bootable setup which is also 
>  not good, as user is using perfectly legal options, and still the whole 
>  thing is just rendered unusable???
> >>>
> >>> I'm curious why you can't find the space for a bigger partition?
> >>> Almost all drives these days are partitioned with a little wasted
> >>> space, and that wasted space should be more than enough to cover us
> >>> here. Also, most drives have a swap partition that can be shrunk a
> >>> trivial amount to get space for this...
> >>>
> >>> Warner
> >>>
> >>
> >> I need to do some testing to make a recipe that works for it, but the
> >> other option is to use the ZFS bootcode area.
> >>
> >> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> >> partition, for boot code. This is how we boot ZFS on MBR.
> >>
> >> It should be possible to use this on GPT as well, we just don't.
> > 
> > In the future, maybe it'd be a good idea for the installer to leave
> > more space (a few MB, perhaps?) between the freebsd-boot and
> > freebsd-swap partitions? At least, for ZFS installs.
> > 
> > Thanks,
> > 
> 
> The PMBR code has a limitation for 536kb, and it all has to fit under
> the 640k barrier, so the current 512kb size is plenty. The issue is some
> people are upgrading from systems that were isntalled long ago, when
> 64kb or less was the default.

Gotcha. Thanks for the explanation.

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Allan Jude]

On 2017-01-27 12:33, Shawn Webb wrote:
> On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
>> On 2017-01-27 12:05, Warner Losh wrote:
>>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:

> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>  wrote:
>
> Hi,
>   I tried upgrading one of my workstations and unfortunately the 
> freebsd-boot partition is too small (I follow manpage directions, 
> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
> and I don???t have enough space or ability to resize the partition and 
> make it bigger. So, I???m in need of a build knob to control the bloat, 
> and/or having an alternative boot loader without geli/skein/crypto 
> support compiled in. Would you be opposed to the work?
> Thanks,
> -Ngie


 I do agree that since the geli knob is already there, it may do. Of course 
 we also can think of additional knobs, but there is an issue - it wont 
 help just to exclude some files, the additional features also do sit in 
 the code, so the replacement stubs will be needed, also testing them all 
 over will take some time. And the preprocessor spaghetti really is nasty 
 thing to deal with;)

 And then there is another issue (partly why I did the feature support in 
 first place) - as the kernel does not block user from enabling the 
 features, the user can end up facing non-bootable setup which is also not 
 good, as user is using perfectly legal options, and still the whole thing 
 is just rendered unusable???
>>>
>>> I'm curious why you can't find the space for a bigger partition?
>>> Almost all drives these days are partitioned with a little wasted
>>> space, and that wasted space should be more than enough to cover us
>>> here. Also, most drives have a swap partition that can be shrunk a
>>> trivial amount to get space for this...
>>>
>>> Warner
>>>
>>
>> I need to do some testing to make a recipe that works for it, but the
>> other option is to use the ZFS bootcode area.
>>
>> ZFS it self, reserves something like 3.5 mb of space in the ZFS
>> partition, for boot code. This is how we boot ZFS on MBR.
>>
>> It should be possible to use this on GPT as well, we just don't.
> 
> In the future, maybe it'd be a good idea for the installer to leave
> more space (a few MB, perhaps?) between the freebsd-boot and
> freebsd-swap partitions? At least, for ZFS installs.
> 
> Thanks,
> 

The PMBR code has a limitation for 536kb, and it all has to fit under
the 640k barrier, so the current 512kb size is plenty. The issue is some
people are upgrading from systems that were isntalled long ago, when
64kb or less was the default.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Shawn Webb]

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
> On 2017-01-27 12:05, Warner Losh wrote:
> > On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
> >>
> >>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
> >>>  wrote:
> >>>
> >>> Hi,
> >>>   I tried upgrading one of my workstations and unfortunately the 
> >>> freebsd-boot partition is too small (I follow manpage directions, 
> >>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
> >>> and I don???t have enough space or ability to resize the partition and 
> >>> make it bigger. So, I???m in need of a build knob to control the bloat, 
> >>> and/or having an alternative boot loader without geli/skein/crypto 
> >>> support compiled in. Would you be opposed to the work?
> >>> Thanks,
> >>> -Ngie
> >>
> >>
> >> I do agree that since the geli knob is already there, it may do. Of course 
> >> we also can think of additional knobs, but there is an issue - it wont 
> >> help just to exclude some files, the additional features also do sit in 
> >> the code, so the replacement stubs will be needed, also testing them all 
> >> over will take some time. And the preprocessor spaghetti really is nasty 
> >> thing to deal with;)
> >>
> >> And then there is another issue (partly why I did the feature support in 
> >> first place) - as the kernel does not block user from enabling the 
> >> features, the user can end up facing non-bootable setup which is also not 
> >> good, as user is using perfectly legal options, and still the whole thing 
> >> is just rendered unusable???
> > 
> > I'm curious why you can't find the space for a bigger partition?
> > Almost all drives these days are partitioned with a little wasted
> > space, and that wasted space should be more than enough to cover us
> > here. Also, most drives have a swap partition that can be shrunk a
> > trivial amount to get space for this...
> > 
> > Warner
> > 
> 
> I need to do some testing to make a recipe that works for it, but the
> other option is to use the ZFS bootcode area.
> 
> ZFS it self, reserves something like 3.5 mb of space in the ZFS
> partition, for boot code. This is how we boot ZFS on MBR.
> 
> It should be possible to use this on GPT as well, we just don't.

In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: malloc() call somehow calling the rtld malloc() implementaion

[Alexander Kabaev]

On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
Don Lewis  wrote:

> I've been attempting to get OpenOffice to build properly in a
> clang400-import poudriere jail and have run into a mystery.  The build
> procedure creates a c++ executable "idlc", which is used to build
> other stuff.  The new operator has been overrriden to call a custom
> memory allocator, which I have configured to call the system version
> of malloc().
> 
> At some point idlc crashes because it has allocated a 16 byte
> structure and the compiler is using "movaps %xmm0,(%rax)" to
> initialize it, which requires 16 byte alignment.  Unfortunately this
> structure is only 8 byte aligned, causing a bus error.  This
> shouldn't be happening because our system malloc() always seems to do
> the proper alignment.  It appears that intead of calling the version
> of malloc() in libc, the simple version of malloc() built into rtld
> is being called instead.
> 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details. This GDB was configured as "amd64-marcel-freebsd"...
> (gdb) break main
> Breakpoint 1 at 0x43b1f6: file idlcmain.cxx, line 34.
> (gdb) run @/tmp/r
> Starting
> program: 
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc
> @/tmp/r [New LWP 101304] [New Thread 802616000 (LWP 101304/idlc)]
> [Switching to Thread 802616000 (LWP 101304/idlc)]
> 
> Breakpoint 1, main (argc=2, argv=0x7fffb278) at idlcmain.cxx:34
> 34SAL_IMPLEMENT_MAIN_WITH_ARGS(argc, argv)
> (gdb) break malloc
> Breakpoint 2 at 0x8006a5f01:
> file /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c,
> line 163. (gdb) cont Continuing.
> Trace 12474/1: "Min Prioriy for policy '2' == '0'
> "
> Trace 12474/1: "Max Prioriy for policy '2' == '103'
> "
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
> compiling 1 source files ...
> Compiling: 
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/offapi/com/sun/star/i18n/KParseTokens.idl
> 
> Breakpoint 2, malloc (nbytes=343)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163   /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:
> No such file or directory.
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> Current language:  auto; currently minimal (gdb) cont
> Continuing.
> 
> Breakpoint 2, malloc (nbytes=32)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> Trace 13112/2: "ChildStatusProc : starting
> '/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/ucpp'"
>  [New
> Thread 802616500 (LWP 100249/idlc)] [Switching to Thread 802616500
> (LWP 100249/idlc)]
> 
> Breakpoint 2, malloc (nbytes=19)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> 
> Breakpoint 2, malloc (nbytes=34)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> 
> Breakpoint 2, malloc (nbytes=16)
> at 
> /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
> 163
> in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
> (gdb) cont Continuing.
> sizeof(AstExprValue)=16
> 
> Program received signal SIGBUS, Bus error.
> [Switching to Thread 802616000 (LWP 101304/idlc)]
> 0x00478cc2 in AstExpression::eval_bit_op (this=0x802633dc8, 
> ek=EK_const) at astexpression.cxx:1001
> 1001  std::auto_ptr< AstExprValue > retval(new
> AstExprValue());
> 
> 
> idlc is linked to libc.so:
> 
> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
> 

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Warner Losh]

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:
>
>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
>> wrote:
>>
>> Hi,
>>   I tried upgrading one of my workstations and unfortunately the 
>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>> have enough space or ability to resize the partition and make it bigger. So, 
>> I’m in need of a build knob to control the bloat, and/or having an 
>> alternative boot loader without geli/skein/crypto support compiled in. Would 
>> you be opposed to the work?
>> Thanks,
>> -Ngie
>
>
> I do agree that since the geli knob is already there, it may do. Of course we 
> also can think of additional knobs, but there is an issue - it wont help just 
> to exclude some files, the additional features also do sit in the code, so 
> the replacement stubs will be needed, also testing them all over will take 
> some time. And the preprocessor spaghetti really is nasty thing to deal with;)
>
> And then there is another issue (partly why I did the feature support in 
> first place) - as the kernel does not block user from enabling the features, 
> the user can end up facing non-bootable setup which is also not good, as user 
> is using perfectly legal options, and still the whole thing is just rendered 
> unusable…

I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Toomas Soome]

> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> Hi,
>   I tried upgrading one of my workstations and unfortunately the 
> freebsd-boot partition is too small (I follow manpage directions, exactly, 
> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
> have enough space or ability to resize the partition and make it bigger. So, 
> I’m in need of a build knob to control the bloat, and/or having an 
> alternative boot loader without geli/skein/crypto support compiled in. Would 
> you be opposed to the work?
> Thanks,
> -Ngie


I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable…

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

malloc() call somehow calling the rtld malloc() implementaion

[Don Lewis]

I've been attempting to get OpenOffice to build properly in a
clang400-import poudriere jail and have run into a mystery.  The build
procedure creates a c++ executable "idlc", which is used to build other
stuff.  The new operator has been overrriden to call a custom memory
allocator, which I have configured to call the system version of
malloc().

At some point idlc crashes because it has allocated a 16 byte structure
and the compiler is using "movaps %xmm0,(%rax)" to initialize it, which
requires 16 byte alignment.  Unfortunately this structure is only 8 byte
aligned, causing a bus error.  This shouldn't be happening because our
system malloc() always seems to do the proper alignment.  It appears
that intead of calling the version of malloc() in libc, the simple
version of malloc() built into rtld is being called instead.

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) break main
Breakpoint 1 at 0x43b1f6: file idlcmain.cxx, line 34.
(gdb) run @/tmp/r
Starting program: 
/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc
 @/tmp/r
[New LWP 101304]
[New Thread 802616000 (LWP 101304/idlc)]
[Switching to Thread 802616000 (LWP 101304/idlc)]

Breakpoint 1, main (argc=2, argv=0x7fffb278) at idlcmain.cxx:34
34  SAL_IMPLEMENT_MAIN_WITH_ARGS(argc, argv)
(gdb) break malloc
Breakpoint 2 at 0x8006a5f01: file 
/var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c, line 163.
(gdb) cont
Continuing.
Trace 12474/1: "Min Prioriy for policy '2' == '0'
"
Trace 12474/1: "Max Prioriy for policy '2' == '103'
"
/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
 compiling 1 source files ... 
Compiling: 
/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/offapi/com/sun/star/i18n/KParseTokens.idl

Breakpoint 2, malloc (nbytes=343)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c: 
No such file or directory.
in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
Current language:  auto; currently minimal
(gdb) cont
Continuing.

Breakpoint 2, malloc (nbytes=32)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.
Trace 13112/2: "ChildStatusProc : starting 
'/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/ucpp'"
[New Thread 802616500 (LWP 100249/idlc)]
[Switching to Thread 802616500 (LWP 100249/idlc)]

Breakpoint 2, malloc (nbytes=19)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.

Breakpoint 2, malloc (nbytes=34)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.

Breakpoint 2, malloc (nbytes=16)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.

Breakpoint 2, malloc (nbytes=16)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.

Breakpoint 2, malloc (nbytes=16)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.

Breakpoint 2, malloc (nbytes=16)
at /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c:163
163 in /var/poudriere/jails/clang400amd64/usr/src/libexec/rtld-elf/malloc.c
(gdb) cont
Continuing.
sizeof(AstExprValue)=16

Program received signal SIGBUS, Bus error.
[Switching to Thread 802616000 (LWP 101304/idlc)]
0x00478cc2 in AstExpression::eval_bit_op (this=0x802633dc8, 
ek=EK_const) at astexpression.cxx:1001
1001std::auto_ptr< AstExprValue > retval(new AstExprValue());


idlc is linked to libc.so:

/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc:
libreg.so.3 => 
/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib/libreg.so.3
 (0x8008b9000)
libuno_sal.so.3 => 
/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib/libu