Bug in Netscape Internet Service software
I spent almost a day on a "bug" appeared in my program, which is a very simple portscanner using non-blocking tcp connect. I closed all the sockets after they are used, but boundchecker still complains about "Outstanding Allocations", and the call path is "My Program->ws2_32.dll->sliplsp.dll". Actually I should pay more attention to sliplsp.dll, but at that moment, ws2_32.dll convinced me that the bug is in my program.
I opened windows task manager and noticed that the handle count keeps increasing. To see the details about the handle I launched Process Explorer, and found out there are lots of file handles named "\Device\WS2IFSL\NifsSct". What the hell is that?
Even google can not help, there is no useful discussion of NifsSct at all.
My program is quiet simple, but to be 100% sure, I started to use simple code to test, and found something interesting:
1. After socket() succeed, a new handle called "\Device\Afd\Endpoint" will be created.
2. After connect() succeed, a new handle called "\Device\Tcp" will be created.
3. After closesocket(), all of them will be closed.
But the problem is, "\Device\WS2IFSL\NifsSct" will be created along with the other two, and I have no idea what they are. Finally I had to give up after several hours of pointless efforts.
Then another day came. I want to solve another myth I saw: after reading tons of good words about Ruby on Rails, I want to give it a try myself, but the installation of rails("gem install rails") always deadlock ruby.exe. I was very disappointed about ruby at that moment, since there are source code at hand, I decided to find the "bug" and fix it.
Then my eyes opened: the debugger shows ruby.exe loads "C:\Programs Files\Netscape Internet Service\sliplsp.dll". Hah? I turned back to boundcheck, and enabled the full path in the view, it is the same dll!
I have had some bad experience before with programs hooked up with standard network stack. So I uninstalled Netscape Internet Service, deleted its folder after reboot, then everything goes fine. There is no more leaking \Device\WS2IFSL\NifsSct and I finally get rails installed.
There are not too much users in the world use Netscape Internet Service. It explains why there are no discussion about it at all.
I opened windows task manager and noticed that the handle count keeps increasing. To see the details about the handle I launched Process Explorer, and found out there are lots of file handles named "\Device\WS2IFSL\NifsSct". What the hell is that?
Even google can not help, there is no useful discussion of NifsSct at all.
My program is quiet simple, but to be 100% sure, I started to use simple code to test, and found something interesting:
1. After socket() succeed, a new handle called "\Device\Afd\Endpoint" will be created.
2. After connect() succeed, a new handle called "\Device\Tcp" will be created.
3. After closesocket(), all of them will be closed.
But the problem is, "\Device\WS2IFSL\NifsSct" will be created along with the other two, and I have no idea what they are. Finally I had to give up after several hours of pointless efforts.
Then another day came. I want to solve another myth I saw: after reading tons of good words about Ruby on Rails, I want to give it a try myself, but the installation of rails("gem install rails") always deadlock ruby.exe. I was very disappointed about ruby at that moment, since there are source code at hand, I decided to find the "bug" and fix it.
Then my eyes opened: the debugger shows ruby.exe loads "C:\Programs Files\Netscape Internet Service\sliplsp.dll". Hah? I turned back to boundcheck, and enabled the full path in the view, it is the same dll!
I have had some bad experience before with programs hooked up with standard network stack. So I uninstalled Netscape Internet Service, deleted its folder after reboot, then everything goes fine. There is no more leaking \Device\WS2IFSL\NifsSct and I finally get rails installed.
There are not too much users in the world use Netscape Internet Service. It explains why there are no discussion about it at all.
0 Comments:
Post a Comment
<< Home