arty@svn.reactos.com wrote:
Patch to fix NtCreateSempahore, in the case where the initial lookup succeeds. We previously left the function without initializing hSemaphore. Patch suggested by me and executed by hpoussin.
To me it looks totally wrong. First of all, the handle in my tests is never written if the function fails (just create a testcase where your application tries to create thousands of semaphore objects to reproduce it). Second of all you initialize the semaphore object only if creating it failed, as in you initialize a semaphore object on a NULL pointer. Third of all you insert a handle to the object no matter if you previously could create it, so you would end up creating a handle to a null-pointer.
The previous version I wrote just had one small bug, it checked if ObCreateObject failed to continue initialization and handle creation instead of checking if it succeeded. I'm going to revert this version of NtCreateSemaphore as it introduces even more bugs and adds behavior neither documented nor reproducable. I guess in case an application failed due to this function it was because of the fact that the function succeeded and didn't return a handle to a semaphore object even though one was created.
Best Regards Thomas
On Thu, 10 Feb 2005 10:18:05 +0100 Thomas Weidenmueller w3seek@reactos.com wrote:
The previous version I wrote just had one small bug, it checked if ObCreateObject failed to continue initialization and handle creation instead of checking if it succeeded. I'm going to revert this version of NtCreateSemaphore as it introduces even more bugs and adds behavior neither documented nor reproducable. I guess in case an application failed due to this function it was because of the fact that the function succeeded and didn't return a handle to a semaphore object even though one was created.
Well it is a bit unkind to make a new semaphore and not return the handle to it. Thanks for fixing it the right way.