I am using a Delphi Win32 custom DataAbstract+ROSDK server application. Because my client apps are Apple ecosystem I thought I’d try using Apple’s bonjour service.
If I use the Bonjour server type, I get this “break” command at shutdown when I run inside the debugger:
The actual outputdebugstring message is probably NOT coming from the FastMM debug heap:
Debug Output:
HEAP: Free Heap block 036712C0 modified at 036712F0 after it was freed
Unfortunately the address moves each time I run, and all I can see is that a pointer sized value that is set to the uninitialized heap area is being modified after it was freed, by being set to nil. From the call stack, it appears that the
problem is happening when the dnssd.dll is unloaded.
It appears that there may be either a bug in RemObjects SDK in the way it uses the Apple Bonjour Client DLL, or there may be a bug in the Bonjour client itself, at least on some Windows versions.
At shutdown, the crash above is occurring right when fTimer.free executes, in the TDAConnectionManager.Destroy method.
destructor TDAConnectionManager.Destroy;
begin
DriverManager := nil;
Incidentally, this heap corruption message and debugger breakpoint reproduces even in the provided RO SDK samples “BonjourDiscovery” project group, using Server.exe.
I am running this test on Windows 8, so it is possible that this problem might only manifest on Windows 8 and Windows Server 2012.
I have tested our Bonjour Discovery sample in Windows 8, Bonjour 2.0.2.0, DA 6.0.65.1057 - and have no problems that you described. Could you describe in more details your actions with our sample that give you error? Do you use sample server with another client?
Did you use 64 bit or 32 bit Windows 8? I am on Windows 8 Pro, 64 bit. This problem reproduces with the PCTrade sample server, and also with the SDK “Bonjour Discovery” program group (which has a client.exe and server.exe that simply demonstrate bonjour). Did you run server.dproj inside the delphi debugger? If not, you will not see the crashes, as they do not generate any user visible output.
Secondly, it seems that discovery features work on the first launch of the service or demo server exe, but not on the second launch, unless you do a NET STOP “Bonjour Service” from an elevated (admin) command prompt.
Although I thought I had properly configured the Windows firewall, I decided to turn it off, to see if my troubles become less severe. It seems that the Windows firewall causes some severe issues which are not black and white. In other words, instead of causing a complete and total failure of communications (the usual thing you would expect Windows Firewall to do), the Windows Firewall is simply wreaking havoc on Bonjour’s functionality.
A second fragile area of the system is that the RemObjects discovery code goes into a tailspin if the “Bonjour Server” service is stopped. I see hundreds of threads per second started and then immediately stopping, in the delphi debugger, if I stop the Bonjour Service after registering with Bonjour in my delphi custom server.
My main issue MIGHT just be the firewall. Don’t bother doing anything to try to reproduce this until I isolate this issue with the firewall off. SInce turning the firewall off, the service has now stayed up and running and visible via Bonjour for over 5 minutes, whereas before, it was working for about 1 minute, then going away.
Was there any more info or progress on this? I’m getting the exact same problem with no firewall active. Using Windows 7 x64, Delphi 2010 and the latest release of RO. As stated above, the problem happens using the supplied Bonjour demo and running the client in the IDE. Please advise.
I can confirm that my firewall is off. Unfortunately I’m only getting the error in my server application. I’ve tried creating a fresh DA server and client app and can’t get the error to appear.
For what it’s worth, my server application works fine without any errors, then I just drop a TROZeroConfRegistration component on my server data module, set the domain to “local.” and the server property to my TROSuperTCPServer then run the server again and, when I close the server application, I get the aforementioned HEAP debug error and the CPU window appears.
Aha, I have reproduced it. I’d forgotten to add the RegisterForZeroConf function call.
So, simply create a brand new RO server using the wizard. DA isn’t required, a basic RO SDK server is enough.
Now drop the TROZeroConfRegistration component on the fServerForm and set the domain and server properties accordingly. Now go into the NewService_Impl.pas file and uncomment out the provided RegisterForZeroConf function call.
Run the server, then close the form to shut it down and bang, the error appears, at least for me.
It does appear that the RegisterForZeroConf is the culprit or, more specifically, the “unregistration” isn’t working properly at shutdown.
I tried adding this immediately after the RegisterForZeroConf call:
(fClassFactory as IROClassFactory_ZeroConfig).UnregisterInterfaceName(’_NewService_rosdk._tcp.’);
i.e. unregister it immediately after registering. Not very useful I grant you but crucially the error doesn’t appear at all when I do this.
This suggests that the “unregistration” isn’t being done or is being done at the wrong time during shutdown. If I could find a way of calling this function to unregister it manually at a suitable point during server shutdown then I could work around the problem. The logical place would be the finalization section of the service but alas the error appears before this is run.
Is this actually an error, or a hard-coded breakpoint in DNSSD.dll? I just checked “Ignore non-user breakpoints” in Delphi’s debugger options and the issue went away for me.
Microsoft had a hard-coded breakpoint in ntdll.dll some time ago before Delphi had this option. We had to do in-memory patching to avoid the pain of Delphi IDE hitting that breakpoint.
BTW, you can get DNSSD 3.0.0.10 from the iTunes installer if you want to see if it helps… Just open the installer exe as a zip file to find the Bonjour MSI.