https://bugs.openldap.org/show_bug.cgi?id=10190
Issue ID: 10190 Summary: Stack space exhaustion on windows due to FD_SETSIZE Product: OpenLDAP Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: varunpatil@ucla.edu Target Milestone: ---
Setting FD_SETSIZE is only effective on Windows and BSD, and is currently set to an unreasonable default of 4096. Each fd_set is initialized with an array of file descriptors of this size; this allocates 8*4096 bytes on 64-bit machines, which quickly exhausts the small stack space on Windows.
This patch sets the default to a more reasonable value of 128; the default value on Windows currently is 64.
https://bugs.openldap.org/show_bug.cgi?id=10190
--- Comment #1 from varunpatil@ucla.edu --- Created attachment 1014 --> https://bugs.openldap.org/attachment.cgi?id=1014&action=edit Patch with fix
https://bugs.openldap.org/show_bug.cgi?id=10190
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu hyc@openldap.org --- No. Just compile with -DOPENLDAP_FD_SETSIZE=128 if that's what you want. Patches to change constants that are already redefinable at compile time will not be accepted.
https://bugs.openldap.org/show_bug.cgi?id=10190
--- Comment #3 from varunpatil@ucla.edu --- So you prefer to keep the build broken out of the box? Up to you ...
https://bugs.openldap.org/show_bug.cgi?id=10190
--- Comment #4 from varunpatil@ucla.edu ---
Patches to change constants that are already redefinable at compile time will not be accepted.
Why though? This seems like a very crappy policy.
This bug took a very long time to diagnose and I've no doubt others might run into it if they bothered to compile for Windows.
https://bugs.openldap.org/show_bug.cgi?id=10190
--- Comment #5 from Howard Chu hyc@openldap.org --- (In reply to varunpatil from comment #4)
Patches to change constants that are already redefinable at compile time will not be accepted.
Why though? This seems like a very crappy policy.
This bug took a very long time to diagnose and I've no doubt others might run into it if they bothered to compile for Windows.
What bug? You haven't identified any bug. OpenLDAP builds and runs fine on Windows, and the slapd server handles thousands of concurrent connections, same as when built on Linux. There is no bug here.
Changing the default as you have would cripple slapd built on Windows, and would be a significant backward-incompatible change. Allowing such changes would really be a crappy policy.
This ticket is closed.
https://bugs.openldap.org/show_bug.cgi?id=10190
--- Comment #6 from varunpatil@ucla.edu --- (In reply to Howard Chu from comment #5)
(In reply to varunpatil from comment #4)
Patches to change constants that are already redefinable at compile time will not be accepted.
Why though? This seems like a very crappy policy.
This bug took a very long time to diagnose and I've no doubt others might run into it if they bothered to compile for Windows.
What bug? You haven't identified any bug. OpenLDAP builds and runs fine on Windows, and the slapd server handles thousands of concurrent connections, same as when built on Linux. There is no bug here.
Did you even bother to read the description? I don't care if your slapd server handles millions of connections; fact is that a simple app using libldap can segfault under certain circumstances on Windows, and I consider this a bug.
Changing the default as you have would cripple slapd built on Windows, and would be a significant backward-incompatible change.
You're not even supposed to change FD_SETSIZE, and Linux uses 1024 regardless; so I wouldn't be so sure about the "crippling" you talk about. Perhaps it might have made sense to make it consistent to 1024 across platforms; 4096 allocates 64K memory on the stack for a single select call.
Allowing such changes would really be a crappy policy.
Your ego is leading you to miss the point. Your statement of "Patches to change constants that are already redefinable at compile time will not be accepted" is objectively crap. The whole point of having defaults is that they should be reasonable and so changing a default value is a perfectly valid change. You not agreeing with a different default and rejecting patches that change defaults outright are two completely different things.
This ticket is closed.
Umm okay? As an open source maintainer myself, I'm really liking your attitude towards people who want to contribute. Honestly I'd close it again if I could and never (try to) contribute again.
openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=10190
--- Comment #6 from varunpatil@ucla.edu --- (In reply to Howard Chu from comment #5)
(In reply to varunpatil from comment #4)
Patches to change constants that are already redefinable at compile time will not be accepted.
Why though? This seems like a very crappy policy.
This bug took a very long time to diagnose and I've no doubt others might run into it if they bothered to compile for Windows.
What bug? You haven't identified any bug. OpenLDAP builds and runs fine on Windows, and the slapd server handles thousands of concurrent connections, same as when built on Linux. There is no bug here.
Did you even bother to read the description? I don't care if your slapd server handles millions of connections; fact is that a simple app using libldap can segfault under certain circumstances on Windows, and I consider this a bug.
The code works as designed, and the smooth operation of millions of servers around the world is more important than the opinion of a single self-entitled ignorant prick.
It's not the 1980s, you can afford to set your program to use a stack larger than 64K.
https://bugs.openldap.org/show_bug.cgi?id=10190
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Keywords|needs_review |