reopen 673681
thanks
The fix + the workaround (of bug #673711) introduced in the eegdev_0.2-2
seems to fix only part of the problem, or the workaround was not enough.
The test suite on kfreebsd is now stuck. buildd's log:
> make[4]: Leaving directory
> `/build/buildd-eegdev_0.2-2-kfreebsd-i386-_
Hi
On 21/05/2012 01:21, Steven Chamberlain wrote:
> I find it interesting that this bug led to those glibc errors (double
> free or corruption) in #673681 instead of a hang or simple test failure.
Actually this bug does not cause the corruption in #673681: a race
condition in the unit tests is th
normally not report the bug since it seems already reported
upstream. However, I stumbled into this problem while I was trying to fix an
RC-bug (#673681) and according to the linked thread, there might be a small
patch that could fix the issue.
Thanks for considering the problem,
Cheers
Nicolas
Sorry for replying so late
On 08/02/2012 06:58, Benjamin Kaduk wrote:
> Perhaps freebsd-standa...@freebsd.org would be
> appropriate for this? Though perhaps -hackers would reach a larger
> audience.
I have dropped an email today in freebsd-standa...@freebsd.org:
http://lists.freebsd.org/piperma
On 04/02/2012 21:07, Robert Millan wrote:
> Can you reproduce this with upstream kernel? (apt-get install
> kfreebsd-downloader)
Yes it is reproducible with upstream kernel
> If it affects upstream, for this kind of reports it's much better to
> report them to FreeBSD PR database instead:
>
> ht
Source: kfreebsd-9
Severity: important
Tags: upstream
When a write() cannot transfer as many bytes as requested (because of a file
limit), it fails instead of transferring as many bytes as there is room to
write.
This is a violation of the POSIX standard:
http://pubs.opengroup.org/onlinepubs/0079
6 matches
Mail list logo
