The read callback registered in the Stdio.File object has become zero in some way without Stdio.File knowing about it. If you set it to zero through set_read_callback or similar, it will deregister the internal wrapper callback __stdio_read_callback correctly and it won't happen.
A common cause for this is that the object your callbacks are in has been destructed while the Stdio.File object still is in use by the backend.
Another possibility is that you call set_read_callback(0) in another thread when the backend thread just has called __stdio_read_callback.
Stdio.File isn't thread safe, and I'm not sure it should be. There are some attempts to make it thread safe in 7.4 and later through the internal functions _disable_callbacks and _enable_callbacks, but afaics they won't work reliably.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-17 11:06: Subject: Strange things with Stdio.File
Hi list,
I am have some problems with Stdio.File which looks quite the same telling about the attempt to call the NULL-value when using non blocking I/O:
Attempt to call the NULL-value Unknown program: 0(0,"* OK [CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT] Courier-IMAP ready. Copyright 1998-2003 Double Precision, Inc. See COPYING for distribution informatio"+[5]) /usr/local/pike/7.2.512/lib/modules/Stdio.pmod/module.pmod:692: Stdio.File("socket", "localhost:143", 777 /* fd=-1 */)->__stdio_read_callback()
Attempt to call the NULL-value Unknown program: 0(0,"421 Error: timeout exceeded\r\n") /usr/lib/pike/7.2.526/lib/modules/Stdio.pmod/module.pmod:692: Stdio.File("socket", "127.0.0.1:10026", 777 /* fd=35 */)->__stdio_read_callback()
Do you know what these mean ? FYI I use Pike 7.2.512 and 7.2.526.
/ David Gourdelier
/ Brevbäraren