Hi *, I've been having some troubles with compression tests running on AppVeyor. Although I wasn't able to replicate that on my machine, it's not occasional there. Today I dug deep on AppVeyor and found something.
Basically when I send compressed data of op_attach request, the server closes connection without any error returned or error in the log. It's like I flush the buffer and boom the connection goes immediately to FIN, ACK from server side. It does not happen always at the same test being executed, but at least few times during the tests suite. The same op_attach data are sometimes fine and sometimes trigger the closing. Using the PDB version of Firebird didn't throw any assert etc. It's *always* in op_attach and it's the *very first compressed data* I send to server after the initial auth dance (which is uncompressed, obviously). I tried to capture as much data as I could. To get some hint for me or some smart people here. Here's https://snag.gy/mKaF7j.jpg the WireShark screenshot of two *different* runs. I send the op_attach (416/412 bytes highlighted lines - which is 166/164 bytes of op_attach data) and then immediately the FIN follows. The data being sent are (in HEX) 789c62606010668000d1bcd49282a2fcb2cc94d4a2f892d4e29262bdb49424885c2ba3154b051703833d0b339067c0525a926621c3161c19ece2e468c9c20f147367d9c0c3c0e0a5ec6c1513929f9f531ce3179a9759621c9394991793570a64ea26a6a7e695e8a556a406b09bea19e801718886899393a391a3a9a9899bb199b9a3a5a1a585b3a5919181a1a1939b91a5a5a385b18b8989a1a389b92f0bd49100000000ffff and 789c62606010668000d1bcd49282a2fcb2cc94d4a2f892d4e29262bdb49424885c2ba3154b051703833d0b339067c0525a926621c3161c19ece2e468c9c20f147367d9c0c3c0e0a5ec6c1513929f9f531ce3179a9759621c9394991793570a64ea26a6a7e695e8a556a406b09bea19e80171888691b1ab89b189b385a39189ab85a3a185b1b3b9a3a38bb913906beee6ece86ce4e8e26c6ae1e6e8cb027524000000ffff the first one before compression is (0x13 = op_attach, clearly) 00-00-00-13-00-00-00-00-00-00-00-15-6E-65-74-70-72-6F-76-69-64-65-72-5F-74-65-73-74-73-2E-66-64-62-00-00-00-00-00-00-85-01-3A-04-78-0A-00-00-3F-04-03-00-00-00-30-04-75-74-66-38-1C-06-53-59-53-44-42-41-39-04-0F-00-00-00-47-04-0C-09-00-00-4A-23-43-3A-5C-54-6F-6F-6C-73-5C-4E-55-6E-69-74-33-5C-62-69-6E-5C-6E-75-6E-69-74-2D-61-67-65-6E-74-2E-65-78-65-50-07-35-2E-30-2E-35-2E-30-54-28-44-34-35-34-46-33-37-41-30-44-32-38-31-35-37-36-31-45-35-33-46-35-35-38-43-33-36-45-44-32-33-46-33-32-32-39-32-35-45-31-4D-04-00-00-00-00-00-00-00 Same data sent couple of times before (or after) didn't caused any trouble. When the connection was closed, my tests were waiting in debugger and hence there was no high level response to FIN back to server and I immediately tried creating full dump of Firebird process (but I know that might be too late anyway). Here are the two dumps for inspection http://uschovna.cz/zasilka/KTV8BVKU92ZEYACL-SGY and also here http://uschovna.cz/zasilka/KT6289CJF6JUU62M-YLU are full recordings from WireShark (you can see it there few times, easiest to find is to check the last packets). Fair to say the server runs fine after it and next connections (even the same retried) are fine. So it looks like something runs over/out on server and goes out of hand. Which *I* might be causing (maybe some data before), for sure, but at least the server should handle it gracefully, IMO. I can set up the machine in few minutes and then it's RDP accessible, if somebody want's to see it in action with me. Any help would be greatly appreciated. -- Mgr. Jiří Činčura Independent IT Specialist ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
