Nabble - uClibc

res_query() brain damage

2009-12-02T21:15:18Z

Recently, I've transitioned my routing computer over to uClibc. It
mostly works well, but I noticed some minor glitches with Exim (the mail
server).

After some investigation, I traced the problem to uClibc's
implementation of res_query, which contains the following:

--
i = __dns_lookup(dname, type, __nameserversXX, [...]

if (i < 0) {
h_errno = TRY_AGAIN;
return -1;
}
--

This means that all negative DNS results get reported as temporary
failures -- which confuses the mailserver. It cares much about the
difference between an ambiguous result due to failure and an definitive
denial that a record exists.

The result is a lot of log messages complaining about tempfailing dnsbl
blacklists (but fortunately no actual loss of their spam protection),
and endless deferral of email coming from domains with no MX record.

Diking the "h_errno = TRY_AGAIN;" line appears to resolve the problem.
(h_errno is set properly from within __dns_lookup.)

Were this a complicated emergent behavior of the library, I'd just
report it via the bug tracker. However, this looks like it was
deliberate -- so I'm bringing it to the list for comment.

---- Michael Deutschmann <michael@...>
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: nptl branch going away, use nptl_merge

2009-12-02T06:52:24Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Landley wrote:

> On Monday 23 November 2009 12:14:07 Austin Foxley wrote:
>> On 11/23/2009 01:23 AM, Bernhard Reutner-Fischer wrote:
>>> Good idea.
>>> Is there something preventing a rename of nptl_merge -> nptl now?
>> Done. nptl_merge is now nptl.
>>
>> -Austin
>
> Confused. I'm testing via:
>
> git archive --prefix=uClibc/ origin/nptl_merge | bzip2 > ~/test-uClibc.tar.bz2
>
> I just did a "git pull", followed by "git branch -a", and it shows:
>
> * master
> origin/0_9_28
> origin/0_9_29
> origin/0_9_30
> origin/HEAD
> origin/master
> origin/nptl
> origin/nptl_merge
> origin/old_nptl
>
> I don't know which branch is what at this point. I take it the easy way to fix
> this is to "rm -rf ~/uclibc/git" and re-check-out the whole mess?
>
> Rob
>
> (I really hate git.)

#git remote prune origin

will do the work for you. Use --dry-run to see what it will prune without
actually pruning. Hope it helps.

Carmelo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAksWfygACgkQoRq/3BrK1s831gCg+govUEgDLfQao8q5LPP9UDKf
CNcAoJYOTzUkUtmghU0QkMGQZQdch2xa
=1lMT
-----END PGP SIGNATURE-----
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: building static busybox/toybox with uclibc-nptl

2009-12-02T06:29:47Z

On 12/02/2009 12:58 AM, Natanael Copa wrote:
> /home/ncopa/src/firmware-0.9.8/build/root-filesystem-i586/usr/lib/libc.a(fork.os): In function `fork':
> fork.c:(.text.__libc_fork+0xf5): undefined reference to `pthread_mutexattr_init'
> fork.c:(.text.__libc_fork+0xfd): undefined reference to `pthread_mutexattr_settype'
> fork.c:(.text.__libc_fork+0x114): undefined reference to `pthread_mutex_init'
> fork.c:(.text.__libc_fork+0x125): undefined reference to `pthread_mutexattr_destroy'

Try turning on "Use stdio futexes". It's under string support for some reason. I
was hoping to make that the default as it makes libc not need pthread_mutex.

-Austin

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

building static busybox/toybox with uclibc-nptl

2009-12-02T00:57:51Z

Hi,

I'm trying to build a native toolchain for x86 uclibc-nptl, using
firmwarelinux.

So for I have needed to disable the rpc stuff in uclibc and mount in
busybox to be able to build it.

However, during linking phase, I get this error:

==========
archival/lib.a(bbunzip.o): In function `bbunpack':
archival/bbunzip.c:116: warning: the use of OBSOLESCENT `utime' is discouraged, use `utimes'
networking/lib.a(ipcalc.o): In function `ipcalc_main':
networking/ipcalc.c:179: warning: gethostbyaddr is obsolescent, use getaddrinfo() instead.
libbb/lib.a(inet_common.o): In function `INET_resolve':
libbb/inet_common.c:68: warning: gethostbyname is obsolescent, use getnameinfo() instead.
/home/ncopa/src/firmware-0.9.8/build/root-filesystem-i586/usr/lib/libc.a(fork.os): In function `fork':
fork.c:(.text.__libc_fork+0xf5): undefined reference to `pthread_mutexattr_init'
fork.c:(.text.__libc_fork+0xfd): undefined reference to `pthread_mutexattr_settype'
fork.c:(.text.__libc_fork+0x114): undefined reference to `pthread_mutex_init'
fork.c:(.text.__libc_fork+0x125): undefined reference to `pthread_mutexattr_destroy'
make: *** [busybox_unstripped] Error 1

I get same error with toybox.

If i force it to link dynamic it works.

-nc

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

sh: SHMLBA & cache shape info from auxvt

2009-12-01T02:17:48Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All, Paul
we are adding the code in uClibc ld.so to retrieve the value
of shm_alignment from the cache shape info passed to the user space
through the AUXVT for sh arch.

Currently in bits/shm.h we have

/* Segment low boundary address multiple. */
/*
* XXX: This is misleading, SH-4 and SH-3 7705 in 32kb mode have dcache
* aliases to contend with in the 4k page case. This is not an issue for
* the other parts. Leave this bumped up for sanity until this can be
* accurately defined by the L1D shape through the auxiliary vector.
*/
#define SHMLBA (__getpagesize() << 2)

The comment (I guess Paul added) is definitely clear.

We would like to have something like that

#define SHMLBA __get_shm_alignment()

but this will add a reference to a new function into any binaries
compiled using the new header that will not work with older runtime libraries
(not a major problem because header and libraries should be always aligned).

My doubt is it is allowed to add/export a new function in lib C that is not
part of the POSIX API.

Another option could be to remap the macro with sysconf, so

#define SHMLBA sysconf(_SC_SHM_ALIGNMENT)

or something like that, but also in this case we need to export a new
sysconf name in bits/confname.h; is this allowed ?

Cheers,
Carmelo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAksU7UwACgkQoRq/3BrK1s/cZQCeME4hljRMipGGlN8Gpi1hdZd5
IXAAnA1U9XGq6Q9R3nMLk06pRe7Ca3gS
=dwqq
-----END PGP SIGNATURE-----
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: bugs in malloc

2009-11-29T17:52:12Z

Hello Peter,

Unfortunately, my 0.9.28 build is using 0.9.28.3 and the changes you
mentioned are there and the crash is not happening. It has to be something
else.

Thanks for the info.

Sergio

On 11/26/09 1:34 PM, "Peter Mazinger" <ps.m@...> wrote:

> Hi,
>
> it might also be a mutex/threads issue, I know of a bug introduced somewhere
> between 0.9.28 and 0.9.28.2 iirc, it is in uClibc_mutex.h. One of the macros
> does not check for a case = NULL, I reported this to the committer and the
> maintainer at that time. To test if I am right, replace
> __UCLIBC_MUTEX_CONDITIONAL_LOCK(M,C) and UNLOCK with their counterparts
> __UCLIBC_MUTEX_[UN]LOCK_CANCEL_UNSAFE(M), rebuild uClibc and then your app.
>
> Peter
>
> -------- Original-Nachricht --------
>> Datum: Tue, 24 Nov 2009 07:14:36 -0500
>> Von: "Sergio M. Ammirata, Ph.D." <sergio@...>
>> An: Freeman Wang <xwang@...>, Mike Frysinger <vapier@...>,
>> uclibc@...
>> Betreff: Re: bugs in malloc
>
>> If it helps, I am also experiences crashes in malloc. They did not occur
>> in
>> 0.9.28. Here is a sample backtrace:
>>
>> Program terminated with signal 11, Segmentation fault.
>> [New process 1788]
>> [New process 1752]
>> [New process 1784]
>> [New process 1783]
>> [New process 1789]
>> [New process 1791]
>> [New process 1787]
>> [New process 1785]
>> [New process 1786]
>> #0 0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
>> heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
>> 184 mem = MALLOC_SETUP (mem, size);
>> (gdb) bt
>> #0 0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
>> heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
>> #1 0x3782e53c in malloc (size=506912) at libc/stdlib/malloc/malloc.c:223
>> #2 0x3782eb10 in memalign (alignment=16, size=506880) at
>> libc/stdlib/malloc/memalign.c:48
>> #3 0x08083fd1 in __vout_AllocatePicture (p_this=0x8d74f6c,
>> p_pic=0x9a1a048,
>> i_chroma=808596553, i_width=704, i_height=480, i_aspect=576000) at
>> video_output/vout_pictures.c:515
>> #4 0x373bdacf in video_new_buffer (p_this=0x8d74f6c, pp_ring=0x8893868,
>> p_sys=0x8885680) at transcode.c:2499
>> #5 0x08144ed4 in DecodeBlock (p_dec=0x8d74f6c, pp_block=0x3efff89c) at
>> libmpeg2.c:604
>> #6 0x373c026d in Send (p_stream=0x887f6c8, id=0x8892bf8,
>> p_buffer=0xcf0bec0) at transcode.c:2030
>> #7 0x373e00a6 in Send (p_stream=0x887e32c, id=0x8892bd0,
>> p_buffer=0xcf0bec0) at duplicate.c:277
>> #8 0x0809182c in sout_InputSendBuffer (p_input=0x8892bc0,
>> p_buffer=0xcf0bec0) at stream_output/stream_output.c:279
>> #9 0x080d31e8 in DecoderDecode (p_dec=0x88a91bc, p_block=0xd232f28) at
>> input/decoder.c:579
>> #10 0x080d70ac in EsOutSend (out=0x887b21c, es=0x88a6e08,
>> p_block=0xd232f28)
>> at input/es_out.c:1107
>> #11 0x080ffed9 in ParsePES (p_demux=0x8890c64, pid=0x999cf10) at
>> ../../include/vlc_es_out.h:109
>> #12 0x08101a58 in Demux (p_demux=0x8890c64) at ts.c:1927
>> #13 0x08073a6f in MainLoop (p_input=0x8882170) at input/input.c:538
>> #14 0x08074b17 in Run (p_input=0x8882170) at input/input.c:444
>> #15 0x378b3136 in pthread_start_thread (arg=0x3efffea0) at
>> libpthread/linuxthreads.old/manager.c:309
>> #16 0x377c2c12 in clone () at libc/sysdeps/linux/i386/clone.S:106
>>
>> The crash happens in different parts of the application but it is always a
>> malloc crash.
>>
>>
>> Regards,
>>
>> --
>> Sergio M. Ammirata, Ph.D.
>>
>>
>>
>> On 11/24/09 2:16 AM, "Freeman Wang" <xwang@...> wrote:
>>
>>> Mike
>>>
>>> An example may be better to show what we thought.
>>>
>>> Say, we already have a mmb list of three blocks M1 --> M2 --> M3. Now a
>>> heap request comes in for an 8k buffer. The heap is extended using mmap
>>> and we iterate through the list and find the new block descriptor,
>>> new_mmb, should be added after M3. *** Now we try to allocate new_mmb
>>> from the mmb_heap and find mmb_heap needs to be extended too *** So a
>>> new mmap syscall is made to extend the mmb_heap, and again the new block
>>> needs a descriptor also from the mmb_heap. Again we iterated through the
>>> existing list, and find this new_mmb_2 should be added after M3 too !!!.
>>> We then try to allocate new_mmb_2 and it should succeed because the mmap
>>> usually gives us at least a page and it has been added to the mmb_heap.
>>> When the allocation of the first new_mmb returns, the list has already
>>> been updated to M1 --> M2 --> M3 --> M4_2, but we do not know, so M4_1
>>> will be still added after M3.
>>>
>>> That's just one of the possible ways the current code could mess up.
>>> Depending on where the two blocks are located, things could go wild and
>>> the link list be totally destroyed. However, if we make the allocation
>>> before going through the mmb list, we will be able to make sure the
>>> new_mmb structure is added properly.
>>>
>>> Freeman
>>>
>>> -----Original Message-----
>>> From: Mike Frysinger [mailto:vapier@...]
>>> Sent: Monday, November 23, 2009 7:42 PM
>>> To: uclibc@...
>>> Cc: Freeman Wang
>>> Subject: Re: bugs in malloc
>>>
>>> On Monday 23 November 2009 14:55:26 Freeman Wang wrote:
>>>> 1. We found with some special application, the application would get
>>>> stuck at line 162 of malloc.c and the reason was mem->next points back
>>>
>>>> to itself.
>>>
>>> please try to reduce the allocation patterns of your 'special'
>>> application.
>>> it should be easy to enable debugging and capture the malloc/free
>>> sequences and run them again manually.
>>>
>>>> It turns out, we believe, to be because new_mmb is allocated after the
>>>
>>>> mmb list is iterated throught to find the insertion point. When the
>>>> mmb_heap also runs out and needs to be extended when the regular heap
>>>> is just extended, the mmb list could be messed up. We moved the
>>>> new_mmb allocation up and the problem seems to have been fixed.
>>>
>>> i dont see why the current code is a problem. it's a singly linked list
>>> which means if the list is walked to the end, the new_mmb will be
>>> 'inserted' as the last item in the linked list. prev_mmb points to the
>>> last valid entry in the list and mmb is null. so the last valid entry
>>> will be updated to point to new_mmb and it will have its next member set
>>> to null. i dont see any place where the mmb list 'could be messed up'.
>>>
>>> if you look a few lines up, the recursive memory-full-issue should
>>> already be handled because a mmap for more memory is done, and that mmap
>>> is put into the heap by the heap free call.
>>>
>>>> 2. While trying to fix the above issue, we read the code and found a
>>>> multi-threading issue with this mmb list handling. Th'is list is
>>>> halfway protected in free.c and not protected by any lock at all in
>>>> malloc.c. Is it intentional?
>>>
>>> looks like the locking fixes we have in the blackfin tree werent pushed
>>> upstream. i'll have to rebase them first, but it should at least
>>> partially cover what you see. if it doesnt, i'll stitch in your pieces.
>>>
>>>> 3. In an embedded world without MMU, it is not garanteed that the mmap
>>>
>>>> syscall would always get back a valid block, and that's probably why
>>>> the return value, block, is checked immediately after the syscall. But
>>>
>>>> it seems we are not checking the return value of new_mmb which is
>>>> allocated from the mmb_heap? Is it a potential issue?
>>>
>>> you have no guarantee of mmap returning valid memory under a mmu-system
>>> either. typically an oom situation will have an application crash
>>> quickly, so this particular missing check isnt a big deal, but it should
>>> probably still be added. i imagine in a threaded situation, one thread
>>> could grab the fresh memory before the original thread got a chance to
>>> use it and thus got null back.
>>> -mike
>>> _______________________________________________
>>> uClibc mailing list
>>> uClibc@...
>>> http://lists.busybox.net/mailman/listinfo/uclibc
>>
>>
>> _______________________________________________
>> uClibc mailing list
>> uClibc@...
>> http://lists.busybox.net/mailman/listinfo/uclibc

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-28T12:44:02Z

On Sat, Nov 28, 2009 at 1:29 AM, Rob Landley <rob@...> wrote:

> On Saturday 28 November 2009 01:06:30 Kevin Day wrote:
>> On Fri, Nov 27, 2009 at 2:45 PM, Rob Landley <rob@...> wrote:
>> > On Friday 27 November 2009 11:45:50 Kevin Day wrote:
>> >> I was looking at uClibc 0.9.28.3 to try and apply this patch and
>> >> noticed:
>> >>
>> >> At the very end of your patch, the untouched code only has
>> >> free(packet); while 0.9.28.3 has:
>> >> if (packet)
>> >> free(packet);
>> >>
>> >> Does anybody know why was this safety check removed?
>> >
>> > From the Single Unix Specification version 4 (I.E. SUSv4, I.E. POSIX
>> > 2008):
>> >
>> > http://www.opengroup.org/onlinepubs/9699919799/functions/free.html
>> >
>> > > If ptr is a null pointer, no action shall occur.
>> >
>> > I.E. free() has a null check built-in, as required by POSIX.
>> >
>> > Rob
>> > --
>> > Latency is more important than throughput. It's that simple. - Linus
>> > Torvalds
>>
>> So you are saying a double-free cannot happen here?
>
> I'm saying that freeing a NULL pointer is a NOP, so testing for NULL before
> calling free() is a waste of bytes.
>
> What does a double-free have to do with this? If the pointer is NULL, then
> there's nothing to free. If the pointer isn't NULL, the test isn't relevant.
>
> Legal (and pointless) code:
>
> void does_nothing(void)
> {
> x=NULL;
>
> free(x);
> free(x);
> free(x);
> }
>
> Rob
> --
> Latency is more important than throughput. It's that simple. - Linus Torvalds
>

Don't worry, that part is not being misunderstood.
What I was saying is that:

x = malloc(sizeof(int));
free(x);
free(x); <-- bad

the fact that somebody was doing a test to see if the pointer was NULL
before freeing it suggested to me that somebody with the older uClibc
version believed a double free would be possible at this point in the
code.

Seeing the if(x)'s removed triggered my habits and I forgot (because I
drilled the some habits into myself) that your free's do not set x to
NULL after freeing it.

Your previous post already defined that the if (pointer) was being
removed to save space as it is safe to do so.
Once I realized that I had my habits being applied to my thought
process, I realized that my statement was not relevant.
Thus my immediate second post stating at the start "Never mind.."

And for the record, I precede my free's with if (x) to avoid extra
function calls as I suspect doing an if () test is resourcefully
cheaper than doing a function call. Though I never bothered to try and
prove it..
However, this is uClibc and one of your goals is to save binary space.
This is why I didn't bother continuing the discussion on the if () part.
Again, I forgot this because I had drilled these habits into myself.
It was simply me forgetting why I did something and reacting instinctively.

And so I try to conclude again with, never mind.

--
Kevin Day
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T23:29:37Z

On Saturday 28 November 2009 01:06:30 Kevin Day wrote:

> On Fri, Nov 27, 2009 at 2:45 PM, Rob Landley <rob@...> wrote:
> > On Friday 27 November 2009 11:45:50 Kevin Day wrote:
> >> I was looking at uClibc 0.9.28.3 to try and apply this patch and
> >> noticed:
> >>
> >> At the very end of your patch, the untouched code only has
> >> free(packet); while 0.9.28.3 has:
> >> if (packet)
> >> free(packet);
> >>
> >> Does anybody know why was this safety check removed?
> >
> > From the Single Unix Specification version 4 (I.E. SUSv4, I.E. POSIX
> > 2008):
> >
> > http://www.opengroup.org/onlinepubs/9699919799/functions/free.html
> >
> > > If ptr is a null pointer, no action shall occur.
> >
> > I.E. free() has a null check built-in, as required by POSIX.
> >
> > Rob
> > --
> > Latency is more important than throughput. It's that simple. - Linus
> > Torvalds
>
> So you are saying a double-free cannot happen here?

I'm saying that freeing a NULL pointer is a NOP, so testing for NULL before
calling free() is a waste of bytes.

What does a double-free have to do with this? If the pointer is NULL, then
there's nothing to free. If the pointer isn't NULL, the test isn't relevant.

Legal (and pointless) code:

void does_nothing(void)
{
x=NULL;

free(x);
free(x);
free(x);
}

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T23:19:58Z

On Sat, Nov 28, 2009 at 1:06 AM, Kevin Day <thekevinday@...> wrote:

> On Fri, Nov 27, 2009 at 2:45 PM, Rob Landley <rob@...> wrote:
>> On Friday 27 November 2009 11:45:50 Kevin Day wrote:
>>> I was looking at uClibc 0.9.28.3 to try and apply this patch and noticed:
>>>
>>> At the very end of your patch, the untouched code only has
>>> free(packet); while 0.9.28.3 has:
>>> if (packet)
>>> free(packet);
>>>
>>> Does anybody know why was this safety check removed?
>>
>> From the Single Unix Specification version 4 (I.E. SUSv4, I.E. POSIX 2008):
>>
>> http://www.opengroup.org/onlinepubs/9699919799/functions/free.html
>>
>> > If ptr is a null pointer, no action shall occur.
>>
>> I.E. free() has a null check built-in, as required by POSIX.
>>
>> Rob
>> --
>> Latency is more important than throughput. It's that simple. - Linus Torvalds
>>
>
> So you are saying a double-free cannot happen here?
>
> --
> Kevin Day
>

Never mind, I just remember that I have habits and practices that I
have engraved into myself such that I forget the internal details
sometimes.

I generally have a free(..) wrapper that frees the pointer and then
sets the pointer to null so that the double free doesn't happen. And
then out of what I would call paranoia practice I always wrap them in
if (pointer) anyway.

So my concern was if those pointers were freed already and if they
were being set to NULL after they were being freed to prevent double
frees.

Sorry for the double post, it just popped into my mind after I hit the
send button.

--
Kevin Day
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T23:06:30Z

On Fri, Nov 27, 2009 at 2:45 PM, Rob Landley <rob@...> wrote:

> On Friday 27 November 2009 11:45:50 Kevin Day wrote:
>> I was looking at uClibc 0.9.28.3 to try and apply this patch and noticed:
>>
>> At the very end of your patch, the untouched code only has
>> free(packet); while 0.9.28.3 has:
>> if (packet)
>> free(packet);
>>
>> Does anybody know why was this safety check removed?
>
> From the Single Unix Specification version 4 (I.E. SUSv4, I.E. POSIX 2008):
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/free.html
>
> > If ptr is a null pointer, no action shall occur.
>
> I.E. free() has a null check built-in, as required by POSIX.
>
> Rob
> --
> Latency is more important than throughput. It's that simple. - Linus Torvalds
>

So you are saying a double-free cannot happen here?

--
Kevin Day
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T12:45:49Z

On Friday 27 November 2009 11:45:50 Kevin Day wrote:
> I was looking at uClibc 0.9.28.3 to try and apply this patch and noticed:
>
> At the very end of your patch, the untouched code only has
> free(packet); while 0.9.28.3 has:
> if (packet)
> free(packet);
>
> Does anybody know why was this safety check removed?

>From the Single Unix Specification version 4 (I.E. SUSv4, I.E. POSIX 2008):

http://www.opengroup.org/onlinepubs/9699919799/functions/free.html

> If ptr is a null pointer, no action shall occur.

I.E. free() has a null check built-in, as required by POSIX.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0/3] Fixes for hardened/nptl

2009-11-27T10:14:13Z

On 11/27/2009 08:12 AM, Natanael Copa wrote:
> Various fixes to make nptl work on hardened toolchain. Tested with simple
> pthreaded hello world.
>
> Those are for nptl branch.

Thanks! Applied.

-Austin
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T10:05:08Z

On 11/27/09, Kevin Day <thekevinday@...> wrote:
...
> At the very end of your patch, the untouched code only has
> free(packet); while 0.9.28.3 has:
> if (packet)
> free(packet);
>
> Does anybody know why was this safety check removed?

Explained in the commit message:

http://git.uclibc.org/uClibc/commit/?id=9e5250dae08a1601c3c7c82d9128613d7c22dd84

--
Natanael Copa
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T10:04:05Z

>
> On Fri, Nov 27, 2009 at 7:10 AM, Natanael Copa <natanael.copa@...> wrote:
> > On Fri, 2009-11-27 at 12:31 +0000, Natanael Copa wrote:
> >> This fixes an issue when a CNAME was returned for an A query.
> >> Garbage was returned.
> >>
> >> Postfix was affected of this.
> >
> > FWIW, this patch is also a candidate for 0_9_30 tree.
> >
> > -nc
> >
>
> I was looking at uClibc 0.9.28.3 to try and apply this patch and noticed:
>
> At the very end of your patch, the untouched code only has
> free(packet); while 0.9.28.3 has:
> if (packet)
> free(packet);
>
> Does anybody know why was this safety check removed?
>
> Looking at the top portion of both your patch (again at the untouched
> code portion of the patch) and 0.9.28.3 code, they are both calling
> free(a.dotted); without checking it as well.
> Is there a reason for not doing this?
> I am imagining segfaults here if the memory does not get allocated.
>
> If you are talking about saving space by not using the "if (pointer)
> free(pointer)" practice, isn't this optimized away by gcc's
> delete-null-pointer-checks flag for the cases where it IS safe to
> remove?

free(NULL) is a NOP and it is required to be. Checking
for NULL before free() is a waste. Just do man 3 free

Jocke

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T09:45:50Z

On Fri, Nov 27, 2009 at 7:10 AM, Natanael Copa <natanael.copa@...> wrote:

> On Fri, 2009-11-27 at 12:31 +0000, Natanael Copa wrote:
>> This fixes an issue when a CNAME was returned for an A query.
>> Garbage was returned.
>>
>> Postfix was affected of this.
>
> FWIW, this patch is also a candidate for 0_9_30 tree.
>
> -nc
>

I was looking at uClibc 0.9.28.3 to try and apply this patch and noticed:

At the very end of your patch, the untouched code only has
free(packet); while 0.9.28.3 has:
if (packet)
free(packet);

Does anybody know why was this safety check removed?

Looking at the top portion of both your patch (again at the untouched
code portion of the patch) and 0.9.28.3 code, they are both calling
free(a.dotted); without checking it as well.
Is there a reason for not doing this?
I am imagining segfaults here if the memory does not get allocated.

If you are talking about saving space by not using the "if (pointer)
free(pointer)" practice, isn't this optimized away by gcc's
delete-null-pointer-checks flag for the cases where it IS safe to
remove?

--
Kevin Day
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 3/3] PIC fixes for hardened

2009-11-27T08:12:44Z

From: Timo Teräs <timo.teras@...>

Signed-off-by: Natanael Copa <natanael.copa@...>
---
libpthread/nptl/sysdeps/pthread/Makefile.in | 4 ++--
.../sysdeps/unix/sysv/linux/i386/Makefile.arch | 7 ++++---
.../sysdeps/unix/sysv/linux/i386/lowlevellock.h | 6 ++++--
3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/libpthread/nptl/sysdeps/pthread/Makefile.in b/libpthread/nptl/sysdeps/pthread/Makefile.in
index 2a82532..4524015 100644
--- a/libpthread/nptl/sysdeps/pthread/Makefile.in
+++ b/libpthread/nptl/sysdeps/pthread/Makefile.in
@@ -23,8 +23,8 @@ libpthread_CSRC = pthread_barrier_wait.c pthread_cond_broadcast.c \

ifeq ($(TARGET_ARCH),i386)
X86_PTHREAD_EXCLUDE_LIST = pthread_spin_unlock.c pthread_spin_init.c \
- pthread_cond_wait.c pthread_barrier_wait.c pthread_cond_broadcast.c \
- pthread_cond_signal.c pthread_cond_timedwait.c pthread_rwlock_timedrdlock.c \
+ pthread_barrier_wait.c pthread_cond_broadcast.c \
+ pthread_cond_signal.c pthread_rwlock_timedrdlock.c \
pthread_rwlock_timedwrlock.c pthread_rwlock_unlock.c pthread_rwlock_wrlock.c \
pthread_rwlock_rdlock.c

diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/i386/Makefile.arch b/libpthread/nptl/sysdeps/unix/sysv/linux/i386/Makefile.arch
index 06c0bd8..740ee7f 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/i386/Makefile.arch
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/i386/Makefile.arch
@@ -15,9 +15,10 @@ libc_a_CSRC = fork.c
libc_a_SSRC = clone.S vfork.S

libpthread_SSRC += i486/lowlevellock.S i486/pthread_barrier_wait.S i486/pthread_cond_signal.S i486/pthread_cond_broadcast.S \
- i486/pthread_cond_timedwait.S i486/pthread_cond_wait.S i486/sem_post.S i486/sem_timedwait.S \
- i486/sem_trywait.S i486/sem_wait.S i486/pthread_rwlock_rdlock.S i486/pthread_rwlock_wrlock.S \
- i486/pthread_rwlock_timedrdlock.S i486/pthread_rwlock_timedwrlock.S i486/pthread_rwlock_unlock.S
+ i486/sem_post.S i486/sem_timedwait.S \
+ i486/sem_trywait.S i486/sem_wait.S i486/pthread_rwlock_rdlock.S i486/pthread_rwlock_wrlock.S \
+ i486/pthread_rwlock_timedrdlock.S i486/pthread_rwlock_timedwrlock.S i486/pthread_rwlock_unlock.S
+#i486/pthread_cond_timedwait.S i486/pthread_cond_wait.S

libc_a_SSRC += i486/libc-lowlevellock.S

diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h b/libpthread/nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h
index 785f2ac..1a060c0 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h
@@ -65,8 +65,10 @@ typedef int lll_lock_t;
/* Delay in spinlock loop. */
#define BUSY_WAIT_NOP __asm__ ("rep; nop")

-
#define lll_futex_wait(futex, val) \
+ lll_futex_timed_wait (futex, val, NULL)
+
+#define lll_futex_timed_wait(futex, val, timeout) \
({ \
int __ret; \
register __typeof (val) _val __asm__ ("edx") = (val); \
@@ -74,7 +76,7 @@ typedef int lll_lock_t;
LLL_ENTER_KERNEL \
LLL_EBX_LOAD \
: "=a" (__ret) \
- : "0" (SYS_futex), LLL_EBX_REG (futex), "S" (0), \
+ : "0" (SYS_futex), LLL_EBX_REG (futex), "S" (timeout), \
"c" (FUTEX_WAIT), "d" (_val), \
"i" (offsetof (tcbhead_t, sysinfo))); \
__ret; })
--
1.6.5.3

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 2/3] define local stack_chk_guard for nptl

2009-11-27T08:12:43Z

Signed-off-by: Natanael Copa <natanael.copa@...>
---
libc/misc/internals/__uClibc_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/libc/misc/internals/__uClibc_main.c b/libc/misc/internals/__uClibc_main.c
index 85dbe71..cb2c6ed 100644
--- a/libc/misc/internals/__uClibc_main.c
+++ b/libc/misc/internals/__uClibc_main.c
@@ -203,10 +203,11 @@ void __uClibc_init(void)
#ifndef SHARED
# ifdef __UCLIBC_HAS_SSP__
/* Set up the stack checker's canary. */
- stack_chk_guard = _dl_setup_stack_chk_guard();
# ifdef THREAD_SET_STACK_GUARD
+ uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard();
THREAD_SET_STACK_GUARD (stack_chk_guard);
# ifdef __UCLIBC_HAS_SSP_COMPAT__
+ stack_chk_guard = _dl_setup_stack_chk_guard();
__guard = stack_chk_guard;
# endif
# else
--
1.6.5.3

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 1/3] ldso: initialize stack_chk_guard after TLS is initialized

2009-11-27T08:12:42Z

stack_chk_guard is on thread local storage so we need to init TLS before
we can init stack_chk_guard.

Signed-off-by: Natanael Copa <natanael.copa@...>
---
ldso/ldso/ldso.c | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/ldso/ldso/ldso.c b/ldso/ldso/ldso.c
index 021f109..555eeb9 100644
--- a/ldso/ldso/ldso.c
+++ b/ldso/ldso/ldso.c
@@ -376,19 +376,6 @@ void _dl_get_ready_to_run(struct elf_resolve *tpnt, DL_LOADADDR_TYPE load_addr,
_dl_init_static_tls = &_dl_nothread_init_static_tls;
#endif

-#ifdef __UCLIBC_HAS_SSP__
- /* Set up the stack checker's canary. */
- stack_chk_guard = _dl_setup_stack_chk_guard ();
-# ifdef THREAD_SET_STACK_GUARD
- THREAD_SET_STACK_GUARD (stack_chk_guard);
-# ifdef __UCLIBC_HAS_SSP_COMPAT__
- __guard = stack_chk_guard;
-# endif
-# else
- __stack_chk_guard = stack_chk_guard;
-# endif
-#endif
-
/* At this point we are now free to examine the user application,
* and figure out which libraries are supposed to be called. Until
* we have this list, we will not be completely ready for dynamic
@@ -944,6 +931,19 @@ void _dl_get_ready_to_run(struct elf_resolve *tpnt, DL_LOADADDR_TYPE load_addr,
tcbp = init_tls ();
}
#endif
+#ifdef __UCLIBC_HAS_SSP__
+ /* Set up the stack checker's canary. */
+ stack_chk_guard = _dl_setup_stack_chk_guard ();
+# ifdef THREAD_SET_STACK_GUARD
+ THREAD_SET_STACK_GUARD (stack_chk_guard);
+# ifdef __UCLIBC_HAS_SSP_COMPAT__
+ __guard = stack_chk_guard;
+# endif
+# else
+ __stack_chk_guard = stack_chk_guard;
+# endif
+#endif
+

_dl_debug_early("Beginning relocation fixups\n");

--
1.6.5.3

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 0/3] Fixes for hardened/nptl

2009-11-27T08:12:41Z

Various fixes to make nptl work on hardened toolchain. Tested with simple
pthreaded hello world.

Those are for nptl branch.

Natanael Copa (2):
ldso: initialize stack_chk_guard after TLS is initialized
define local stack_chk_guard for nptl

Timo Teräs (1):
PIC fixes for hardened

ldso/ldso/ldso.c | 26 ++++++++++----------
libc/misc/internals/__uClibc_main.c | 3 +-
libpthread/nptl/sysdeps/pthread/Makefile.in | 4 +-
.../sysdeps/unix/sysv/linux/i386/Makefile.arch | 7 +++--
.../sysdeps/unix/sysv/linux/i386/lowlevellock.h | 6 +++-
5 files changed, 25 insertions(+), 21 deletions(-)

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 2/2] add hidden aliases for openat funcs

2009-11-27T06:38:29Z

From: Mike Frysinger <vapier@...>

openat64() uses openat(), so we need hidden aliases for it.

Signed-off-by: Mike Frysinger <vapier@...>
(cherry picked from commit fc0cc43885c69b3029d5783f3ce65ff53f8defe5)

Signed-off-by: Natanael Copa <natanael.copa@...>
---
include/fcntl.h | 2 ++
libc/sysdeps/linux/common/openat.c | 7 +++++++
libc/sysdeps/linux/common/openat64.c | 7 +++++++
3 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/include/fcntl.h b/include/fcntl.h
index 084ee8c..7ce3150 100644
--- a/include/fcntl.h
+++ b/include/fcntl.h
@@ -119,6 +119,7 @@ extern int open64 (__const char *__file, int __oflag, ...) __nonnull ((1));
# ifndef __USE_FILE_OFFSET64
extern int openat (int __fd, __const char *__file, int __oflag, ...)
__nonnull ((2));
+libc_hidden_proto(openat)
# else
# ifdef __REDIRECT
extern int __REDIRECT (openat, (int __fd, __const char *__file, int __oflag,
@@ -130,6 +131,7 @@ extern int __REDIRECT (openat, (int __fd, __const char *__file, int __oflag,

extern int openat64 (int __fd, __const char *__file, int __oflag, ...)
__nonnull ((2));
+libc_hidden_proto(openat64)
#endif

/* Create and open FILE, with mode MODE. This takes an `int' MODE
diff --git a/libc/sysdeps/linux/common/openat.c b/libc/sysdeps/linux/common/openat.c
index 33bd606..8380ec6 100644
--- a/libc/sysdeps/linux/common/openat.c
+++ b/libc/sysdeps/linux/common/openat.c
@@ -12,7 +12,14 @@
#undef openat

#ifdef __NR_openat
+/* The openat() prototype is varargs based, but we don't care about that
+ * here, so need to provide our own dedicated signature.
+ */
+extern int openat(int fd, const char *file, int oflag, mode_t mode);
+libc_hidden_proto(openat)
+
_syscall4(int, openat, int, fd, const char *, file, int, oflag, mode_t, mode)
+libc_hidden_def(openat)
#else
/* should add emulation with open() and /proc/self/fd/ ... */
#endif
diff --git a/libc/sysdeps/linux/common/openat64.c b/libc/sysdeps/linux/common/openat64.c
index 75711aa..06a5819 100644
--- a/libc/sysdeps/linux/common/openat64.c
+++ b/libc/sysdeps/linux/common/openat64.c
@@ -14,10 +14,17 @@
#ifdef __UCLIBC_HAS_LFS__

#ifdef __NR_openat
+/* The openat() prototype is varargs based, but we don't care about that
+ * here, so need to provide our own dedicated signature.
+ */
+extern int openat64(int fd, const char *file, int oflag, mode_t mode);
+libc_hidden_proto(openat64)
+
int openat64(int fd, const char *file, int oflag, mode_t mode)
{
return openat(fd, file, oflag | O_LARGEFILE, mode);
}
+libc_hidden_def(openat64)
#else
/* should add emulation with open() and /proc/self/fd/ ... */
#endif
--
1.6.5.3

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 0/2] *at funcs for 0_9_30 branch

2009-11-27T06:38:23Z

Hi,

I cherry-picked 2 commits for 0_9_30 branch that adds the *at funcs.

Mike Frysinger (2):
first pass at implementing *at funcs
add hidden aliases for openat funcs

include/dirent.h | 10 +++++-
include/fcntl.h | 17 ++++++---
include/features.h | 53 +++++++++++++++++++++------
include/stdio.h | 5 +++
include/sys/stat.h | 33 +++++++++++++----
include/sys/time.h | 2 +-
libc/misc/dirent/opendir.c | 63 +++++++++++++++++++++++++-------
libc/sysdeps/linux/common/faccessat.c | 16 ++++++++
libc/sysdeps/linux/common/fchmodat.c | 16 ++++++++
libc/sysdeps/linux/common/fchownat.c | 16 ++++++++
libc/sysdeps/linux/common/fstatat.c | 27 ++++++++++++++
libc/sysdeps/linux/common/fstatat64.c | 31 ++++++++++++++++
libc/sysdeps/linux/common/futimesat.c | 16 ++++++++
libc/sysdeps/linux/common/linkat.c | 16 ++++++++
libc/sysdeps/linux/common/mkdirat.c | 16 ++++++++
libc/sysdeps/linux/common/mkfifoat.c | 19 ++++++++++
libc/sysdeps/linux/common/mknodat.c | 25 +++++++++++++
libc/sysdeps/linux/common/openat.c | 25 +++++++++++++
libc/sysdeps/linux/common/openat64.c | 32 ++++++++++++++++
libc/sysdeps/linux/common/readlinkat.c | 16 ++++++++
libc/sysdeps/linux/common/renameat.c | 16 ++++++++
libc/sysdeps/linux/common/symlinkat.c | 16 ++++++++
libc/sysdeps/linux/common/unlinkat.c | 16 ++++++++
libc/sysdeps/linux/common/utimensat.c | 16 ++++++++
24 files changed, 478 insertions(+), 40 deletions(-)
create mode 100644 libc/sysdeps/linux/common/faccessat.c
create mode 100644 libc/sysdeps/linux/common/fchmodat.c
create mode 100644 libc/sysdeps/linux/common/fchownat.c
create mode 100644 libc/sysdeps/linux/common/fstatat.c
create mode 100644 libc/sysdeps/linux/common/fstatat64.c
create mode 100644 libc/sysdeps/linux/common/futimesat.c
create mode 100644 libc/sysdeps/linux/common/linkat.c
create mode 100644 libc/sysdeps/linux/common/mkdirat.c
create mode 100644 libc/sysdeps/linux/common/mkfifoat.c
create mode 100644 libc/sysdeps/linux/common/mknodat.c
create mode 100644 libc/sysdeps/linux/common/openat.c
create mode 100644 libc/sysdeps/linux/common/openat64.c
create mode 100644 libc/sysdeps/linux/common/readlinkat.c
create mode 100644 libc/sysdeps/linux/common/renameat.c
create mode 100644 libc/sysdeps/linux/common/symlinkat.c
create mode 100644 libc/sysdeps/linux/common/unlinkat.c
create mode 100644 libc/sysdeps/linux/common/utimensat.c

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T05:10:12Z

On Fri, 2009-11-27 at 12:31 +0000, Natanael Copa wrote:
> This fixes an issue when a CNAME was returned for an A query.
> Garbage was returned.
>
> Postfix was affected of this.

FWIW, this patch is also a candidate for 0_9_30 tree.

-nc

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] res_query: fix for CNAME responses on A queries.

2009-11-27T04:28:38Z

This fixes an issue when a CNAME was returned for an A query.
Garbage was returned.

Postfix was affected of this.

Signed-off-by: Natanael Copa <natanael.copa@...>
---
libc/inet/resolv.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c
index e6dac1a..0eb59f3 100644
--- a/libc/inet/resolv.c
+++ b/libc/inet/resolv.c
@@ -1604,11 +1604,10 @@ int res_query(const char *dname, int class, int type,

free(a.dotted);

- if (a.atype == type) { /* CNAME */
- if (i > anslen)
- i = anslen;
- memcpy(answer, packet, i);
- }
+ if (i > anslen)
+ i = anslen;
+ memcpy(answer, packet, i);
+
free(packet);
return i;
}
--
1.6.5.2

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Why __WORDSIZE_COMPAT32 is off for x86_64?

2009-11-26T14:28:58Z

On Thursday 26 November 2009 16:27, Bernhard Reutner-Fischer wrote:

> On Thu, Nov 26, 2009 at 01:49:51PM +0100, Denys Vlasenko wrote:
> >libc/sysdeps/linux/x86_64/bits/wordsize.h:
> >
> >/* Determine the wordsize from the preprocessor defines. */
> >
> >#if defined __x86_64__
> ># define __WORDSIZE 64
> >/*# define __WORDSIZE_COMPAT32 1*/
> >#else
> ># define __WORDSIZE 32
> >#endif
> >
> >This breaks /var/run/utmp format.
> >This makes any tool which uses /var/run/utmp to misbehave
> >on a system where some other parts are based on glibc:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=541587
> >
> >Whoever commented it out forgot to explain *why*
> >he commented it out. I propose uncommenting it.
> >
> >Please ACK or apply attached patch.

Pushed to git
--
vda
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: bugs in malloc

2009-11-26T10:34:15Z

Hi,

it might also be a mutex/threads issue, I know of a bug introduced somewhere between 0.9.28 and 0.9.28.2 iirc, it is in uClibc_mutex.h. One of the macros does not check for a case = NULL, I reported this to the committer and the maintainer at that time. To test if I am right, replace __UCLIBC_MUTEX_CONDITIONAL_LOCK(M,C) and UNLOCK with their counterparts
__UCLIBC_MUTEX_[UN]LOCK_CANCEL_UNSAFE(M), rebuild uClibc and then your app.

Peter

-------- Original-Nachricht --------
> Datum: Tue, 24 Nov 2009 07:14:36 -0500
> Von: "Sergio M. Ammirata, Ph.D." <sergio@...>
> An: Freeman Wang <xwang@...>, Mike Frysinger <vapier@...>, uclibc@...
> Betreff: Re: bugs in malloc

> If it helps, I am also experiences crashes in malloc. They did not occur
> in
> 0.9.28. Here is a sample backtrace:
>
> Program terminated with signal 11, Segmentation fault.
> [New process 1788]
> [New process 1752]
> [New process 1784]
> [New process 1783]
> [New process 1789]
> [New process 1791]
> [New process 1787]
> [New process 1785]
> [New process 1786]
> #0 0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
> heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
> 184 mem = MALLOC_SETUP (mem, size);
> (gdb) bt
> #0 0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
> heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
> #1 0x3782e53c in malloc (size=506912) at libc/stdlib/malloc/malloc.c:223
> #2 0x3782eb10 in memalign (alignment=16, size=506880) at
> libc/stdlib/malloc/memalign.c:48
> #3 0x08083fd1 in __vout_AllocatePicture (p_this=0x8d74f6c,
> p_pic=0x9a1a048,
> i_chroma=808596553, i_width=704, i_height=480, i_aspect=576000) at
> video_output/vout_pictures.c:515
> #4 0x373bdacf in video_new_buffer (p_this=0x8d74f6c, pp_ring=0x8893868,
> p_sys=0x8885680) at transcode.c:2499
> #5 0x08144ed4 in DecodeBlock (p_dec=0x8d74f6c, pp_block=0x3efff89c) at
> libmpeg2.c:604
> #6 0x373c026d in Send (p_stream=0x887f6c8, id=0x8892bf8,
> p_buffer=0xcf0bec0) at transcode.c:2030
> #7 0x373e00a6 in Send (p_stream=0x887e32c, id=0x8892bd0,
> p_buffer=0xcf0bec0) at duplicate.c:277
> #8 0x0809182c in sout_InputSendBuffer (p_input=0x8892bc0,
> p_buffer=0xcf0bec0) at stream_output/stream_output.c:279
> #9 0x080d31e8 in DecoderDecode (p_dec=0x88a91bc, p_block=0xd232f28) at
> input/decoder.c:579
> #10 0x080d70ac in EsOutSend (out=0x887b21c, es=0x88a6e08,
> p_block=0xd232f28)
> at input/es_out.c:1107
> #11 0x080ffed9 in ParsePES (p_demux=0x8890c64, pid=0x999cf10) at
> ../../include/vlc_es_out.h:109
> #12 0x08101a58 in Demux (p_demux=0x8890c64) at ts.c:1927
> #13 0x08073a6f in MainLoop (p_input=0x8882170) at input/input.c:538
> #14 0x08074b17 in Run (p_input=0x8882170) at input/input.c:444
> #15 0x378b3136 in pthread_start_thread (arg=0x3efffea0) at
> libpthread/linuxthreads.old/manager.c:309
> #16 0x377c2c12 in clone () at libc/sysdeps/linux/i386/clone.S:106
>
> The crash happens in different parts of the application but it is always a
> malloc crash.
>
>
> Regards,
>
> --
> Sergio M. Ammirata, Ph.D.
>
>
>
> On 11/24/09 2:16 AM, "Freeman Wang" <xwang@...> wrote:
>
> > Mike
> >
> > An example may be better to show what we thought.
> >
> > Say, we already have a mmb list of three blocks M1 --> M2 --> M3. Now a
> > heap request comes in for an 8k buffer. The heap is extended using mmap
> > and we iterate through the list and find the new block descriptor,
> > new_mmb, should be added after M3. *** Now we try to allocate new_mmb
> > from the mmb_heap and find mmb_heap needs to be extended too *** So a
> > new mmap syscall is made to extend the mmb_heap, and again the new block
> > needs a descriptor also from the mmb_heap. Again we iterated through the
> > existing list, and find this new_mmb_2 should be added after M3 too !!!.
> > We then try to allocate new_mmb_2 and it should succeed because the mmap
> > usually gives us at least a page and it has been added to the mmb_heap.
> > When the allocation of the first new_mmb returns, the list has already
> > been updated to M1 --> M2 --> M3 --> M4_2, but we do not know, so M4_1
> > will be still added after M3.
> >
> > That's just one of the possible ways the current code could mess up.
> > Depending on where the two blocks are located, things could go wild and
> > the link list be totally destroyed. However, if we make the allocation
> > before going through the mmb list, we will be able to make sure the
> > new_mmb structure is added properly.
> >
> > Freeman
> >
> > -----Original Message-----
> > From: Mike Frysinger [mailto:vapier@...]
> > Sent: Monday, November 23, 2009 7:42 PM
> > To: uclibc@...
> > Cc: Freeman Wang
> > Subject: Re: bugs in malloc
> >
> > On Monday 23 November 2009 14:55:26 Freeman Wang wrote:
> >> 1. We found with some special application, the application would get
> >> stuck at line 162 of malloc.c and the reason was mem->next points back
> >
> >> to itself.
> >
> > please try to reduce the allocation patterns of your 'special'
> > application.
> > it should be easy to enable debugging and capture the malloc/free
> > sequences and run them again manually.
> >
> >> It turns out, we believe, to be because new_mmb is allocated after the
> >
> >> mmb list is iterated throught to find the insertion point. When the
> >> mmb_heap also runs out and needs to be extended when the regular heap
> >> is just extended, the mmb list could be messed up. We moved the
> >> new_mmb allocation up and the problem seems to have been fixed.
> >
> > i dont see why the current code is a problem. it's a singly linked list
> > which means if the list is walked to the end, the new_mmb will be
> > 'inserted' as the last item in the linked list. prev_mmb points to the
> > last valid entry in the list and mmb is null. so the last valid entry
> > will be updated to point to new_mmb and it will have its next member set
> > to null. i dont see any place where the mmb list 'could be messed up'.
> >
> > if you look a few lines up, the recursive memory-full-issue should
> > already be handled because a mmap for more memory is done, and that mmap
> > is put into the heap by the heap free call.
> >
> >> 2. While trying to fix the above issue, we read the code and found a
> >> multi-threading issue with this mmb list handling. Th'is list is
> >> halfway protected in free.c and not protected by any lock at all in
> >> malloc.c. Is it intentional?
> >
> > looks like the locking fixes we have in the blackfin tree werent pushed
> > upstream. i'll have to rebase them first, but it should at least
> > partially cover what you see. if it doesnt, i'll stitch in your pieces.
> >
> >> 3. In an embedded world without MMU, it is not garanteed that the mmap
> >
> >> syscall would always get back a valid block, and that's probably why
> >> the return value, block, is checked immediately after the syscall. But
> >
> >> it seems we are not checking the return value of new_mmb which is
> >> allocated from the mmb_heap? Is it a potential issue?
> >
> > you have no guarantee of mmap returning valid memory under a mmu-system
> > either. typically an oom situation will have an application crash
> > quickly, so this particular missing check isnt a big deal, but it should
> > probably still be added. i imagine in a threaded situation, one thread
> > could grab the fresh memory before the original thread got a chance to
> > use it and thus got null back.
> > -mike
> > _______________________________________________
> > uClibc mailing list
> > uClibc@...
> > http://lists.busybox.net/mailman/listinfo/uclibc
>
>
> _______________________________________________
> uClibc mailing list
> uClibc@...
> http://lists.busybox.net/mailman/listinfo/uclibc

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Why __WORDSIZE_COMPAT32 is off for x86_64?

2009-11-26T07:26:07Z

On Thu, Nov 26, 2009 at 01:49:51PM +0100, Denys Vlasenko wrote:

>libc/sysdeps/linux/x86_64/bits/wordsize.h:
>
>/* Determine the wordsize from the preprocessor defines. */
>
>#if defined __x86_64__
># define __WORDSIZE 64
>/*# define __WORDSIZE_COMPAT32 1*/
>#else
># define __WORDSIZE 32
>#endif
>
>This breaks /var/run/utmp format.
>This makes any tool which uses /var/run/utmp to misbehave
>on a system where some other parts are based on glibc:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=541587
>
>Whoever commented it out forgot to explain *why*
>he commented it out. I propose uncommenting it.
>
>Please ACK or apply attached patch.

ok.
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Why __WORDSIZE_COMPAT32 is off for x86_64?

2009-11-26T04:49:51Z

libc/sysdeps/linux/x86_64/bits/wordsize.h:

/* Determine the wordsize from the preprocessor defines. */

#if defined __x86_64__
# define __WORDSIZE 64
/*# define __WORDSIZE_COMPAT32 1*/
#else
# define __WORDSIZE 32
#endif

This breaks /var/run/utmp format.
This makes any tool which uses /var/run/utmp to misbehave
on a system where some other parts are based on glibc:

https://bugzilla.redhat.com/show_bug.cgi?id=541587

Whoever commented it out forgot to explain *why*
he commented it out. I propose uncommenting it.

Please ACK or apply attached patch.
--
vda

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

6.patch (738 bytes) Download Attachment

Re: Building busybox against nptl branch failed.

2009-11-25T01:39:05Z

On Wednesday 25 November 2009 02:31:01 Bernhard Reutner-Fischer wrote:
> I have a patch pending, will commit it shortly.

Cool. Thanks.

I patched it locally, which revealed this bug:

libbb/lib.a(xfuncs.o): In function `close_on_exec_on':
xfuncs.c:(.text.close_on_exec_on+0xd): undefined reference to `fcntl64'
libbb/lib.a(xfuncs.o): In function `ndelay_off':
xfuncs.c:(.text.ndelay_off+0xb): undefined reference to `fcntl64'
xfuncs.c:(.text.ndelay_off+0x1f): undefined reference to `fcntl64'
libbb/lib.a(xfuncs.o): In function `ndelay_on':
xfuncs.c:(.text.ndelay_on+0xb): undefined reference to `fcntl64'
xfuncs.c:(.text.ndelay_on+0x1f): undefined reference to `fcntl64'

Although I don't understand how that worked in 0.9.30.1. (In
libc/sysdeps/linux/common there's several instances of libc_hidden_proto(),
libc_hidden_weak(), and libc_hidden_def(), plus both __libc_fcntl64 and
fcntl64... Too tired to try to unravel this tonight, I think. Bedtime.)

Possibly this one needs a new config symbol that 0.9.30.1 didn't? I've already
got "UCLIBC_SUSV4_LEGACY=y" added to the .config...

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Building busybox against nptl branch failed.

2009-11-25T00:31:01Z

I have a patch pending, will commit it shortly.

On 25 Nov 2009 09:14, "Rob Landley" <rob@...> wrote:

On Tuesday 24 November 2009 03:40:38 Rob Landley wrote: > On Tuesday 24
November 2009 03:37:11 Rob L...
So git bisect was useless (general wailing about the state of the tree is in
another message), but visual inspection and "git blame" turned up commit
a9e4475b stick "#if 0" guards around struct in6_pktinfo in
include/netinet/in.h.

I dunno if the relevant code used to actually work (I have no ipv6 test
cases), but it did used to compile. That commit stopped it from doing so.

Rob -- Latency is more important than throughput. It's that simple. - Linus
Torvalds

_______________________________________________ uClibc mailing list
uClibc@... http://lists.b...
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Building busybox against nptl branch failed.

2009-11-25T00:13:22Z

On Tuesday 24 November 2009 03:40:38 Rob Landley wrote:

> On Tuesday 24 November 2009 03:37:11 Rob Landley wrote:
> > libbb/udp_io.c: In function 'send_to_from':
> > libbb/udp_io.c:42: error: invalid application of 'sizeof' to incomplete
> > type 'struct in6_pktinfo'
> > libbb/udp_io.c:87: error: invalid application of 'sizeof' to incomplete
> > type 'struct in6_pktinfo'
> > libbb/udp_io.c:90: error: dereferencing pointer to incomplete type
> > libbb/udp_io.c: In function 'recv_from_to':
> > libbb/udp_io.c:116: error: invalid application of 'sizeof' to incomplete
> > type 'struct in6_pktinfo'
> > libbb/udp_io.c:159: error: dereferencing pointer to incomplete type
> > make[1]: *** [libbb/udp_io.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> > Busybox 1.15.2, more or less defconfig, same config worked fine against
> > glibc and uClibc 0.9.30.1, failed with uClibc git 4d55daf5468b61c9 with
> > the above error.
> >
> > Rob
>
> Oh, the uClibc config in question is attached.
>
> I'm trying to get the non-nptl configs I have working before tackling nptl.
> This was an i686 build.

So git bisect was useless (general wailing about the state of the tree is in
another message), but visual inspection and "git blame" turned up commit
a9e4475b stick "#if 0" guards around struct in6_pktinfo in
include/netinet/in.h.

I dunno if the relevant code used to actually work (I have no ipv6 test
cases), but it did used to compile. That commit stopped it from doing so.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

People have actually been testing this?

2009-11-25T00:05:34Z

So I've been trying to bisect the bug I posted yesterday, where 'struct
in6_pktinfo' is an incomplete type (in the nptl branch, but not in the
0.9.30.1 release), and this breaks the busybox build.

While bisecting, I hit an "undefined NULL" over a larger range, which hid the
introduction of the bug I was looking for. So I bisected _that_ one to where
it was fixed at git 6d3ed00a41a948, and made a patch I could apply to earlier
versions.

Doing a fresh bisect to find the next bug masking the introduction of the one I
was looking for, I hit the "conflicting types for getline" bug. While looking
for where _that_ got fixed, I saw the bug where it tries to use fcntl64 and
can't find it, and the fun little bug where the ldconfig.c build dies with an
unexpected something before 'err'.

This is not "the occasional commit breaks the tree". The tree being broken is
not only the norm, but it tends to be broken for more than one reason at any
given time. So far, bisecting hasn't hit on a single commit since the last
release where the tree actually _did_ work.

I note that I'm actually testing the old threads, not nptl. This is pure
regression testing.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: author should be kept unchanged

2009-11-24T16:21:38Z

On 11/23/2009 10:37 PM, Carmelo AMOROSO wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Austin,
> unless there are changes due to merge, I think that "author" should be
> kept unchanged, instead that's fine/required to add teh signed-off of the
> committer as git policy requires.

Ah sorry about that. I really should have just cherry-picked like I
normally do.

-Austin
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: nptl branch going away, use nptl_merge

2009-11-24T16:18:21Z

On 11/23/2009 07:51 PM, Rob Landley wrote:

> On Sunday 22 November 2009 14:15:23 Austin Foxley wrote:
>> For my own sanity, I'm killing (renaming) the non master based nptl
>> branch. The difference of effort in keeping the two synced to master is
>> quite significant.
>>
>> For the master based nptl_merge, all I have to do is a
>> 'git merge origin/master' and fixup any conflicts. Done.
>
> Ooh, catching up on the non-cc: list emails, just made it to this thread. So
> pretty much you automatically get all the changes checked into "master", and
> we can now completely ignore "master" as a separate entity. Merge done, as
> far as I'm concerned.

No that's not what that means. What I did makes it easy for me to keep
the nptl branch and the master branch in sync.

-Austin
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Problem using net-snmp, Buildroot and uclibc

2009-11-24T08:22:25Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luca Altobelli wrote:

> Dear Sirs
> I'm using buildroot-2009.08 and I need net-snmp (currently I'm using
> version 5.4.2.1) installed on my target system. When compiling no
> problem encountered but, if I try to launch /snmpd/ on my target
> system, it gives the message "cannot find libc.so.6". I have libc.so.6
> on my host system, no trace of it on the target.
> Attached is my Buildroot and Uclibc configurations.
>
> Yours sincerely
> Altobelli Luca.
>

It's clearly a buildroot issue, so you are asking to the wrong list.
Anyway it seems that you are not using uClibc, instead you are
linking against glibc.

Ciao,
Carmelo

> _______________________________________________
> uClibc mailing list
> uClibc@...
> http://lists.busybox.net/mailman/listinfo/uclibc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAksMCEEACgkQoRq/3BrK1s9L2wCg8imTMGEtHUGjeQqoORmFiAJc
o0cAn20HXr03mK0DwbrfN46NoFsFM9Hm
=lS9Z
-----END PGP SIGNATURE-----
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc