Author: sthibault
Date: 2010-04-04 16:42:08 + (Sun, 04 Apr 2010)
New Revision: 4235
Added:
glibc-package/trunk/debian/patches/any/cvs-remove.diff
Removed:
glibc-package/trunk/debian/patches/any/submitted-remove.diff
Modified:
glibc-package/trunk/debian/changelog
Hi,
The current practise of scoping RFC 3484-addresses as site-local is
causing real operational problems on today's internet, and is
inhibiting the rollout of IPv6 on the content side:
Consider a setup where an end user has his computer on a LAN with RFC
1918-based private IPv4 addresses (using
Arrgh,
h̲e̲ strikes again. For some of the files, one thinks “w̲h̲i̲c̲h̲ licences”.
I for one don’t know who the authors of these are (they aren’t even
listed usually). Sorry, but I tried at least.
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much*
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible in the ordinary way)?
Yes.
By design that shouldn't happen: the idea behind COW
retitle 561203 threads and fork on machine with VIPT-WB cache
reassign 561203 linux-2.6
thanks
As I am sure that this bug lives in kernel, I do reassign and retitle.
--
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Processing commands for cont...@bugs.debian.org:
retitle 561203 threads and fork on machine with VIPT-WB cache
Bug #561203 [libc6] FTBFS [hppa] - pthread_create() (or QThread) + fork() =
crash
Changed Bug title to 'threads and fork on machine with VIPT-WB cache' from
'FTBFS [hppa] -
Package: libc6-prof
Version: 2.10.2-6
Severity: important
# cat a.c int main() { return 0; } # gcc -g -pg a.c -o a -static-libgcc -lc_p
# ./a Exit code 0 # gcc -g -pg a.c -o a -static-libgcc -lc_p -pthread # ./a
Segmentation fault (core dumped) # gdb ./a ./core [New Thread 9335]
warning:
7 matches
Mail list logo