Backtrace when Protocols.HTTP.Query objects are cleaned up
Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5730
Reported by Martin Stjernholm mast@roxen.com
These occur regurlarly when the refcount garb frees Protocols.HTTP.Query objects:
File not open.
-:1: Fd(-49)->set_nonblocking()
-:1: Stdio.File("socket", "152.90.238.80:443", 777 /* fd=-1 */)->set_nonblocking()
C:/Program Files (x86)/Pike/lib/modules/Stdio.pmod/module.pmod:1374: Stdio.File("socket", "152.90.238.80:443", 777 /* fd=-1 */)->set_nonblocking(UNDEFINED,UNDEFINED,UNDEFINED,UNDEFINED,UNDEFINED)
C:/Program Files (x86)/Pike/lib/modules/Protocols.pmod/HTTP.pmod/Query.pike:1168: Protocols.HTTP.Query()->close()
C:/Program Files (x86)/Pike/lib/modules/Protocols.pmod/HTTP.pmod/Query.pike:1160: Protocols.HTTP.Query()->destroy()
... the rest of the backtrace is unrelated
Some cvs digging points at this commit:
revision 1.106 date: 2010/03/12 10:18:34; author: srb; state: Exp; lines: +20 -19 Expose close() so you do not have to wait for garbage collection.
It removes a few catches in the destroy() function. Apparently they are there for a reason, but hopefully it's possible to solve the problem in a less blunt way.