mx2927 | 30 Aug 17:36 2015
Picon

va_list and vprintf

Hi all,

I stumbled in the following problem, which is easily explained by the 
following example code:

// begin
#include <stdio.h>
#include <stdarg.h>

void do_print(char* fmt, ...)
{
   va_list ap;
   va_start(ap, fmt);

   vprintf(fmt, ap);
   vprintf(fmt, ap);

   va_end(ap);
}

int main()
{

   do_print("Hello %d, %d, %d\n", 1, 2, 3, 4, 5, 6);

   return 0;
}
// end

The libc manual says about vprintf:
(Continue reading)

Dennis Luehring | 28 Aug 15:17 2015
Picon
Picon

try to compile cross compilers for sparc,alpha and powerpc + glibc 2.22

based on the briliant tutorial by Jeff Preshing
http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/

and his all-in-one-wonder shellscript: 
https://gist.github.com/preshing/41d5c7248dea16238b60
(the questions uses this script+line numbers as orientation)

im able to build a cross-compile suite for aarch64 without any problem
just installed debian 8.1 in a virtual machine

changed BINUTILS_VERSION to binutils-2.25 in line 21
changed LINUX_KERNEL_VERSION to linux-3.18.20 in line 29

and started the scripts - works out of the box in ~13min to get a cross 
compile suite for aarch64

with
1. binutils
2. kernel-headers
3. c/c++ compiler
4. glibc <-- compile problems at this point with sparc,alpha,powerpc - 
but not with aarch64
5. libstdc++

then i tried to build a cross-compiler suite for sparc,alpha and powerpc 
(TARGET in line 16)
and stuck in every target on glibc compilation due to (what i think) 
missing headers

it seems that glibc wants some headers that aren't "exported" in line 72 
(Continue reading)

Tjernlund | 25 Aug 20:43 2015
Picon

getent not working on nss db passwd files:

# > cd /var/db/
# > echo "clue:x:1005:987:added by portage for clue:/var/tmp:/sbin/nologin" | makedb  -o passwd.db  -
# > makedb -u passwd.db 
clue:x:1005:987:added by portage for clue:/var/tmp/:/sbin/nologin

cat /etc/nsswitch.conf
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29
23:52:23 vapier Exp $

passwd:      compat db
shadow:      compat
group:       compat
.....

# > getent passwd clue
< No output from getent >

# > strace getent passwd clue
.....
open("/var/db/passwd.db", O_RDONLY|O_CLOEXEC) = 3
read(3, "\1\6\21\335\1\0\0\0 <at> \0\0\0\0\0\0\0,\0\0\0\0\0\0\0\200\0\0\0\0\0\0\0", 32) = 32
mmap(NULL, 128, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6ed6f08000
close(3)                                = 0
munmap(0x7f6ed6f08000, 128)             = 0
exit_group(2)                           = ?
+++ exited with 2 +++

I am doing something wrong or is it an bug?

(Continue reading)

Juan Manuel Torres Palma | 25 Aug 07:08 2015
Picon

[Manual] Problems building the manual.

Dear glibc developers,

While fixing some patches for the glibc manual, a building problem has
come across and it's being very annoying.

While documenting a function, I am changing the safety annotations and
that seems to break the build. I have checked other files like
time.texi and they do exactly what I want to do. Let me illustrate
with an example:

If I define the function as follows, compiles perfectly:
-----------------------------------------------------------------------------
 <at> deftypefun thrd_t thrd_current (void)
 <at> safety{ <at> prelim{} <at> mtsafe{} <at> assafe{} <at> acsafe{}}
Returns the identifier of the calling thread.
 <at> end deftypefun
-----------------------------------------------------------------------------

However, just changing  <at> mtsafe{} to  <at> mtunsafe{} breaks the build:
-----------------------------------------------------------------------------
 <at> deftypefun thrd_t thrd_current (void)
 <at> safety{ <at> prelim{} <at> mtunsafe{} <at> assafe{} <at> acsafe{}}
Returns the identifier of the calling thread.
 <at> end deftypefun
-----------------------------------------------------------------------------
The error message I get is:
isothreads.texi:55: <at> safety{ <at> prelim{} <at> mtunsafe{} <at> assafe{} <at> acsafe{}}
Makefile:88: recipe for target
'/home/jmtp/workspace/glibc-code/build/manual/stamp-summary' failed

(Continue reading)

Holliday, Robert | 21 Aug 23:43 2015

RE: DNS Resolver library testing

There are many vulnerabilities in the DNS Resolver library.

I have found many zero-day vulnerabilities in the DNS Resolver library in the current version of the GLIBC
library using Codenomicon Defensics, a fuzz testing tool.

I wanted to coordinate free Fuzz testing of the DNS Resolver library with Codenomicon Defensics,
a commercial powerful fuzz testing tool. They are willing to work with Open Source projects to
find vulnerabilities in their software. 

Is there a contact with the GLIBC library, that would be willing to work with Codenomicon, 
to scan the DNS Resolver library, and report the vulnerabilities to the GLIBC community,
which would help get them fixed and make the DNS library used more secure?

Please contact cross@... They have worked with many other 
open source projects to make them less vulnerable. I am not able to get the
DNS library scanned by them, they will only work with members of the GLIBC team.

Thanks.

john smith | 21 Aug 17:54 2015
Picon

are statically allocated structs always aligned to a machine word on x86/x86_64?

I didn't find any information about alignment requirements for
statically allocated objects in glibc manual (or I have missed because
the manual is huge). I noted that sometimes variables such as int are
not aligned on word boundary in x86 and x86_64 but I have never seen a
struct that wouldn't be allocated at address that isn't a multiple or
4/8. I am asking this question because I would like to know whether
it's safe to assume that struct will be always assigned at a word
boundary and therefore it's possible to correctly calculate a struct
size without running a program.

--

-- 
<wempwer@...>

Holliday, Robert | 20 Aug 17:18 2015

DNS Resolv and BIND Update?

Why doesn't the DNS Resolver library, glibc/resolv, ever get updated to use the
newest BIND DNS code?

Linda A. Walsh | 18 Aug 01:04 2015

probllems with ltdl versions and building newer versions

I've been using -flto with most of my builds without problems.

Then I got to squid-3.5.7 which had its own and I tried to use.

It didn't play well with what I had installed, (at link time
many things were 'unresolved'), so I tried to use the ltdl included
with squid.

Now my "other builds" no longer work with messages along the lines
of a 2.2 vs. 3.0 version incompat.

Looked up source for lto and found gnu page 
https://gcc.gnu.org/wiki/LinkTimeOptimization
...followed instructions there and a few variations ...
nothing would generate lto or any installable.

Error messages center around some struct sizes:
  /usr/bin/gcc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions  -I. 
-I../../lto/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat 
-Wstrict-prototypes -pedantic  -fpic ../../lto/libiberty/physmem.c -o 
pic/physmem.o; \
else true; fi
../../lto/libiberty/physmem.c: In function 'physmem_total':
../../lto/libiberty/physmem.c:96:23: error: storage size of 'pss' isn't 
known
     struct pst_static pss;
                       ^
../../lto/libiberty/physmem.c:97:5: warning: implicit declaration of 
function 'pstat_getstatic' [-Wimplicit-function-declaration]
     if (0 <= pstat_getstatic (&pss, sizeof pss, 1, 0))
(Continue reading)

Stefan Hajnoczi | 14 Aug 16:44 2015
Picon

Adding AF_VSOCK to getaddrinfo(3)

The Linux AF_VSOCK address family is used for host/guest communication
on VMware hypervisors and I am working on virtio support for KVM and
other open source hypervisors.

Existing programs can be extended to support AF_VSOCK - the effort is
similar to adding IPv6 support to a program.  Many programs already rely
on getaddrinfo(3) so I'd like to add AF_VSOCK support there too.

I have the following textual representation in mind:

Represent AF_VSOCK <uint32_t cid, uint32_t port> addresses textually as
node "[vsock:<cid>]" and service "<port>".  For example, cid 2 and port
80
is written as node "[vsock:2]" and service "80".

This is close to the IPv6 notation but not a valid IPv6 address, so it's
possible to extend address parsing code to handle the AF_VSOCK case.

Is it reasonable to extend getaddrinfo(3) in this way?

Thanks,
Stefan
Mathieu Westphal | 6 Aug 09:06 2015

dl-open/dl-lookup/dl-close potential bug

Hello

looking at source it appears that calling a dlclose on a library with
DF_A_NODELETE flag positioned will fail with an assert error :

Inconsistency detected by ld.so: dl-close.c: 764: _dl_close: Assertion
`map->l_init_called' failed!

I would prefer if it could fail a bit more silently, so it will not be
necessary to choose between "closable" and "non-closable" lib when
closing libraries.
For example a error value.

Or it may be simply a bug

What do you think ?
Mathieu Westphal

Holliday, Robert | 3 Aug 22:56 2015

Buffer size issues in received dns messages

Issue:
Bug 18665 - In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

I have submitted this issue a while ago, and I was wondering how I could get somebody to
review the issue.

I want to move this issue from BUG to PATCH.

Thanks,
Robert.


Gmane