https://bugs.kde.org/show_bug.cgi?id=471222
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #17 from Mark Wielaard ---
(In reply to Paul Floyd from comment #14)
> On second thoughts, isn't the fdleak_ipv4 double close message expected?
Yes, it is. It also failed for me locally. I added it to the
none/tests/fdleak_ipv4.stderr.exp
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #16 from Mark Wielaard ---
(In reply to Paul Floyd from comment #13)
> I had to modify double_close_range.c and socket_close.c like this
>
> #if defined(__linux__)
> #include
> #endif
>
> I get 3 new failures
>
> The first one has two
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #15 from Mark Wielaard ---
I needed the following on a system that didn't have close_range:
diff --git a/none/tests/Makefile.am b/none/tests/Makefile.am
index f56eb7faab67..a37bb27257a6 100644
--- a/none/tests/Makefile.am
+++
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #14 from Paul Floyd ---
On second thoughts, isn't the fdleak_ipv4 double close message expected?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #13 from Paul Floyd ---
I had to modify double_close_range.c and socket_close.c like this
#if defined(__linux__)
#include
#endif
I get 3 new failures
The first one has two things. Line number changes because of the Linux header.
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #12 from Paul Floyd ---
I'll test the new patch on FreeBSD tonight.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=471222
Alexandra Hajkova changed:
What|Removed |Added
Attachment #166151|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #10 from Paul Floyd ---
(In reply to Mark Wielaard from comment #7)
> I note that freebsd also has a closefrom syscall plus wrapper. But this
> doesn't seem to implement file descriptor tracking?
> It should probably use the newly
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #9 from Paul Floyd ---
> Shouldn't that be 0 instead of 1?
> Real CLOSE_RANGE_CLOEXEC is 4.
> What does 1 mean in this case?
Must have been my mistake it is definitely 4 (or 1<<2)
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #8 from Mark Wielaard ---
BTW. In that testcase memcheck/tests/freebsd/close_range.c it has:
/* It looks like close_range was initially implemented for FreeBSD 13
* but without CLOSE_RANGE_CLOEXEC
* That implementation got back ported to
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #7 from Mark Wielaard ---
I forgot about freebsd, sorry.
But I see the close_range wrappers are almost identical, so that is good.
We can adapt them together.
And freebsd already has ./memcheck/tests/freebsd/close_range.vgtest
Lets see if
https://bugs.kde.org/show_bug.cgi?id=471222
Alexandra Hajkova changed:
What|Removed |Added
Attachment #166140|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=471222
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #5 from Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=471222
Alexandra Hajkova changed:
What|Removed |Added
Attachment #166136|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #3 from Alexandra Hajkova ---
Submitting a patch:
[PATCH] syswrap-generic.c: Warn when file descriptor
is closed the second time.
Note that close_range is handled similar to closing each descriptor
individually. We might want to treat
https://bugs.kde.org/show_bug.cgi?id=471222
--- Comment #2 from Alexandra Hajkova ---
Created attachment 166136
--> https://bugs.kde.org/attachment.cgi?id=166136=edit
patch
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=471222
Mark Wielaard changed:
What|Removed |Added
CC||ahajk...@redhat.com,
|
18 matches
Mail list logo
